Czy zasadę kompleksowości można sformalizować?

Pod koniec lat 90., kiedy byłem na studiach, gazeta

JH Saltzer; Stroik DP; DD Clark: Kompleksowe argumenty w projektowaniu systemu . ACM Trans. Comput. Syst. 2 (4): 277-288, 1984. DOI = 10.1145 / 357401.357402

było prawie wymagane czytanie w każdej klasie systemów operacyjnych na każdym uniwersytecie i nadal wydaje się być jedną z głównych zasad leżących u podstaw projektowania Internetu. (Patrz na przykład: J Kempf, R Austein (red.) I IAB, „ The Rise of the Middle and the Future of End-to-End: Refleksje na temat ewolucji architektury Internetu ”, RFC 3724, marzec 2004. )

Zasada end-to-end stwierdza (Saltzer i in., 1984):

[Jeżeli] dana funkcja może zostać całkowicie i poprawnie zaimplementowana tylko przy wiedzy i pomocy aplikacji stojącej w końcowych punktach systemu komunikacyjnego ..., pod warunkiem, że ta kwestionowana funkcja jako cecha samego systemu komunikacyjnego nie jest możliwy. [Chociaż] czasami niepełna wersja funkcji zapewnianej przez system komunikacyjny może być przydatna jako ulepszenie wydajności.

Lub w skrócie (z streszczenia):

Argument end-to-end sugeruje, że funkcje umieszczone na niskich poziomach systemu mogą być zbędne lub mieć niewielką wartość w porównaniu z kosztem ich zapewnienia na tym niskim poziomie.

Ale z niewielkim powodzeniem stosowałem zasadę end-to-end we własnym doświadczeniu (która dotyczy architektury komputerowej, a nie architektury internetowej). Ponieważ zasada jest określona jako „wiersz” (tj. W angielskiej prozie zawierającej kilka terminów, które nie są zdefiniowane matematycznie), dość łatwo oszukać się, że „daną funkcję można całkowicie i poprawnie zrealizować tylko za pomocą znajomość i pomoc aplikacji ”. Ale czym jest „omawiana funkcja”, nie mówiąc już o „wiedzy i pomocy” aplikacji?

Przykład: sieci na chipie (w przeciwieństwie do Internetu) nie mogą upuszczać pakietów, ale mają dość ograniczone buforowanie, więc musisz mieć sposób na uniknięcie impasu lub odzyskanie go. Z drugiej strony aplikacja musi również stać w martwym punkcie, prawda? Mogę więc pomyśleć, że powinienem zrobić wspólny przypadek (bez impasu) szybko i odrzucić unikanie impasu w aplikacji. Właśnie tego próbowaliśmy na Alewife i Fugu (Mackenzie i in., Exploiting Two-Case Delivery for Fast Protected Messaging , Int'l Symp High-Perf Comp Arch, (HPCA-4): 231-242, 1998. Lub rozprawa Jana Kubiatowicza.) „Zadziałało” (ponieważ interkonekt przerwał procesor, gdy bufory zostały zapełnione, a system operacyjny został wzbogacony o buforowanie oprogramowania), ale nie spotkałem nikogo w środowisku akademickim lub przemysłowym (w tym żadnego z nas, którzy byli autorami tego Papier HPCA) ścigający się, próbując powtórzyć ten pomysł. Zatem najwyraźniej unikanie zakleszczenia w sieci nie jest tą samą „omawianą funkcją”, jak unikanie zakleszczenia na poziomie aplikacji, lub zasada end-to-end jest błędna.

Czy można przekształcić zasadę end-to-end z „wiersza” w twierdzenie? A przynajmniej czy można to stwierdzić w sposób zrozumiały dla architekta komputerowego?

Uważam, że mogą występować dwa niedociągnięcia w stosowaniu zasady end-to-end (e2e):

Po pierwsze, w tym sensie, że zastosujesz go do wydajności. Kompletny jest zasadą projektowania, która zapewnia ortogonalność architektury, kompozycyjność, regularność, jedno lub wszystkie, zapewnia prymitywy itp. Takie zasady zostały opisane w powiązanych podręcznikach. Wydajność nie jest jedną z nich. W rzeczywistości Clark i wsp. Implikują, że ścisłe kompleksowe działanie może skutkować gorszą wydajnością, dlatego wykorzystuje takie, jako wyjątek od tej zasady.

Jeśli więc nadal chcesz sformalizować:

„Argument end-to-end odwołuje się do wymagań aplikacji i stanowi uzasadnienie dla przeniesienia funkcji w górę w systemie warstwowym”, więc będziesz potrzebować sformalizowanych wymagań aplikacji i sformalizowanego systemu warstwowego. Oto próba, która może pomóc pójść o krok dalej:

Załóżmy, że masz wymagania dotyczące warstwy (i) (warstwa (0) dotyczy zestawu aplikacji, które spodziewasz się teraz lub w przyszłości, warstwy aplikacji) oraz stabilnych interfejsów Interfejs (i, i + 1) i Interfejs (i + 1 , i) (od Warstwy i do i + 1 zakładamy tutaj brak nakładania warstw, łatwo je zmienić i sprawiają, że jest to wymóg) i funkcje Funkcja (i, j) (Warstwa i, Indeks funkcji j, zakłada część danych funkcji mieć to prostsze)

Dane wejściowe: wymagania dotyczące warstwy (0) (jak powiedzieliśmy, należy je sformalizować)

Wyjście: wszystko inne

Wyjście END-TO-END jest wyjściem takim, że: Dla każdego L warstwa (L) spełnia swoje wymagania tylko za pomocą funkcji Funkcja (L, j) (tj. Funkcje w warstwie) i Interfejs (L, L + 1), Interfejs (L + 1, L)

Dla każdej warstwy L i funkcji Funkcja (L, F) nie ma zestawu Funkcji S na wyjściu, więc Funkcja (L, F) = S (= oznacza równoważną wydajność i skutki uboczne)

Tak więc, dochodząc do drugiego możliwego niedociągnięcia dla konkretnego zastosowania zasady e2e (i jeśli dobrze czytam, co się próbuje), można stwierdzić, że wcale nie jest ona zgodna z zasadą e2e. Twoje układy zapewniają „pewne unikanie zakleszczeń” i masz interfejs, który jest nietypowy, nie jest twardy i specyficzny, aby wyzwalać (przerywać) więcej pomocy z wyższych warstw. Jest to prawdopodobnie podejście między warstwami, a nie podejście kompleksowe. Innymi słowy, masz funkcję (1, x), która nie wypełnia swojego zadania całkowicie i poprawnie z ustawionymi interfejsami - jeśli chcesz skorzystać z powyższej formalizacji wersji roboczej (która oczywiście jest tylko początkiem przydatnym do rozszerzenia, aby w pełni odpowiedzieć na twoje pytanie ale prawdopodobnie sama w sobie nie jest pełna).