บทนำร่วม 3/8

การแบ่งทรัพยากรเครือข่ายให้ใช้ร่วมกัน (Multiplexing)

Link หนึ่งเส้นมีต้นทุน แต่ผู้ใช้ไม่ได้ส่งข้อมูลตลอดเวลา Multiplexing จึงเป็นวิธีทำให้ข้อมูลหลาย flow ใช้ช่องทางเดียวกันร่วมกันได้ โดยแบ่งทรัพยากรตามความถี่ เวลา หรือความต้องการที่เกิดขึ้นจริง

1เทคนิคการ Multiplex

เครือข่ายที่มีประสิทธิภาพไม่ได้เกิดจากการสร้าง link ส่วนตัวให้ผู้ใช้ทุกคน แต่เกิดจากการเปิดให้หลายคนใช้ link เดียวกัน โดยยังแยกข้อมูลของแต่ละคนกลับออกมาได้ถูกต้อง โจทย์จึงไม่ใช่เพียง “รวมอย่างไร” แต่รวมแล้วต้องไม่ปนกัน และแบ่งกันอย่างไรจึงจะคุ้มค่าและเป็นธรรม

ทำไมต้องแบ่งใช้ทรัพยากร

ลองคิดถึง link ความเร็วสูงที่เชื่อมอาคารสองหลัง หากมีผู้ใช้ 100 คน ทางเลือกที่ตรงไปตรงมาที่สุดคือสร้าง link แยก 100 เส้น แต่ผู้ใช้แต่ละคนไม่ได้ส่งข้อมูลเต็มกำลังตลอดเวลา บางคนอ่านหน้าเว็บ บางคนกำลังพิมพ์ข้อความ และบางคนลุกไปชงกาแฟ ถ้าแต่ละคนครอบครอง link ของตนเอง ทรัพยากรส่วนใหญ่จะว่างอยู่เกือบตลอดวัน

ทางเลือกที่สมเหตุสมผลกว่าคือให้ทุกคนแชร์ link เส้นเดียวกัน แต่ทันทีที่พูดว่า “แชร์” คำถามใหม่ก็เกิดขึ้น ใครได้ใช้ก่อน ใช้ได้นานแค่ไหน ถ้าหลายคนต้องการพร้อมกันจะทำอย่างไร และเมื่อข้อมูลไปถึงอีกฝั่ง เราจะแยกออกได้อย่างไรว่าส่วนใดเป็นของใคร

คำจำกัดความ

Multiplexing คือกระบวนการรวมข้อมูลจากหลายแหล่งหรือหลาย flow ให้เดินทางผ่านทรัพยากรร่วมกัน ส่วน demultiplexing คือกระบวนการที่ปลายทางแยกข้อมูลรวมออก แล้วส่งแต่ละส่วนไปยังผู้รับหรือ flow ที่ถูกต้อง

หลายแหล่งข้อมูลFlow A, B และ C

Multiplexerรวมตามกติกา

Shared Linkส่งผ่านช่องทางเดียว

Demultiplexerอ่านตัวระบุและแยกกลับ

หลายปลายทางคืนให้ A, B และ C

ลองนึกภาพ — รถไฟหนึ่งขบวนกับผู้โดยสารหลายคน

Multiplexing คล้ายการให้ผู้โดยสารหลายคนเดินทางด้วยรถไฟขบวนเดียวกัน แทนที่จะสร้างรถไฟส่วนตัวคนละขบวน ทุกคนแชร์หัวรถจักร ราง และเวลาเดินทางร่วมกัน แต่แต่ละคนมีตั๋วระบุที่นั่งและสถานีปลายทาง จึงแยกได้ว่าใครต้องลงที่ไหน

การรวมกันไม่ได้แปลว่าข้อมูลกลายเป็นก้อนเดียวที่แยกไม่ออก ตรงกันข้าม ระบบต้องเพิ่มกติกาหรือตัวระบุบางอย่างเพื่อให้แยกกลับได้ ความคุ้มค่าจึงมาพร้อมข้อมูลควบคุมและกลไกจัดการ ไม่ใช่เพียงเททุกอย่างลงท่อเดียวแล้วหวังว่าปลายทางจะเดาออกเอง

เราแบ่ง “อะไร” ให้ผู้ใช้แต่ละราย

วิธี multiplex ต่างกันตรงมิติของทรัพยากรที่นำมาแบ่ง บางระบบแบ่งช่วงความถี่ บางระบบแบ่งช่วงเวลา บางระบบแยกด้วยรหัส และบางระบบไม่กันส่วนใดไว้ล่วงหน้า แต่ให้ packet เข้าคิวตามข้อมูลที่มาถึงจริง

เทคนิค	แบ่งทรัพยากรอย่างไร	สิ่งที่ต้องแลก
FDM Frequency-Division Multiplexing	แบ่งย่านความถี่ออกเป็นช่อง แต่ละสัญญาณใช้คนละช่วงความถี่และส่งพร้อมกันได้	ต้องมีช่องว่างระหว่างย่านหรือ guard band เพื่อลดการรบกวน และส่วนที่จัดไว้ยังคงว่างเมื่อผู้ใช้ไม่มีข้อมูล
STDM Synchronous Time-Division Multiplexing	แบ่งเวลาเป็น time slot ที่วนซ้ำ แต่ละ flow ได้ช่องประจำตามตารางที่กำหนดไว้	คาดการณ์สิทธิ์ได้ง่าย แต่ slot อาจเสียเปล่าเมื่อเจ้าของไม่มีข้อมูลส่ง
Statistical Multiplexing	ไม่ได้กัน slot ตายตัว ให้ packet ของ flow ที่มีข้อมูลจริงเข้าคิวและแชร์ link ตามนโยบายของระบบ	ใช้ช่วงว่างของกันและกันได้ดี แต่ต้องมี buffer และต้องรับมือกับ queueing delay, congestion และ packet loss
WDM Wavelength-Division Multiplexing	ใช้แสงหลายความยาวคลื่นส่งพร้อมกันในใยแก้วเส้นเดียว มองได้ว่าเป็น FDM ในระบบ optical	ต้องใช้อุปกรณ์ optical ที่แยกและรวมความยาวคลื่นได้
CDM/CDMA Code-Division Multiplexing	ผู้ใช้หลายรายใช้เวลาและย่านความถี่ร่วมกัน แต่แยกด้วย code ที่ออกแบบไว้	การแยกสัญญาณและควบคุมกำลังซับซ้อนขึ้น และประสิทธิภาพขึ้นกับคุณสมบัติของ code

รายการนี้ไม่ใช่การแบ่งประเภทที่ปิดตาย เทคโนโลยีจริงอาจนำหลายวิธีมาใช้ร่วมกัน เช่น ใยแก้วหนึ่งเส้นแบ่งเป็นหลาย wavelength แต่ละ wavelength ส่งข้อมูลเป็นลำดับเวลา และภายในข้อมูลนั้นยังมี packet ของหลาย application ซ้อนกันอีกชั้นหนึ่ง Multiplexing จึงเกิดได้หลายระดับพร้อมกัน

FDM: แบ่งพื้นที่ตามความถี่

ใน FDM ผู้ใช้แต่ละรายได้รับช่วงความถี่ของตนเองและส่งพร้อมกันได้ เปรียบเหมือนสถานีวิทยุหลายสถานีออกอากาศพร้อมกันในอากาศเดียว แต่แต่ละสถานีอยู่คนละความถี่ เครื่องรับเลือกฟังสถานีที่ต้องการด้วยการปรับไปยังย่านนั้น

ความท้าทายคือสัญญาณจริงไม่ได้หยุดคมกริบตรงขอบความถี่ จึงมักต้องเว้น guard band ระหว่างช่องเพื่อลดการรบกวน พื้นที่ที่เว้นนี้ช่วยให้ระบบทำงานถูกต้อง แต่ก็เป็นทรัพยากรที่ไม่ได้ใช้ส่งข้อมูลโดยตรง

ลองนึกภาพ — ถนนหลายช่องที่วิ่งพร้อมกัน

FDM คล้ายแบ่งถนนกว้างออกเป็นหลายช่อง รถของแต่ละกลุ่มวิ่งในช่องของตนได้พร้อมกัน เส้นแบ่งช่องช่วยไม่ให้รถปะปนกัน แต่พื้นที่ของแต่ละช่องถูกกันไว้แล้ว หากช่องหนึ่งไม่มีรถ ช่องข้าง ๆ ก็ไม่ได้ขยายเข้ามาใช้เองโดยอัตโนมัติ

STDM: แบ่งกันตามตารางเวลา

STDM แบ่งเวลาออกเป็น frame และแบ่งแต่ละ frame เป็น slot ผู้ใช้แต่ละรายได้ slot ประจำวนซ้ำไปตามลำดับ ข้อดีคือปลายทางทราบตารางอยู่แล้ว จึงแยกข้อมูลกลับได้จากตำแหน่งของ slot และแต่ละ flow ทราบว่าตนจะได้สิทธิ์เมื่อไร

ปัญหาเกิดเมื่อ traffic มาเป็นช่วง หากถึง slot ของ A แต่ A ไม่มีข้อมูล slot นั้นอาจว่าง ขณะที่ B มีข้อมูลกองรออยู่ก็ยังใช้แทนไม่ได้ ความเป็นระเบียบจึงแลกมาด้วยโอกาสที่ทรัพยากรถูกจองไว้แต่ไม่ได้ใช้

ลองนึกภาพ — ห้องเรียนที่กำหนดตารางตายตัว

STDM คล้ายห้องเรียนที่แบ่งเวลาให้อาจารย์ A ใช้ 9.00–10.00 น. และอาจารย์ B ใช้ 10.00–11.00 น. ทุกคนวางแผนได้ง่ายและไม่แย่งห้องกัน แต่ถ้า A ยกเลิกสอน ห้องอาจว่างหนึ่งชั่วโมง แม้ B จะมีนักศึกษารออยู่หน้าห้องก็ตาม

ระบบนี้ไม่ได้ไม่มีประสิทธิภาพเสมอไป หากผู้ใช้มีข้อมูลสม่ำเสมอและต้องการเวลาที่แน่นอน การจอง slot ล่วงหน้ากลับเป็นข้อดี ปัญหาไม่ได้อยู่ที่การแบ่งตายตัว แต่อยู่ที่รูปแบบการแบ่งนั้นตรงกับรูปแบบการใช้งานหรือไม่

Statistical Multiplexing: ใครมีข้อมูลก็เข้าคิว

Statistical multiplexing ไม่จัด slot ประจำให้แต่ละ flow หาก A ไม่มีข้อมูล ช่วงเวลาของ link สามารถนำไปส่ง packet ของ B หรือ C ได้ จึงเหมาะกับ traffic ของคอมพิวเตอร์ที่มักเป็นแบบ bursty คือเงียบอยู่ช่วงหนึ่ง แล้วส่งข้อมูลออกมาเป็นชุด

คำว่า statistical สื่อว่าเราอาศัยพฤติกรรมโดยรวม ผู้ใช้แต่ละรายอาจต้องการส่งข้อมูลเต็มกำลังเป็นบางเวลา แต่โดยทั่วไปไม่ใช่ทุกคนที่ต้องการพร้อมกันตลอดเวลา เราจึงสามารถให้หลาย flow แชร์ link ที่มีความจุน้อยกว่าผลรวมความเร็วสูงสุดของทุก flow ได้ ตราบใดที่ภาระพร้อมกันไม่เกินความสามารถของ link บ่อยหรือยาวเกินไป

ลองนึกภาพ — ร้านอาหารที่ไม่จองโต๊ะให้ลูกค้าทุกคนทั้งวัน

ร้านอาหารรู้ว่ามีลูกค้าเป็นสมาชิกหนึ่งพันคน แต่ไม่ได้สร้างโต๊ะหนึ่งพันตัว เพราะสมาชิกไม่ได้มาพร้อมกันทั้งหมด ร้านจัดโต๊ะให้คนที่มาถึงจริง วิธีนี้ใช้พื้นที่คุ้มกว่าอย่างมาก

อย่างไรก็ตาม หากทุกคนมาถึงพร้อมกันตอนเที่ยง ร้านไม่ได้เสกโต๊ะเพิ่มได้ทันที ลูกค้าต้องรอ บางคนอาจเปลี่ยนร้าน และหากร้านรับคิวได้จำกัด คนที่มาทีหลังอาจไม่ได้บัตรคิว Statistical multiplexing ให้ประสิทธิภาพจากการแชร์ช่วงว่าง แต่รับความเสี่ยงของการรอเมื่อความต้องการมาพร้อมกัน

คิวเป็นผู้ตัดสินว่า “ใครได้ไปก่อน”

เมื่อ packet มาถึงเร็วกว่าที่ link ขาออกส่งได้ packet ต้องพักใน buffer และรออยู่ใน queue สวิตช์จึงต้องมีนโยบายเลือก packet ถัดไป การเลือกนี้ไม่ได้มีผลเพียงต่อความเร็วเฉลี่ย แต่มีผลต่อความยุติธรรม ความหน่วงของแต่ละ flow และความสามารถในการรองรับงานที่สำคัญต่างกัน

นโยบายคิว	แนวคิด	ข้อดี	จุดที่ต้องระวัง
FIFO	มาก่อนได้ส่งก่อน	เรียบง่ายและเข้าใจง่าย	packet ขนาดใหญ่หรือ flow ที่ส่งมากอาจทำให้ packet อื่นรอนาน
Round-Robin	วนให้สิทธิ์แต่ละ flow หรือแต่ละคิว	ป้องกัน flow หนึ่งยึดสิทธิ์ทั้งหมดได้ดีขึ้น	ถ้า packet มีขนาดต่างกัน การได้หนึ่ง packet เท่ากันไม่ได้แปลว่าได้ bandwidth เท่ากัน
Priority Queueing	ส่งคิวสำคัญก่อน	ลดเวลารอของงานเร่งด่วน	คิวลำดับต่ำอาจแทบไม่ได้ส่ง หากงานลำดับสูงเข้ามาตลอด
Weighted Scheduling	กำหนดสัดส่วนสิทธิ์ให้แต่ละคิว	ควบคุมการแบ่งทรัพยากรได้ละเอียดขึ้น	ต้องเลือกน้ำหนักให้สัมพันธ์กับเป้าหมายของระบบ

Statistical Multiplexing ในการทำงานจริง

สวิตช์ต้องทำมากกว่ารับแล้วส่งต่อ มันต้องเก็บ packet ที่ยังส่งไม่ได้ แยก packet เข้าคิว และเลือกว่าจะส่ง packet ใดก่อน เมื่ออัตราที่ packet เข้ามาสูงกว่าอัตราที่ link ระบายออกได้ต่อเนื่อง คิวจะยาวขึ้น ความหน่วงจะเพิ่ม และเมื่อ buffer เต็ม packet จะถูกทิ้ง อาการรวมนี้เป็นส่วนหนึ่งของภาวะ congestion

ประสิทธิภาพกับความแน่นอนดึงระบบไปคนละทาง

การจองทรัพยากรล่วงหน้าให้ความแน่นอน แต่เสี่ยงปล่อยทรัพยากรว่าง การแชร์ตามความต้องการจริงใช้ทรัพยากรคุ้มกว่า แต่เวลารอขึ้นกับผู้ใช้คนอื่น ไม่มีคำตอบใดชนะทุกด้าน การออกแบบจึงต้องถามว่า application ต้องการอะไร และระบบยอมรับความไม่แน่นอนได้มากเพียงใด

ตัวอย่างเช่น การสำรองไฟล์อาจยอมรอได้ หากช่วงนั้นมี Video Call ที่ต้องการส่งต่อเนื่อง แต่หากตั้ง priority ให้ Video Call สูงเสมอโดยไม่จำกัด การสำรองไฟล์อาจไม่เสร็จเสียที QoS จึงไม่ใช่การประกาศว่า traffic หนึ่ง “สำคัญกว่า” แล้วจบ แต่เป็นการกำหนดนโยบายพร้อมตรวจผลข้างเคียงที่เกิดกับ flow อื่น

ทำไม Internet ใช้ Statistical Multiplexing อย่างกว้างขวาง

Traffic ของคอมพิวเตอร์จำนวนมากมาเป็นช่วง หากกันเวลาและ bandwidth ตายตัวให้ทุก flow จะมีช่วงว่างมาก Statistical multiplexing เปิดให้ flow อื่นใช้ช่วงว่างนั้นได้ จึงเหมาะกับ packet switching และรองรับผู้ใช้จำนวนมากได้คุ้มค่า แต่ไม่ได้หมายความว่าจะดีกว่า FDM หรือ STDM ในทุกสถานการณ์ งานที่ต้องการอัตราคงที่หรือเวลาที่คาดการณ์ได้อาจได้ประโยชน์จากการจองทรัพยากรมากกว่า

หยุดคิดสักครู่

ถ้า link รองรับ 100 Mbps และมีผู้ใช้ 20 คนที่แต่ละคนอาจส่งได้สูงสุด 10 Mbps เราจำเป็นต้องสร้าง link 200 Mbps หรือไม่? คำตอบขึ้นอยู่กับว่าผู้ใช้ทั้ง 20 คนส่งเต็มกำลังพร้อมกันบ่อยเพียงใด และระบบยอมให้เกิดคิวได้นานแค่ไหน ค่าเฉลี่ยอย่างเดียวจึงยังไม่พอ เราต้องดูรูปแบบการพุ่งขึ้นของ traffic ด้วย

2ขนาดเครือข่ายตามพื้นที่ครอบคลุม

คำว่า LAN หรือ WAN ช่วยบอกขอบเขตโดยคร่าว แต่ไม่ควรใช้เป็นกล่องแข็งเกินไป เครือข่ายสมัยใหม่ซ้อนกันหลายระดับ เครือข่ายขององค์กรอาจมี LAN หลายแห่ง เชื่อมผ่าน WAN และใช้ระบบ cloud ที่ผู้ใช้มองไม่เห็นตำแหน่งจริงเลย

คำเรียก	ขอบเขตโดยทั่วไป	ตัวอย่าง	ประเด็นสำคัญ
LAN Local Area Network	พื้นที่จำกัด เช่น ห้อง อาคาร หรือบริเวณองค์กร	Ethernet และ Wi-Fi ภายในอาคาร	มักอยู่ภายใต้การดูแลขององค์กรเดียว และมีอัตราการส่งค่อนข้างสูง
MAN Metropolitan Area Network	ระดับเมืองหรือเขตเมือง	เครือข่ายที่เชื่อมหลายวิทยาเขตในเมืองเดียวกัน	เป็นคำแบ่งขอบเขตแบบดั้งเดิม ปัจจุบันเส้นแบ่งกับ WAN อาจไม่ชัด
WAN Wide Area Network	เชื่อมพื้นที่ห่างกันระดับภูมิภาค ประเทศ หรือระหว่างประเทศ	เครือข่ายเชื่อมสาขาองค์กร หรือโครงข่ายผู้ให้บริการ	ต้องพึ่งผู้ให้บริการหลายส่วน มีระยะทางและเขตการจัดการเข้ามาเกี่ยวข้อง
PAN Personal Area Network	รอบตัวบุคคลในระยะใกล้	Bluetooth ระหว่างโทรศัพท์ หูฟัง และอุปกรณ์สวมใส่	เน้นระยะใกล้ พลังงานต่ำ และอุปกรณ์ส่วนบุคคล
SAN Storage Area Network	เครือข่ายเฉพาะสำหรับเชื่อมระบบจัดเก็บข้อมูล	Server เชื่อม storage ภายใน data center	ชื่อคล้ายการแบ่งตามพื้นที่ แต่จริง ๆ แบ่งตามหน้าที่และชนิดของงาน

คำว่า System Area Network ก็ใช้ตัวย่อ SAN ได้ในบางบริบท โดยหมายถึงเครือข่ายประสิทธิภาพสูงที่เชื่อมระบบคอมพิวเตอร์ระยะใกล้ แต่ไม่ควรรวมความหมายนี้กับ Storage Area Network โดยไม่อธิบาย เพราะเป็นคนละแนวคิด แม้ใช้ตัวย่อเหมือนกัน

เหตุใดเรื่องขนาดเครือข่ายจึงมาอยู่ในบท Multiplexing

เมื่อขอบเขตเครือข่ายใหญ่ขึ้น จำนวนผู้ใช้และจำนวนองค์กรที่แชร์ทรัพยากรก็มักเพิ่มขึ้นด้วย LAN ภายในห้องอาจแชร์สื่อกันในกลุ่มเล็ก แต่ WAN ต้องรวม traffic จากหลาย LAN หลายองค์กร และหลาย application เข้าสู่ link ความจุสูง Multiplexing จึงไม่ได้เกิดเฉพาะในสายเส้นหนึ่ง แต่เกิดเป็นลำดับชั้นจากผู้ใช้ ไปยังอาคาร เมือง และโครงข่ายหลัก

อย่างไรก็ตาม ขนาดทางภูมิศาสตร์ไม่ได้กำหนดประสิทธิภาพโดยตรง LAN ไม่ได้เร็วกว่า WAN ทุกกรณี และ WAN ไม่ได้ช้าเพราะชื่อของมัน แต่ระยะทาง จำนวน hop เทคโนโลยี link การแชร์ทรัพยากร และนโยบายของผู้ให้บริการต่างหากที่ทำให้พฤติกรรมแตกต่างกัน

ลองนึกภาพ — จากซอยเล็กสู่ทางด่วน

รถจากบ้านหลายหลังรวมเข้าสู่ถนนในซอย ถนนจากหลายซอยรวมเข้าสู่ถนนใหญ่ และถนนใหญ่หลายสายรวมเข้าสู่ทางด่วน Traffic ของเครือข่ายก็คล้ายกัน ข้อมูลจากผู้ใช้จำนวนมากถูก multiplex รวมขึ้นไปตามลำดับ

ทางด่วนมีช่องทางมากกว่าซอย แต่ก็รับรถจากพื้นที่กว้างกว่า จึงไม่ได้ว่างเสมอไป และหากทางขึ้นจุดหนึ่งมีรถเข้ามาเร็วกว่าที่ทางด่วนรับได้ คิวจะเกิดก่อนขึ้นทาง เช่นเดียวกับ packet ที่รออยู่ใน buffer ก่อนออกสู่ link ขนาดใหญ่

หัวข้อเหล่านี้จะกลับมาอีกครั้งเมื่อใด

FDM, WDM และ TDM จะกลับมาใน Physical Layer ส่วน statistical multiplexing, queue และ congestion จะปรากฏตั้งแต่ switch และ router ไปจนถึง Transport Layer ขณะที่ LAN, WAN และ SAN จะช่วยบอกบริบทว่าเทคโนโลยีหนึ่งถูกออกแบบให้ทำงานในสภาพแวดล้อมแบบใด

3สรุปและขั้นตอนถัดไป

Multiplexing รวมข้อมูลหลาย flow ให้ใช้ทรัพยากรร่วมกัน ส่วน demultiplexing แยกข้อมูลกลับไปยังปลายทางที่ถูกต้อง
FDM แบ่งตามความถี่, WDM แบ่งตามความยาวคลื่น, STDM แบ่งตามตารางเวลา และ CDM แยกผู้ใช้ด้วย code
Statistical multiplexing จัดสรร link ตามข้อมูลที่มาถึงจริง จึงเหมาะกับ traffic แบบ bursty แต่ต้องใช้ buffer, queue และนโยบายเลือก packet
FIFO, Round-Robin, Priority และ weighted scheduling ให้ผลต่างกันในด้านความเรียบง่าย ความยุติธรรม และเวลารอ
เมื่อข้อมูลเข้ามาเร็วกว่าที่ link ส่งออกได้ คิวจะยาวขึ้น หากเกิดนานพอ buffer จะเต็มและ packet อาจถูกทิ้ง
LAN, MAN, WAN และ PAN แบ่งเครือข่ายตามขอบเขตโดยคร่าว ส่วน Storage Area Network แบ่งตามงานที่ทำมากกว่าพื้นที่ครอบคลุม

เปลี่ยนมุมมอง

Multiplexing ดูเหมือนเทคนิคแบ่งช่องทาง แต่ลึกลงไปแล้วมันคือการตัดสินใจว่าเราจะจัดการ “ช่วงว่าง” อย่างไร ระบบที่จองทรัพยากรล่วงหน้าปกป้องความแน่นอนของเจ้าของ ส่วนระบบที่เปิดให้คนอื่นยืมช่วงว่างไปใช้เพิ่มประสิทธิภาพโดยรวม แต่ต้องรับความไม่แน่นอนเมื่อเจ้าของหลายคนกลับมาใช้พร้อมกัน

จากการแบ่งทรัพยากร ไปสู่ความน่าเชื่อถือ

เมื่อหลาย flow แชร์ทรัพยากรเดียวกัน packet อาจต้องรอ มาช้า ถูกทิ้ง หรือมาถึงไม่ตรงจังหวะที่ application ต้องการ บทถัดไปจึงจะขยับจากคำถามว่า “แชร์อย่างไร” ไปสู่คำถามว่า “เมื่อการสื่อสารไม่เป็นไปตามที่หวัง เราจะตรวจพบและแก้ไขอย่างไร”

คำถามก่อนเข้าสู่บทถัดไป

ถ้า packet หายเพราะ buffer ของ router เต็ม ใครควรรับผิดชอบส่งใหม่—router ตัวที่ทิ้ง, ผู้ส่งต้นทาง หรือ application? คำตอบขึ้นอยู่กับข้อตกลงของแต่ละชั้น และจะพาเราเข้าสู่ Communication & Reliability โดยตรง