หลักการแบบ end-to-end สามารถทำเป็นกรงเล็บได้หรือไม่?

ในช่วงปลายปี 1990 ตอนที่ฉันอยู่ในบัณฑิตวิทยาลัยกระดาษ

JH Saltzer; DP Reed; DD คลาร์ก: ข้อโต้แย้ง End-to-end ในการออกแบบระบบ ACM Trans คอมพิวเต Syst 2 (4): 277-288, 1984. DOI = 10.1145 / 357401.357402

มันค่อนข้างจำเป็นต้องอ่านในทุกระบบปฏิบัติการในทุก ๆ ชั้นของมหาวิทยาลัยและมันก็ยังคงเป็นหนึ่งในหลักการที่เป็นแนวทางหลักในการออกแบบอินเทอร์เน็ต (ดูตัวอย่าง: J Kempf, R Austein (eds) และ IAB " การเพิ่มขึ้นของกลางและอนาคตของ End-to-End: ภาพสะท้อนของวิวัฒนาการของสถาปัตยกรรมอินเทอร์เน็ต " RFC 3724, มีนาคม 2004 )

สถานะของหลักการแบบครบวงจร (Saltzer et al., 1984):

[ถ้า] ฟังก์ชั่นที่เป็นปัญหาสามารถดำเนินการได้อย่างสมบูรณ์และถูกต้องเฉพาะกับความรู้และความช่วยเหลือของแอปพลิเคชันที่ยืนอยู่ที่จุดสิ้นสุดของระบบการสื่อสาร, ... , หากฟังก์ชั่นที่สงสัยว่าเป็นคุณสมบัติของระบบการสื่อสารเอง เป็นไปได้ [แม้ว่า] บางครั้งรุ่นที่ไม่สมบูรณ์ของฟังก์ชั่นที่มีให้โดยระบบการสื่อสารอาจมีประโยชน์เป็นการเพิ่มประสิทธิภาพ

หรือสั้นกว่า (จากนามธรรม):

อาร์กิวเมนต์แบบ end-to-end แสดงให้เห็นว่าฟังก์ชั่นที่วางไว้ในระดับต่ำของระบบอาจซ้ำซ้อนหรือมีค่าน้อยเมื่อเทียบกับค่าใช้จ่ายของการให้พวกเขาในระดับต่ำที่

แต่ฉันประสบความสำเร็จเพียงเล็กน้อยในการใช้หลักการแบบครบวงจรในประสบการณ์ของฉันเอง (ซึ่งอยู่ในสถาปัตยกรรมคอมพิวเตอร์ไม่ใช่สถาปัตยกรรมอินเทอร์เน็ต) เนื่องจากหลักการดังกล่าวเป็น "บทกวี" (กล่าวคือในร้อยแก้วภาษาอังกฤษที่มีกลุ่มของคำศัพท์ที่ไม่ได้กำหนดทางคณิตศาสตร์) มันค่อนข้างง่ายที่จะหลอกตัวเองในการคิดว่า "ฟังก์ชั่นในคำถามได้อย่างสมบูรณ์และถูกต้องเท่านั้น ความรู้และความช่วยเหลือของแอปพลิเคชัน " แต่ "ฟังก์ชั่นที่เป็นปัญหา" คือความรู้และความช่วยเหลือ "ของแอปพลิเคชันเพียงอย่างเดียว

ตัวอย่าง: เครือข่ายบนชิป (ต่างจากอินเทอร์เน็ต) ไม่ได้รับอนุญาตให้วางแพ็กเก็ต แต่มีบัฟเฟอร์ค่อนข้าง จำกัด ดังนั้นคุณต้องมีวิธีหลีกเลี่ยงหรือกู้คืนจากการหยุดชะงัก ในทางกลับกันแอปพลิเคชันต้องทำให้ตัวเองหยุดชะงักได้ฟรีเช่นกันใช่ไหม? ดังนั้นฉันอาจให้เหตุผลว่าฉันควรทำให้กรณีทั่วไป (ไม่มีการหยุดชะงัก) อย่างรวดเร็วและดันการหลีกเลี่ยงการหยุดชะงักของแอพ นี่คือความจริงแล้วสิ่งที่เราลองใช้กับ Alewife และ Fugu (Mackenzie, et al., Exploiting การจัดส่งแบบสองกรณีสำหรับการส่งข้อความที่ได้รับการปกป้องอย่างรวดเร็ว Int'l Symp High-Perf Comp Arch, (HPCA-4): 231-242, 1998. หรือวิทยานิพนธ์ของ John Kubiatowicz.) มัน "ใช้งานได้" (โดยให้ interconnect ขัดจังหวะตัวประมวลผลเมื่อบัฟเฟอร์เต็มและมีการเพิ่มระบบปฏิบัติการด้วยการบัฟเฟอร์ซอฟต์แวร์) แต่ฉันไม่เห็นใครในวงการการศึกษาหรืออุตสาหกรรม (รวมถึงพวกเราที่เป็นผู้เขียนในเรื่องนั้น กระดาษ HPCA) แข่งรอบพยายามทำซ้ำความคิด ดังนั้นการหลีกเลี่ยงการหยุดชะงักที่เห็นได้ชัดในเครือข่ายจึงไม่เหมือนกับ "ฟังก์ชั่นที่เป็นปัญหา" เช่นเดียวกับการหลีกเลี่ยงการหยุดชะงักของระดับแอปพลิเคชันหรือหลักการจากต้นทางถึงปลายทางผิด

เป็นไปได้ไหมที่จะเปลี่ยนหลักการจากต้นจนจบจาก "บทกวี" เป็นทฤษฎีบท? หรืออย่างน้อยก็สามารถระบุได้ในแง่ที่เข้าใจได้กับสถาปนิกคอมพิวเตอร์หรือไม่?

ฉันเชื่อว่าอาจมีข้อบกพร่องสองประการในการประยุกต์ใช้หลักการแบบ end-to-end (e2e) ของคุณ:

ประการแรกในแง่ที่คุณใช้มันเพื่อการแสดง end-to-end เป็นหลักการออกแบบเช่นเพื่อให้แน่ใจว่า orthogonality สถาปัตยกรรมความเรียงสม่ำเสมอหนึ่งหรือทั้งหมดให้ดั้งเดิมเป็นต้นหลักการดังกล่าวได้รับการระบุไว้ในตำราที่เกี่ยวข้อง ประสิทธิภาพไม่ใช่หนึ่งในนั้น ในความเป็นจริง Clark et al หมายถึงว่าการจบจากจุดหนึ่งไปยังอีกจุดหนึ่งอย่างเข้มงวดอาจส่งผลให้ประสิทธิภาพแย่ลงดังนั้นจึงใช้เช่นนี้เป็นข้อยกเว้นสำหรับหลักการนี้

ดังนั้นหากคุณยังต้องการทำเป็นระเบียบ:

"การโต้แย้งแบบ end-to-end นั้นเป็นที่สนใจของความต้องการของแอพพลิเคชั่นและให้เหตุผลสำหรับการย้ายฟังก์ชั่นขึ้นในระบบเลเยอร์" ดังนั้นคุณจะต้องมีข้อกำหนดแอพพลิเคชั่นที่เป็นทางการและระบบชั้นแบบเป็นทางการ นี่คือความพยายามที่อาจช่วยให้ก้าวไปอีกขั้นหนึ่ง:

สมมติว่าคุณมีข้อกำหนดของเลเยอร์ (i) (เลเยอร์ (0) สำหรับชุดแอปพลิเคชันที่คุณคาดหวังว่าจะรองรับในตอนนี้หรือในอนาคตแอพพลิเคชั่นเลเยอร์) และอินเทอร์เฟซของ บริษัท (i, i + 1) และ Interface (i + 1) , i) (จากเลเยอร์ i ถึง i + 1 ถือว่าไม่มี cross-layering ที่นี่ง่ายต่อการเปลี่ยนแปลงและทำให้เป็นข้อกำหนด) และฟังก์ชั่น Function (i, j) (Layer i, Function index j, สันนิษฐานว่าเป็นส่วนหนึ่งของข้อมูล เพื่อให้มันง่ายขึ้น)

อินพุต: ข้อกำหนดของเลเยอร์ (0) (ดังที่เรากล่าวว่าสิ่งเหล่านี้จำเป็นต้องทำเป็นระเบียบ)

เอาท์พุท: ทุกอย่างอื่น

เอาท์พุท END-TO-END เป็นเอาท์พุทที่: สำหรับแต่ละ L, เลเยอร์ (L) บรรลุความต้องการโดยฟังก์ชั่นเท่านั้นฟังก์ชั่น (L, j) (ฟังก์ชั่นภายในเลเยอร์) และอินเทอร์เฟซ (L, L + 1) (L + 1, L)

สำหรับแต่ละเลเยอร์ L และฟังก์ชั่นฟังก์ชั่น (L, F) ไม่มีชุดฟังก์ชั่น S ในเอาต์พุตที่ฟังก์ชั่น (L, F) = S (= หมายถึงเอาต์พุตที่เทียบเท่าและผลข้างเคียง)

ดังนั้นการมาถึงข้อผิดพลาดที่เป็นไปได้ครั้งที่สองสำหรับแอปพลิเคชั่นหลัก e2e เฉพาะ (และถ้าฉันอ่านอย่างถูกต้องสิ่งที่พยายาม) เราสามารถอ้างได้ว่ามันไม่เป็นไปตามหลักการ e2e เลยค่อนข้างตรงกันข้าม คุณมีชิปของคุณที่ให้ "การหลีกเลี่ยงการหยุดชะงักบางอย่าง" และคุณมีอินเทอร์เฟซที่ไม่ธรรมดาและไม่เฉพาะเจาะจงสำหรับการทริกเกอร์ (ขัดจังหวะ) ความช่วยเหลือเพิ่มเติมจากชั้นบน นี่เป็นวิธีการข้ามชั้นไม่ใช่วิธีการแบบครบวงจร กล่าวอีกนัยหนึ่งคุณมีฟังก์ชั่น (1, x) ไม่สามารถทำงานให้เสร็จสมบูรณ์และถูกต้องด้วยการตั้งค่าอินเทอร์เฟซ - ถ้าคุณต้องการใช้แบบฟอร์มการทำให้เป็นระเบียบดังกล่าวข้างต้น (ซึ่งแน่นอนว่า แต่มีแนวโน้มที่จะไม่เต็มในตัวเอง)