Чи можна формалізувати принцип "від кінця до кінця"?

Наприкінці 1990-х, коли я навчався в аспірантурі, папір

JH Saltzer; Д. П. Рід; Д.Д. Кларк: аргументи в кінці системи . ACM Trans. Обчислення. Сист. 2 (4): 277-288, 1984. DOI = 10.1145 / 357401.357402

був дуже потрібний для читання в кожному класі операційних систем у кожному університеті, і все одно, здається, це один з головних керівних принципів, що лежать в основі дизайну Інтернету. (Див. Наприклад: J Kempf, R Austein (eds) та IAB, " Повстання середини та майбутнього від кінця до кінця: роздуми про еволюцію інтернет-архітектури ", RFC 3724, березень 2004 року. )

Принцип дії "до кінця" (Saltzer et al., 1984):

[Якщо] функція, про яку йдеться, може повністю та правильно реалізовуватися лише за допомогою знань та допомоги програми, що стоїть у кінцевих точках системи зв’язку, ..., за умови, що сумнівна функція як особливість самої системи зв'язку не є можливо. [Хоча] іноді неповна версія функції, що надається системою зв'язку, може бути корисною як підвищення продуктивності.

Або коротше (з реферату):

Аргумент «до кінця» говорить про те, що функції, розміщені на низьких рівнях системи, можуть бути зайвими або малими значеннями в порівнянні з витратами на забезпечення їх на такому низькому рівні.

Але я мав невеликий успіх у застосуванні принципу "до кінця" на власному досвіді (що стосується комп'ютерної архітектури, а не Інтернет-архітектури). Оскільки принцип викладений як "вірш" (тобто в англійській прозі з купою термінів, які не визначені математично), досить просто обдурити себе думкою, що "розглянутий функції можна повністю і правильно реалізовувати лише за допомогою знання та допомога програми ". Але що таке "функція, про яку йдеться," не кажучи вже про "знання та допомогу" програми?

Приклад: На мережах з мікросхемами (на відміну від Інтернету) заборонено скидати пакети, але вони мають досить обмежену буферизацію, тому вам потрібно мати якийсь спосіб уникнення або відновлення з тупикової ситуації. З іншого боку, додатку також потрібно зробити вільний тупик, чи не так? Тому я можу пояснити, що я повинен зробити звичайний випадок (без тупика) швидким і відсунути тупик у програмі. Це, власне, те, що ми спробували на Alewife та Fugu (Mackenzie, співавт., Експлуатуючи доставку у двох випадках для швидкого захищеного обміну повідомленнями , Int'l Symp High Perf Comp Arch, (HPCA-4): 231-242, 1998. Або дисертація Джона Кубіатовича.) "Це спрацювало" (тим, що взаємозв'язок переривав процесор, коли буфери заповнювались та мав розширення ОС з буферизацією програмного забезпечення), але я не бачив нікого в академіях чи галузі (включаючи когось із нас, хто був автором цього Папір HPCA) мчить навколо, намагаючись повторити ідею. Таким чином, очевидно, уникнення тупикових ситуацій у мережі - це не та сама "функція, про яку йдеться", як уникнення тупикового рівня на застосуванні, або принцип "від кінця до кінця" є неправильним.

Чи можна перетворити принцип "від кінця до кінця" з "поеми" в теорему? Або принаймні, чи можна це висловити в термінах, зрозумілих архітектору комп'ютерів?

Я вважаю, що у вашому застосуванні принципу "кінець до кінця" (e2e) можуть бути два недоліки:

По-перше, в тому сенсі, що ви застосовуєте його для виконання. Цільовий принцип - такий принцип дизайну, який забезпечує ортогональність архітектури, композиційність, регулярність, одне або все, надання примітивів тощо. Такі принципи були викладені у відповідних підручниках. Продуктивність не одна з них. Насправді, Кларк та ін., Випливає, що суворий кінцевий результат може призвести до погіршення продуктивності, тому він використовує такі, як виняток із цього принципу.

Отже, якщо ви все ще хочете оформлити:

"Аргумент" в кінці "звертається до вимог додатків і надає обгрунтування для переміщення функції вгору в шаруватій системі", тому вам знадобляться формалізовані вимоги додатків та формалізована шарувата система. Ось спроба, яка може допомогти зробити її на крок далі:

Скажімо, у вас є вимоги до рівня (i) (Layer (0) - це набір програм, які, як ви очікуєте, буде підтримувати зараз або в майбутньому, рівень додатків) та тверді інтерфейси Interface (i, i + 1) та Interface (i + 1 , i) (від шару i до i + 1 попередньо не припускайте, що тут немає перехресного шару, його легко змінити та зробити його вимогою) та функції функція (i, j) (шар i, індекс функцій j, припустимо, частина даних функції щоб було простіше)

Введення: вимоги рівня (0) (як ми говорили, їх потрібно формалізувати)

Вихід: все інше

Вихід "END-TO-END" - це такий вихід, що: Для кожного L рівень (L) виконує свої вимоги лише за допомогою функцій Function (L, j) (тобто функції всередині шару) та Interface (L, L + 1), Interface (L + 1, L)

Для кожного шару L та функції функції (L, F) немає набору функцій S на виході таким чином, що функція (L, F) = S (= означає еквівалентний вихід і побічні ефекти)

Отже, прийшовши до другого можливого недоліку для конкретного застосування принципу e2e (і якщо я читаю правильно те, що намагаються), можна стверджувати, що воно зовсім не слідує принципу e2e, навпаки. У вас чіпи надають "певне уникнення глухого кута", і у вас є інтерфейс, який є звичайним нефірмовим і специфічним, щоб викликати (перервати) додаткову допомогу верхніх шарів. Це, мабуть, підхід на багатошаровому рівні, а не підхід до кінця. Іншими словами, у вас функція (1, x) не виконує своє завдання повністю та правильно із встановленими інтерфейсами - якщо ви хочете використовувати проект формалізації, передбачений вище (що, звичайно, лише початок корисний для розширення, щоб повністю відповісти на ваше запитання але, ймовірно, не повна сама по собі).