Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
KU EECS 780 – Communication Networks – End-to-End Transport © James P.G. Sterbenz ITTC Communication Networks The University of Kansas EECS 780 End-to-End Transport James P.G. Sterbenz Department of Electrical Engineering & Computer Science Information Technology & Telecommunications Research Center The University of Kansas [email protected] http://www.ittc.ku.edu/~jpgs/courses/nets 21 February 2011 rev. 11.0 © 2004–2007 James P.G. Sterbenz © 2004–2011 James P.G. Sterbenz ITTC © James P.G. Sterbenz End-to-End Transport Outline TL.1 TL.2 TL.3 TL.4 Transport services and interfaces End-to-end functions and mechanisms Internet transport protocols Multipoint communication and reliable multicast 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport –1– NET-TL-2 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz End-to-End Transport TL.1 Services and Interfaces TL.1 TL.2 TL.3 TL.4 Transport services and interfaces End-to-end functions and mechanisms Internet transport protocols Multipoint communication and reliable multicast 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-3 © James P.G. Sterbenz Transport Layer Hybrid Layer/Plane Cube management data plane L8 L7 L5 L4 L3 L2.5 L2 L1.5 L1 control plane social application session transport network virtual link link MAC physical 21 February 2011 p l a n e KU EECS 780 – Comm Nets – E2E Transport –2– Layer 4: end-to-end data transfer in data and control planes NET-TL-4 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transport Layer Motivation CPU CPU M app M app ES1 ES2 Why do we need a transport protocol? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-5 © James P.G. Sterbenz Transport Layer Ideal Network Model CPU R= ∞ CPU M app M app ES1 ES2 D=0 • Ideal network model – zero end-to-end delay – unlimited end-to-end bandwidth – perfect end-to-end transmission (no errors) But what? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport –3– NET-TL-6 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transport Layer Ideal Network Model and Motivation R CPU CPU M app M app ES1 ES2 D • Real networks are not ideal • Need an end-to-end protocol to – handle delay between communicating systems – control transmission rate for bandwidth-limited paths – perform error recovery 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-7 © James P.G. Sterbenz Transport Layer Transport Association Definition CPU network intermediate system CPU M app M app end system end system • Transport association between end systems – transport connection in the case of connection state – transport flow in the case of soft state or stateless – may be point-to-point or multipoint 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport –4– NET-TL-8 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transport Layer End-to-End Protocol application application session session transport network transport network network network link link link link end system intermediate system intermediate system end system network link intermediate system network • Transport protocol – is responsible for end-to-end transfer of a TPDU – note to Bell-heads: not layer 2 “transport network” 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-9 © James P.G. Sterbenz Transport Layer Service and Interfaces1 • Transport layer (L4) service to application layer (L7) • Transfer PDU E2E (end-to-end) – sender: encapsulate ADU into TPDU and transmit – receiver: receive TPDU and decapsulate into ADU • Multiplexing to application on end system • Optional reliability: – error checking/correction/retransmission – need depends on application – may be done application-to-application (A2A) • Flow control between end systems – assistance for network congestion control 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport –5– NET-TL-10 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transport Layer Service and Interfaces2 • Transport layer uses service of network layer (L3) – network layer establishes a path through the network • Transport mechanisms depend on L3 service – – – – datagrams vs. connections best effort vs. QOS error characteristics strength and symmetry of connectivity What are the Internet assumptions & service model? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-11 © James P.G. Sterbenz Transport Layer Types of Transport Protocols • Spectrum of transport protocol specialisation – general purpose • e.g. TCP (almost) – functionally partitioned • e.g. ISO TP0–4 – application-oriented • e.g. RTP – special purpose • Software engineering and implementation choice 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport –6– NET-TL-12 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transport Layer Service and Interfaces • Transport PDU encapsulates application data unit – ADU: application data unit – TPDU: transport protocol data unit (segment if TCP or UDP) – TPDU = header + ADU + opt. trailer (protocol dependent) application layer application layer ADU ADU transport layer H ADU transport layer T TPDU H network layer 21 February 2011 ADU T network layer KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-13 © James P.G. Sterbenz Transport Layer Functional Placement end system CPU end system mem mem TPDUs switch network interface frames packet CPU network interface frames • Transport layer functionality only in end system – host software or – network interface (NIC) 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport –7– NET-TL-14 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transport Layer End-to-End vs. Hop-by-Hop • Transport layer is E2E analog of HBH link layer – link layer (L2) transfers frames HBH – network layer (L3) determines the path of hops 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-15 © James P.G. Sterbenz End-to-End vs. Hop-by-Hop End-to-End Arguments • The end-to-end arguments (1st half) • Some functions can be correctly and completely implemented only at the endpoints of a communication association Providing these functions as features in the net is not possible • paraphrased from [Saltzer, Reed, Clark 1981] 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport –8– NET-TL-16 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz End-to-End vs. Hop-by-Hop End-to-End Arguments f -1 f g g′ f1 f1-1 g′′ f2 f2-1 g′′′ f3 f3-1 • Hop-by-Hop functions do not compose end-to-end – between HBH boundaries, function f is defeated (g) • e.g. error control: errors may occur within switches • e.g. encryption: cleartext within switches may be snooped • These functions must be done E2E – doing them HBH is redundant , and may lower performance 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-17 © James P.G. Sterbenz End-to-End vs. Hop-by-Hop End-to-End Arguments • The end-to-end arguments (2nd half) – performance enhancement corollary • Functions should be duplicated hop-by-hop if there is an overall (end-to-end) performance benefit paraphrased from [Saltzer, Reed, Clark 1981] 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport –9– NET-TL-18 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz End-to-End vs. Hop-by-Hop Hop-by-Hop Performance Enhancement • E2E Argument (1st half) says what must be E2E • HBH Performance enhancement (2nd half) – functions should duplicated HBH if overall E2E benefit • Analysis is required to determine cost/benefit – added functionality in net may add overhead not offset 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-19 © James P.G. Sterbenz End-to-End vs. Hop-by-Hop Performance Enhancement Example • E2E vs. HBH error control for reliable communication – E2E argument says error control must be done E2E • e.g. E2E ARQ (error check code and retransmit if necessary – but should HBH error control also be done? 100 m wireless LAN 15 000 km fiber WAN Univ. Kansas 21 February 2011 100 m fiber LAN Univ. Sydney KU EECS 780 – Comm Nets – E2E Transport – 10 – NET-TL-20 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz End-to-End vs. Hop-by-Hop Performance Enhancement Example • E2E vs. HBH error control for reliable communication – E2E argument says error control must be done E2E • e.g. E2E ARQ (error check code and retransmit if necessary – but should HBH error control also be done? 100 m wireless LAN 15 000 km fiber WAN 100 m fiber LAN Univ. Kansas Univ. Sydney • Effect of high loss rate on wireless link – ~250 ms RTT retransmission for every corrupted packet • Error control on wireless link reduces to ~1μs RTT – shorter control loop results in dramatically lower E2E delay 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-21 © James P.G. Sterbenz End-to-End vs. Hop-by-Hop Security • Security and information assurance must be E2E – information in the clear inside network nodes not secure • Justification for HBH security mechanisms – link security may be good enough for some • wireless link encryption for WEP (wire equivalent protection) note: 802.11 WEP not strong enough – subnetwork or edge-to-edge security for VPNs • assures enterprise security across open network… …but not individual flow security 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 11 – NET-TL-22 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz End-to-End vs. Hop-by-Hop E2E Argument Misinterpretations • E2E-only – do not replicate E2E services or features HBH – violates HBH performance enhancement corollary • Everything E2E – implement as many services or feature E2E as possible – misstatement of Internet design philosophy: simple stateless network for resilience and survivability 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-23 © James P.G. Sterbenz End-to-End Transport TL.2 Functions and Mechanisms TL.1 Transport services and interfaces TL.2 End-to-end functions and mechanisms TL.2.1 TL.2.2 TL.2.3 TL.2.4 Framing and multiplexing State management and transfer modes Reliability and error control Transmission control TL.3 Internet transport protocols TL.4 Multipoint communication and reliable multicast 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 12 – NET-TL-24 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Functions and Mechanisms TL.2.1 Framing and Multiplexing TL.1 Transport services and interfaces TL.2 End-to-end functions and mechanisms TL.2.1 TL.2.2 TL.2.3 TL.2.4 Framing and multiplexing State management and transfer modes Reliability and error control Transmission control TL.3 Internet transport Protocols TL.4 Multipoint communication and reliable multicast 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-25 © James P.G. Sterbenz E2E Framing Structure and Fields • Delimits TPDU – physical layer is coded bit stream – receiver needs to delimit frames • Header: how to process the TPDU – protocol processing options – demultiplexing fields: destination application identifier • typically called port (Internet protocol suite terminology) • ISO TSAPA: transport service access point address • Trailer: what to do with the TPDU once arrived – error check (CRC or checksum) for reliability • most transport protocols have this in the header (e.g. TCP) 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 13 – NET-TL-26 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Framing Application Layer Framing ADU ADU TPDU TPDU TPDU TPDU MTU transport layer fragmentation ADU ADU TPDU ADU TPDU ADU TPDU TPDU application layer framing • ALF (application layer framing) – matching ADU to TPDU structure – eliminates fragementation/reassembly overhead – may be more efficient TPDU structure 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-27 © James P.G. Sterbenz E2E Multiplexing Application and Transport Layer transport muxing • Multiplexing appx pa ADU – application • inter-application coordination – transport pb ADU appy appz pc ADU host1 TPDU TPDU a3 pa ADU a4 pc ADU host2 TPDU a4 pb ADU network muxing • applications sharing network interface – network a3 pa ADU NPDUs a4 pb ADU network demuxing • end systems sharing switch a3 pa ADU TPDU host3 – MAC and link a4 pb ADU a4 pc ADU TPDU TPDU host4 • interfaces sharing medium 21 February 2011 a4 pc ADU appa pa ADU appb pb ADU pc ADU appc transport demuxing KU EECS 780 – Comm Nets – E2E Transport – 14 – NET-TL-28 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Functions and Mechanisms TL.2.2 Transfer Modes and State Management TL.1 Transport services and interfaces TL.2 End-to-end functions and mechanisms TL.2.1 TL.2.2 TL.2.3 TL.2.4 Framing and multiplexing State management and transfer modes Reliability and error control Transmission control TL.3 Internet transport protocols TL.4 Multipoint communication and reliable multicast 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-29 © James P.G. Sterbenz E2E Functions and Mechanisms Transport Protocol Service Categories • Transfer mode – – – – connectionless datagram connection-oriented transaction continuous media streaming • Reliability – loss tolerance • Delivery order – ordered – unordered • Traffic characteristics 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 15 – NET-TL-30 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E State Management Control Loops Alternatives? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-31 © James P.G. Sterbenz E2E State Management Control Loops parameters • Open loop data – control parameters – no feedback Open loop Alternative? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 16 – NET-TL-32 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E State Management Control Loops parameters • Open loop data – control parameters – no feedback Open loop initial parameters • Closed loop E2E feedback data – initial parameters – feedback Closed loop • dynamic adaptation 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-33 ITTC © James P.G. Sterbenz E2E State Management Control Loops parameters • Open loop data – control parameters – no feedback Open loop initial parameters • Closed loop data – initial parameters – feedback Closed loop initial parameters E2E feedback HBH feedback • dynamic adaptation data • Closed loop with HBH feedback initial parameters data • Nested control loops sender 21 February 2011 E2E feedback Closed loop with HBH feedback E2E feedback HBH loop Nested control loops KU EECS 780 – Comm Nets – E2E Transport – 17 – HBH loop receiver NET-TL-34 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E State Management Open- vs. Closed-Loop • Open-loop control – use when possible to eliminate control loop latency • particularly for high bandwidth-×-delay product networks • Closed-loop feedback control – use when necessary, e.g. reliability – aggressiveness of closed-loop control • rapid enough to system converges • not too aggressive avoid instability and oscillations 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-35 © James P.G. Sterbenz E2E State Management Hard vs. Soft • Hard state – explicitly established and released – deterministic – delay to establish and memory to maintain Alternative? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 18 – NET-TL-36 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E State Management Hard vs. Soft • Hard state – explicitly established and released – deterministic – delay to establish and memory to maintain • Soft state – established and removed as needed and memory allows – robust to failures – if not explicitly established, delay to accumulate 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-37 © James P.G. Sterbenz E2E State Management Hard vs. Soft • Hard state – explicitly established and released – deterministic – delay to establish and memory to maintain • Soft state – established and removed as needed and memory allows – robust to failures – if not explicitly established, delay to accumulate • Stateless – (essentially) no state 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 19 – NET-TL-38 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E State Management Assumed Initial Conditions • Improve performance of closed-loop control – rapid convergence to steady state • Assume initial conditions – normal or common case – past behaviour – current network state (requires network dials) 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-39 © James P.G. Sterbenz E2E State Management Impact of Data Rate • Transmission delay proportional to data rate tRTT SETUP What happens when data rate increases? tp td ACK RELEASE slow 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 20 – NET-TL-40 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E State Management Impact of Data Rate • Transmission delay proportional to data rate • Connection shortening tRTT SETUP SETUP tp + transmission delay decreases – but signalling delay constant td ACK RELEASE ACK RELEASE slow 21 February 2011 fast KU EECS 780 – Comm Nets – E2E Transport NET-TL-41 ITTC © James P.G. Sterbenz E2E State Management Impact of Data Rate • Transmission delay proportional to data rate • Connection shortening tRTT SETUP SETUP ~1.5tRTT SETUP tp tp + transmission delay decreases – but signalling delay constant ~2.5tRTT • E2E signalling ACK td→0 td ACK – significant fraction of time – connection shortening not proportional to Δ date rate RELEASE RELEASE ACK RELEASE slow 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 21 – fast high-speed NET-TL-42 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E State Management Impact of Latency SETUP • Transmission delay and path delay proportional to length What happens when length increases? ACK RELEASE short links 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-43 ITTC © James P.G. Sterbenz E2E State Management Impact of Path Length SETUP • Transmission delay and path delay proportional to length • Connection lengthening – path delay increases – signalling delay increases SETUP ACK RELEASE • E2E signalling – state open longer – denial of resource to others ACK RELEASE short links 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 22 – long links NET-TL-44 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Transfer Modes Alternatives • End-to-end transfer modes – – – – datagram connection stream transaction 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-45 © James P.G. Sterbenz E2E Transfer Modes Datagram • Independent PDUs – each has fully self-describing header – no end-to-end flow state needed to forward 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 23 – tp+td NET-TL-46 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Transfer Modes Connection • Explicit connection setup – 3-way handshake SETUP / CONNECT / ACK why? SETUP ~tRTT ~1.5tRTT CONNECT ACK tr ~tRTT RELEASE 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-47 © James P.G. Sterbenz E2E Transfer Modes Connection • Explicit connection setup – 3-way handshake SETUP / CONNECT / ACK – both side have been acknowledged SETUP ~tRTT ~1.5tRTT CONNECT ACK tr ~tRTT • Data flow – PDUs need connection or flow identifier • used by nodes to look up state • Release of resources and state – explicit RELEASE – time out state 21 February 2011 RELEASE KU EECS 780 – Comm Nets – E2E Transport – 24 – NET-TL-48 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Transfer Modes Transport and Network Connections • Transport connections – required over end system end system transport layer transport layer setup-req • connectionless L3 • path with any connectionless subnetwork SETUP network layer connection-oriented network network layer CONNECT network layer connection SETUP transport layer transport layer CONNECT connectionless network network layer – may exploit network layer transport layer connection • connection-oriented L3 SETUP transport layer transport layer CONNECT connectionless subnetwork network layer network layer connection-oriented subnetwork heterogeneous subnetworks 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-49 ITTC © James P.G. Sterbenz E2E Transfer Modes Connection State Machine • Connection State Machine – send/receive paths • States – idle – establishing originate SETUP request establishing issue SETUP – initialising – steady state – closing requested issue CONNECT initialising CONNECT ACK from net from net • install state • state convergence receive SETUP from net idle RELEASE from app steady -state closing issue RELEASE RELEASE from net closing issue RELEASE • release state 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 25 – NET-TL-50 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Transfer Modes Media Stream SETUP • Various mechanisms to start stream CONNECT – explicit client request – server push – may or may not establish connection state REQUEST • Data flow – synchronisation and control • embedded or • out-of-band More about this in Lecture MS 21 February 2011 RELEASE KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-51 © James P.G. Sterbenz E2E Transfer Modes Transaction • Transaction request REQUEST – may or may not establish connection state – explicit release of connection state optional tr RESPONSE • Data returned • Overlap to reduce latency – request/response with control RELEASE • Recall: this is not how HTTP over TCP works 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 26 – NET-TL-52 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Functions and Mechanisms TL.2.3 Reliability and Error Control TL.1 Transport services and interfaces TL.2 End-to-End functions and mechanisms TL.2.1 TL.2.2 TL.2.3 TL.2.4 Framing and multiplexing State management and transfer modes Reliability and error control Transmission control TL.3 Internet transport protocols TL.4 Multipoint communication and reliable multicast 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-53 © James P.G. Sterbenz E2E Error Control Types of Errors What are the types of errors? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 27 – NET-TL-54 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Types of Errors • Bit errors • Packet errors types? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-55 © James P.G. Sterbenz E2E Error Control Types of Errors • Bit errors • Packet errors – – – – – – packet loss fragment loss burst loss packet misordering packet insertion packet duplication 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 28 – NET-TL-56 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Causes of Bit Errors • Bit errors causes? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-57 © James P.G. Sterbenz E2E Error Control Causes of Bit Errors • Bit errors – flaky hardware – wireless channels • noise and interference – optical channels • long-haul fiber links engineered on margin with FEC • control of amplifier and regenerator cost More in lecture PL 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 29 – NET-TL-58 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Causes of Packet Loss • Packet loss causes? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-59 © James P.G. Sterbenz E2E Error Control Causes of Packet Loss • Packet loss – network buffer overflow or intentional drop more in lecture TQ – transport protocol packet discard when bit error 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 30 – NET-TL-60 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Causes of Packet Loss • Packet loss – network buffer overflow or intentional drop more in lecture TQ – transport protocol packet discard when bit error • Packet fragment loss causes? impact? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-61 © James P.G. Sterbenz E2E Error Control Causes of Packet Loss • Packet loss – network buffer overflow or intentional drop more in lecture TQ – transport protocol packet discard when bit error • Packet fragment loss – loss of a piece of a fragmented packet – effect: error multiplication • loss of a fragment in net generally results in entire packet loss 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 31 – NET-TL-62 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Causes of Packet Burst Loss • Packet burst loss causes? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-63 © James P.G. Sterbenz E2E Error Control Causes of Packet Burst Loss • Packet burst loss – network buffer overflow during congestion • with high rate flow having adjacent (non-interleaved) packets more in lecture TQ – wireless channel fades more in lecture PL 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 32 – NET-TL-64 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Causes of Packet Misordering • Packet misordering causes? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-65 © James P.G. Sterbenz E2E Error Control Causes of Packet Misordering • Packet misordering – multiple paths through switch or network – non-deterministic paths through switch or network – path reconfiguration • after failure • due to mobility • due to load balancing more in lecture NL 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 33 – NET-TL-66 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Causes of Packet Insertion • Packet insertion meaning? causes? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-67 © James P.G. Sterbenz E2E Error Control Causes of Packet Insertion • Packet insertion – undetectable header error • packet appears that was destined elsewhere – long packet life • packet with same destination and sequence number still in net 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 34 – NET-TL-68 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Causes of Packet Duplication • Packet duplication causes? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-69 © James P.G. Sterbenz E2E Error Control Causes of Packet Duplication • Packet duplication – retransmission but original still arrives 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 35 – NET-TL-70 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Impact of High Speed • Bandwidth-×-delay product increases – fixed duration error event larger relative impact – closed-loop reaction occurs later in terms of # bits sent • Sequence numbers – sequence numbers wrap if sequence space too small • causes packet duplication 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-71 © James P.G. Sterbenz E2E Error Control ARQ Closed Loop Retransmission • Automatic repeat request (ARQ) – PDUs are retransmitted for reliable transfer • Acknowledgments are used to request retransmission alternatives? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 36 – NET-TL-72 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control ARQ Closed Loop Retransmission • Automatic repeat request (ARQ) – PDUs are retransmitted for reliable transfer • Acknowledgments are used to request retransmission – ACK: positive acknowledgement – NAK (or NACK): negative acknowledgement tradeoff? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-73 © James P.G. Sterbenz E2E Error Control ARQ Closed Loop Retransmission • Automatic repeat request (ARQ) – PDUs are retransmitted for reliable transfer • Acknowledgments are used to request retransmission – ACK: positive acknowledgement – NAK (or NACK): negative acknowledgement – tradeoff between error rate and predictability Simplest ARQ mechanism? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 37 – NET-TL-74 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Stop-and-Wait • Each TPDU is acknowledged 0 1 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-75 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Stop-and-Wait • Each TPDU is acknowledged 0 0 2 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 38 – NET-TL-76 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Stop-and-Wait • Each TPDU is acknowledged 0 – subsequent TPDU waits on previous ACK disadvantages? 0 A0 3 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-77 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Stop-and-Wait • Each TPDU is acknowledged 0 – subsequent TPDU waits on previous ACK • significant delay and underutilisation • 1 RTT per TPDU • serious penalty in long-delay environment 0 A0 tack 1 4 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 39 – NET-TL-78 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Stop-and-Wait • Each TPDU is acknowledged 0 – subsequent TPDU waits on previous ACK • significant delay and underutilisation • 1 RTT per TPDU • serious penalty in long-delay environment 0 A0 tack 1 – sender timer tack fires if ACK not received issues? 5 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-79 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Stop-and-Wait • Each TPDU is acknowledged 0 – subsequent TPDU waits on previous ACK • significant delay and underutilisation • 1 RTT per TPDU • serious penalty in long-delay environment 0 A0 tack 1 – sender timer tack fires if ACK not received • too conservative: issues? • too aggressive: issues? 1 6 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 40 – NET-TL-80 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Stop-and-Wait • Each TPDU is acknowledged 0 – subsequent TPDU waits on previous ACK • significant delay and underutilisation • 1 RTT per TPDU • serious penalty in long-delay environment 0 A0 tack 1 – sender timer tack fires if ACK not received • too conservative: unnecessary delay • too aggressive: spurious retransmissions 1 1 7 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-81 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Stop-and-Wait • Each TPDU is acknowledged 0 – subsequent TPDU waits on previous ACK • significant delay and underutilisation • 1 RTT per TPDU • serious penalty in long-delay environment 0 A0 tack 1 – sender timer tack fires if ACK not received • too conservative: unnecessary delay • too aggressive: spurious retransmissions How can we do better? 1 1 A1 8 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 41 – NET-TL-82 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Go-Back-n • Go-back-n : pipeline transmissions 0 1 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-83 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Go-Back-n • Go-back-n : pipeline transmissions 0 + multiple TPDUs simultaneously in flight 1 0 A0 2 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 42 – NET-TL-84 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Go-Back-n • Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight • TPDUs are sequentially acknowledged 0 tack 1 0 2 1 A0 A1 3 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-85 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Go-Back-n • Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight • TPDUs are sequentially acknowledged how is TPDU loss detected? 0 tack A0 1 0 2 1 3 A1 4 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 43 – NET-TL-86 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Go-Back-n • Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight • TPDUs are sequentially acknowledged o previous ACK retransmitted for • subsequent TPDUs after loss • out of sequence TPDU 0 tack A0 A1 1 0 2 1 3 4 A1 5 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-87 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Go-Back-n • Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight • TPDUs are sequentially acknowledged o previous ACK retransmitted for • subsequent TPDUs after loss • out of sequence TPDU o sender timer fires if ACK not received 0 tack A0 A1 1 0 2 1 3 4 5 A1 A1 implication? 6 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 44 – NET-TL-88 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Go-Back-n • Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight • TPDUs are sequentially acknowledged o previous ACK retransmitted for • subsequent TPDUs after loss • out of sequence TPDU o sender timer fires if ACK not received • reset transmission beginning at lost TPDU 0 tack A0 A1 1 0 2 1 3 4 5 A1 2 A1 A1 7 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-89 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Go-Back-n • Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight • TPDUs are sequentially acknowledged o previous ACK retransmitted for • subsequent TPDUs after loss • out of sequence TPDU o sender timer fires if ACK not received • reset transmission beginning at lost TPDU 0 tack A0 A1 1 0 2 1 3 4 5 A1 2 A1 3 2 A1 A2 8 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 45 – NET-TL-90 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Go-Back-n • Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight • TPDUs are sequentially acknowledged o previous ACK retransmitted for • subsequent TPDUs after loss • out of sequence TPDU o sender timer fires if ACK not received • reset transmission beginning at lost TPDU 0 tack A0 A1 1 0 2 1 3 4 5 A1 2 A1 3 2 A1 4 3 A2 A3 9 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-91 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Go-Back-n • Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight • TPDUs are sequentially acknowledged o previous ACK retransmitted for • subsequent TPDUs after loss • out of sequence TPDU o sender timer fires if ACK not received • reset transmission beginning at lost TPDU 0 tack A0 A1 1 0 2 1 3 4 5 A1 2 A1 3 2 A1 4 3 5 4 A2 A3 A4 10 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 46 – NET-TL-92 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Go-Back-n • Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight • TPDUs are sequentially acknowledged o previous ACK retransmitted for • subsequent TPDUs after loss • out of sequence TPDU o sender timer fires if ACK not received • reset transmission beginning at lost TPDU 0 tack A0 A1 1 0 2 1 3 4 5 A1 2 A1 3 2 A1 4 3 5 4 A2 A3 5 6 A4 A5 11 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-93 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Go-Back-n • Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight • TPDUs are sequentially acknowledged o previous ACK retransmitted for • subsequent TPDUs after loss • out of sequence TPDU o sender timer fires if ACK not received • reset transmission beginning at lost TPDU disadvantages? 0 tack A0 A1 1 0 2 1 3 4 5 A1 2 A1 3 2 A1 4 3 5 4 A2 A3 A4 5 6 6 A5 12 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 47 – NET-TL-94 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Go-Back-n • Go-back-n : pipeline transmissions + multiple TPDUs simultaneously in flight • TPDUs are sequentially acknowledged o previous ACK retransmitted for • subsequent TPDUs after loss • out of sequence TPDU o sender timer fires if ACK not received • reset transmission beginning at lost TPDU – significant loss penalty for high bw-×-delay • go back and retransmit all since loss • many unneeded retransmissions • significant additional delay 21 February 2011 0 tack A0 A1 1 0 2 1 3 4 5 A1 2 A1 3 2 A1 4 3 5 4 A2 A3 5 6 A4 6 A5 13 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-95 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Go-Back-n • Optimisation possible for go-back-n? 0 tack A0 A1 1 0 2 1 3 4 5 A1 2 A1 3 2 A1 4 3 5 4 A2 A3 A4 5 6 6 A5 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 48 – NET-TL-96 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Go-Back-n • Optimisation go-back-n timer the only way to detect loss? 0 tack A0 A1 1 0 2 1 3 4 5 A1 2 A1 3 2 A1 4 3 5 4 A2 A3 5 6 A4 6 A5 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-97 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Fast Retransmit • Fast retransmit 0 – optimisation for go-back-n 1 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 49 – NET-TL-98 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Fast Retransmit • Fast retransmit 0 – optimisation for go-back-n 0 1 A0 2 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-99 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Fast Retransmit • Fast retransmit 0 – optimisation for go-back-n tack 1 0 2 1 A0 A1 3 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 50 – NET-TL-100 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Fast Retransmit • Fast retransmit 0 – optimisation for go-back-n tack A0 1 0 2 1 3 A1 4 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-101 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Fast Retransmit • Fast retransmit 0 – optimisation for go-back-n • Assume several duplicate ACKs are loss tack A0 A1 1 0 2 1 3 4 A1 5 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 51 – NET-TL-102 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Fast Retransmit • Fast retransmit 0 – optimisation for go-back-n • Assume several duplicate ACKs are loss o even if timer hasn’t yet fired tack A0 A1 1 0 2 1 3 4 5 A1 A1 2 6 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-103 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Fast Retransmit • Fast retransmit 0 – optimisation for go-back-n • Assume several duplicate ACKs are loss o even if timer hasn’t yet fired + recovers from loss more quickly tack A0 A1 1 0 2 1 3 4 5 A1 A1 A1 2 3 2 A2 7 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 52 – NET-TL-104 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Fast Retransmit • Fast retransmit 0 – optimisation for go-back-n • Assume several duplicate ACKs are loss o even if timer hasn’t yet fired + recovers from loss more quickly tack A0 A1 1 0 2 1 3 4 5 A1 A1 A1 2 3 2 4 3 A2 A3 8 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-105 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Fast Retransmit • Fast retransmit 0 – optimisation for go-back-n • Assume several duplicate ACKs are loss o even if timer hasn’t yet fired + recovers from loss more quickly tack A0 A1 1 0 2 1 3 4 5 A1 A1 A1 2 3 2 4 3 5 4 A2 A3 A4 9 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 53 – NET-TL-106 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Fast Retransmit • Fast retransmit 0 – optimisation for go-back-n • Assume several duplicate ACKs are loss o even if timer hasn’t yet fired + recovers from loss more quickly tack A0 A1 1 0 2 1 3 4 5 A1 A1 A1 2 3 2 4 3 5 4 A2 A3 5 6 A4 A5 10 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-107 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Fast Retransmit • Fast retransmit 0 – optimisation for go-back-n • Assume several duplicate ACKs are loss o even if timer hasn’t yet fired + recovers from loss more quickly tack A0 A1 1 0 2 1 3 4 5 A1 A1 A1 2 3 2 4 3 5 4 A2 A3 A4 5 6 6 A5 11 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 54 – NET-TL-108 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Fast Retransmit • Fast retransmit 0 – optimisation for go-back-n • Assume several duplicate ACKs are loss o even if timer hasn’t yet fired + recovers from loss more quickly – still suffers from go-back-n inefficiencies tack A0 A1 1 0 2 1 3 4 5 A1 A1 A1 2 3 2 4 3 5 4 A2 A3 5 6 A4 6 A5 12 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-109 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Delayed ACK • Delayed ACK o optimisation for go-back-n • Aggregate several ACKs + reduces ACK traffic + allows some receiver resequencing • within ACK aggregation quantum 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 55 – NET-TL-110 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Go-Back-n • Go-back-n ̶ ̶ fast retransmit and delayed ACK help slightly but still significant delay penalty for losses Alternative? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-111 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Selective Repeat • Go-back-n ̶ ̶ fast retransmit and delayed ACK help slightly significant delay penalty for losses • Alternative − don’t go back: selective repeat 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 56 – NET-TL-112 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Selective Repeat • Selective repeat 0 o all TPDUs acknowledged 1 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-113 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Selective Repeat • Selective repeat 0 o all TPDUs acknowledged 1 0 A0 2 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 57 – NET-TL-114 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Selective Repeat • Selective repeat 0 o all TPDUs acknowledged tack 1 0 2 1 A0 A1 3 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-115 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Selective Repeat • Selective repeat 0 o all TPDUs acknowledged tack A0 1 0 2 1 3 A1 4 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 58 – NET-TL-116 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Selective Repeat • Selective repeat 0 o all TPDUs acknowledged – Missequenced TPDUs o acknowledged and held at receiver tack A0 A1 1 0 2 1 3 3 4 A3 5 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-117 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Selective Repeat • Selective repeat 0 o all TPDUs acknowledged • Missequenced TPDUs o TPDUs held and reordered at receiver – increases receiver complexity tack A0 A1 1 0 2 1 3 3 4 5 43 A3 A4 6 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 59 – NET-TL-118 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Selective Repeat • Selective repeat 0 o all TPDUs acknowledged • Missequenced TPDUs o TPDUs held and reordered at receiver – increases receiver complexity • Lost TPDUs o selectively retransmitted tack A0 A1 1 0 2 1 3 3 4 5 A3 A4 43 543 2 A5 7 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-119 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Selective Repeat • Selective repeat 0 o all TPDUs acknowledged • Missequenced TPDUs o TPDUs held and reordered at receiver – increases receiver complexity • Lost TPDUs o selectively retransmitted + no go-back-n latency penalty – requires more receiver buffer space tack A0 A1 1 0 2 1 3 3 4 5 A3 A4 A5 43 543 2 6 5432 A2 8 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 60 – NET-TL-120 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Selective Repeat • Selective repeat 0 o all TPDUs acknowledged • Missequenced TPDUs o TPDUs held and reordered at receiver – increases receiver complexity • Lost TPDUs o selectively retransmitted + no go-back-n latency penalty – requires more receiver buffer space tack A0 A1 1 0 2 1 3 3 4 5 A3 A4 A5 43 543 2 6 5432 7 6 A2 A6 9 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-121 © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Selective Repeat • Selective repeat 0 o all TPDUs acknowledged • Missequenced TPDUs o TPDUs held and reordered at receiver – increases receiver complexity • Lost TPDUs o selectively retransmitted + no go-back-n latency penalty – requires more receiver buffer space tack A0 A1 1 0 2 1 3 3 4 5 A3 A4 A5 43 543 2 6 5432 7 6 8 7 A2 A6 A7 10 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 61 – NET-TL-122 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Selective Repeat • Selective repeat 0 o all TPDUs acknowledged • Missequenced TPDUs o TPDUs held and reordered at receiver – increases receiver complexity • Lost TPDUs o selectively retransmitted + no go-back-n latency penalty – requires more receiver buffer space • A2A Delay and bandwidth reduced tack 1 0 2 1 3 A0 3 A1 4 5 43 A3 543 2 A4 A5 6 5432 7 6 8 7 A2 8 A6 9 A7 A8 11 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-123 ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Periodic State • Selective ACK blocks 0 o bit vectors can aggregate ACKs + significant reduction in control packets + simple receiver implementation possible ~1.5tRTT 1 0 2 1 3 3 4 A01_3 5 43 6 543 7 6543 765543 2 A4567 A2 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 62 – 8 7–2 9 8 9 NET-TL-124 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Impact of Increasing Data Rate • Bandwidth-×-delay product increases – fixed duration error event larger relative impact – reaction to errors decreases in terms of number of bits sent • Sequence numbers – sequence numbers wrap if sequence space too small • causes packet misinsertion 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-125 ITTC © James P.G. Sterbenz E2E Error Control Closed Loop Retransmission: Comparison 0 0 0 tack A0 A0 tack A1 1 0 2 1 3 tack A0 A1 4 5 1 A2 1 A3 A4 A1 21 February 2011 A5 0 2 1 2 A4 4 3 A5 5 4 3 5 6 0 2 1 3 3 4 4 43 A01_3 543 2 5 43 6 543 7 6543 76543 6 7 6 2 8 7 8 7–2 8 A4567 9 8 A2 A7 1 3 A6 6 ~1.5tRTT 3 5 2 A1 1 A3 A1 A1 0 0 1 9 A2 9 A8 KU EECS 780 – Comm Nets – E2E Transport – 63 – NET-TL-126 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Open Loop • Open loop error control o some applications do not need guaranteed reliability examples? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-127 © James P.G. Sterbenz E2E Error Control Open Loop • Open loop error control o some applications do not need guaranteed reliability • applications that are tolerant to some loss • real-time or interactive delay requirements + eliminates control loop latency for recovery – – Mechanisms? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 64 – NET-TL-128 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Open Loop • Open loop error control o some applications do not need guaranteed reliability • applications that are tolerant to some loss • real-time or interactive delay requirements + eliminates control loop latency for recovery – – • Forward error correction (FEC) – block codes: per block recovery – convolutional codes: continuous over window – erasure codes: coding over redundant packets disadvantages? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-129 © James P.G. Sterbenz E2E Error Control Open Loop • Open loop error control o some applications do not need guaranteed reliability • applications that are tolerant to some loss • real-time or interactive delay requirements + eliminates control loop latency for recovery – requires additional end-systems bandwidth & processing – requires additional network bandwidth • Forward error correction (FEC) – block codes: per block recovery – convolutional codes: continuous over window – erasure codes: coding over redundant packets 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 65 – NET-TL-130 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Error Control Hybrid Open/Closed-Loop Control • Hybrid open loop with closed loop when necessary why? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-131 © James P.G. Sterbenz E2E Error Control Hybrid Open/Closed-Loop Control • • • • Hybrid open loop with closed loop when necessary Statistical error bound with FEC Retransmission only when FEC doesn’t correct Appropriate for – high latency and bandwidth-×-delay paths – asymmetric bandwidth paths – intermittent and episodically connected channels 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 66 – NET-TL-132 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Functions and Mechanisms TL.2.4 Transmission Control TL.1 Transport services and interfaces TL.2 End-to-end functions and mechanisms TL.2.1 TL.2.2 TL.2.3 TL.2.4 Framing and multiplexing State management and transfer modes Reliability and error control Transmission control TL.3 Internet transport protocols TL.4 Multipoint communication and reliable multicast 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-133 © James P.G. Sterbenz E2E Transmission Control Definitions: Flow Control • Flow control – control transmission to avoid overwhelming receiver – end-to-end control 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 67 – NET-TL-134 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Transmission Control Definitions: Congestion Control • Flow control – control transmission to avoid overwhelming receiver – end-to-end control • Congestion control – control transmission to avoid overwhelming network paths 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-135 © James P.G. Sterbenz E2E Transmission Control Definitions: Implicit vs. Explicit • Flow control – control transmission to avoid overwhelming receiver – end-to-end control • Congestion control – control transmission to avoid overwhelming network paths – network control with end-to-end assistance (throttling) • Types – explicit relies on congestion information from nodes • allows decoupling of error, flow, and congestion mechanisms – implicit assumes loss is congestion • bad assumption in wireless networks 21 February 2011 (see [Krishnan 2004]) KU EECS 780 – Comm Nets – E2E Transport – 68 – NET-TL-136 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Transmission Control Impact of Increasing Data Rate • Bandwidth-×-delay product increases – response to an event happens after more bits transferred – it may be too late to react • all bits causing problem may already be transmitted • cause of problem may have already gone away Alternative? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-137 © James P.G. Sterbenz E2E Transmission Control Open-Loop Rate Control admission control • Initial negotiation – admission control limits traffic to available resources 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 69 – NET-TL-138 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Transmission Control Open-Loop Rate Control admission control receiver negotiation • Initial negotiation – admission control limits traffic to available resources – receiver negotiates what it can accept (flow control) 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-139 © James P.G. Sterbenz E2E Transmission Control Open-Loop Rate Control admission control rate scheduling rate policing receiver negotiation conforming traffic • Initial negotiation – admission control limits traffic to available resources – receiver negotiates what it can accept (flow control) • Steady state – policing enforces traffic contract from transmitter 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 70 – NET-TL-140 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Transmission Control Open-Loop Rate Control admission control rate scheduling rate policing receiver negotiation conforming traffic excess traffic • Initial negotiation – admission control limits traffic to available resources – receiver negotiates what it can accept (flow control) • Steady state – policing enforces traffic contract from transmitter • excess traffic may be marked and passed if capacity available 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-141 © James P.G. Sterbenz E2E Transmission Control Open-Loop Rate Control Parameters rp uniform ra bursty time • Main parameters – peak rate rp – average rate ra – burstiness (peak to average ratio or max burst size) • Derived parameters – jitter 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 71 – NET-TL-142 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Transmission Control Open-Loop Rate Control: Connections • Requires connection establishment (dis)advantages? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-143 © James P.G. Sterbenz E2E Transmission Control Open-Loop Rate Control: Connections • Requires connection establishment – overhead and delay for connection setup • optimistic establishment or fast reservations ameliorate + QOS guarantees possible in steady state + feedback control loops not needed during transmission + network stability less dependent on congestion control • unless resources significantly overbooked – some connections may not be admitted lecture TQ 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 72 – NET-TL-144 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Transmission Control Closed-Loop Flow and Congestion Control congestion control flow control network packet scheduling • Flow control – sender–receiver • Congestion control – sender–network • Packet scheduling Lecture TQ 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-145 © James P.G. Sterbenz E2E Transmission Control Closed-Loop Flow Control • Feedback from receiver to limit rate • Window to limit amount of unacknowledged data – static window • based on initial negotiation or assumption – dynamic window • renegotiated based on receiver buffer availability • may be combined with congestion control 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 73 – NET-TL-146 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Congestion Control Ideal Network delay ideal delay carried load throughput ideal offered load 1.0 offered load • Ideal network: – throughput: carried load = offered load (45° line) – zero delay (flat line) Why isn’t this possible? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-147 © James P.G. Sterbenz Congestion Control Real Network • Delay can’t be zero: speed-of-light – delay through network channels – delay along paths in network nodes • Throughput can’t be infinite – channel capacity limits bandwidth – switching rate of components limits bit rate 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 74 – NET-TL-148 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Congestion Control Desired Real Network Behaviour throughput 1.0 delay ideal carried load knee delay knee dmin offered load offered load 1.0 1.0 • Desired network: – carried load = offered load up to share of capacity what happens to delay? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-149 © James P.G. Sterbenz Congestion Control Causes of Congestion • Congestion when offered load → link capacity • Best effort – occurs whenever load is high • Probabilistic guarantees – occurs when load exceeds resource reservations • Absolute guarantees – can’t happen (in theory) 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 75 – NET-TL-150 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Congestion Control Infinite Buffers / No Retransmission • Congestion when offered load → link capacity • Infinite buffers ideal discuss why in lecture TQ 21 February 2011 knee delay – queue length builds to infinity – d→∞ delay dmin offered load 1.0 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-151 © James P.G. Sterbenz Congestion Control Finite Buffers with Retransmission • Finite buffers cause packet loss – retransmissions contribute to offered load • assuming reliable protocol – throughput curve levels off 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 76 – NET-TL-152 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Congestion Control Multihop Network • Multiple hops – downstream packet loss – upstream transmission wasted 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-153 © James P.G. Sterbenz Congestion Control Consequences of Congestion • Delay increases – due to packet queuing in network nodes – due to retransmissions when packets overflow buffers • finite buffers must drop packets when full • Throughput – levels off gradually (with real traffic) – then decreases • due to retransmissions when packets dropped • particularly over multiple hops – congestion collapse • “cliff” of the throughput curve 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 77 – NET-TL-154 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Congestion Control Local Action • Local action at point of congestion • Drops packets: discard policy – tail drop simplest: drop packets that overflow buffers – more intelligent policies possible • need flow or connection state in switches • discriminate which flows are causing congestion and penalise 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-155 © James P.G. Sterbenz Congestion Control End-to-End Action • End-to-end action • Throttle source – reduce transmission rates – prevent unnecessary retransmissions • Types – explicit – implicit 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 78 – NET-TL-156 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Congestion Control Congestion Avoidance and Control throughput 1.0 knee delay ideal cliff cliff carried load CC delay knee CA offered load CA ideal CC dmin 1.0 offered load 1.0 • Congestion control: operation at the cliff • Congestion avoidance: operation at the knee – detect and correct impending congestion before the cliff 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-157 © James P.G. Sterbenz E2E Transmission Control Closed-Loop Congestion Control • Feedback from network to limit rate • Required unless open loop with hard reservations • Window to limit amount of unacknowledged data – dynamic window – conservation of packets in the network – self clocking: ACKs determine the transmission of new data 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 79 – NET-TL-158 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Transmission Control Closed-Loop Control: Window Size • Window size critical 0 what happens with increasing bandwidth? 0 1 1 A0 2 A1 5 3 A2 4 A3 5 A4 6 2 3 4 5 6 A5 slow path 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-159 ITTC © James P.G. Sterbenz E2E Transmission Control Closed-Loop Control: Window Size • Window size critical 0 1 2 3 0 – big enough to fill pipe 0 How to determine size? 1 1 A0 2 2 A1 3 5 A2 4 A0 A1 A2 A3 4 5 6 7 3 4 A3 5 A4 A5 A6 A7 5 A4 6 6 A5 slow path 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 80 – 8 9 10 11 A8 A9 A10 A11 0 1 2 3 4 5 6 7 8 9 10 11 12 fast path NET-TL-160 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Transmission Control Closed-Loop Control: Initialisation • Slow start initialisation 0 – increase window until path loaded • Critical parameters A0 A0 A1 1 2 tRTT – initial window size – rate of increase 1 2 A2 tRTT A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A2 A3 A4 A1 Tradeoffs? 21 February 2011 0 0 tRTT A5 3 4 3 5 4 6 5 6 A6 A7 A8 A9 7 A10 8 7 A11 9 8 A12 10 9 A10 11 10 A13 12 11 A14 13 12 A15 14 13 A16 15 14 A17 1 0 2 1 3 2 3 4 5 4 6 5 7 6 8 7 9 8 10 9 11 10 12 11 13 12 14 13 15 14 16 15 17 16 18 17 19 18 20 19 21 20 21 KU EECS 780 – Comm Nets – E2E Transport NET-TL-161 ITTC © James P.G. Sterbenz E2E Transmission Control Closed-Loop Control: Initialisation • Slow start initialisation 0 – increase window until path loaded • Critical parameters A0 A0 A1 1 2 tRTT – initial window size – rate of increase 1 2 A2 tRTT A3 – conservative on high bw-×-delay: • multiple round trips • never get to full rate for transactions – aggressive: A4 A5 A6 A7 A8 A9 A10 A11 • induced congestions A12 KU EECS 780 – Comm Nets – E2E Transport – 81 – A2 A3 A4 A1 • Tradeoffs 21 February 2011 0 0 tRTT A5 3 4 3 5 4 6 5 6 A6 A7 A8 A9 A10 7 8 7 A11 9 8 A12 10 9 A10 11 10 A13 12 11 A14 13 12 A15 14 13 A16 15 14 A17 1 0 2 1 3 2 3 4 5 4 6 5 7 6 8 7 9 8 10 9 11 10 12 11 13 12 14 13 15 14 16 15 17 16 18 17 19 18 20 19 21 20 21 NET-TL-162 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Congestion Control Closed-Loop Control: Steady State additive increase congestion detection rate multiplicative decrease time • AIMD steady state – additive-increase slowly increases rate • increment window – multiplicative-decrease quickly throttles with congestion • divide window when packet lost 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-163 ITTC © James P.G. Sterbenz E2E Congestion Control AIMD Fairness and Stability • AIMD • until loss beyond R – MD: both decrease • half way to origin • halve window size equal bandwidth share R Flow 1 throughput – R = available bandwidth – initial bandwidth share I – AI: both increase ideal – trajectory toward ideal I • intersection of R and equal Flow 2 throughput R [based on Kurose fig. 3.53] 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 82 – NET-TL-164 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Congestion Control Closed-Loop Control initialisation steady state phase congestion detection sending rate AI slow start MD time • Initialisation phase: slow start • Steady-state phase: AIMD 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-165 © James P.G. Sterbenz E2E Congestion Control Closed-Loop Implicit Control • Implicit control – missing ACK assumed to be congestion good assumption? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 83 – NET-TL-166 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Congestion Control Closed-Loop Implicit Control • Implicit control – missing ACK assumed to be congestion – reasonable when all losses are due to congestion • fiber optic channels connected by reliable switches 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-167 © James P.G. Sterbenz E2E Congestion Control Closed-Loop Implicit Control • Implicit control – missing ACK assumed to be congestion – reasonable when all losses are due to congestion • fiber optic channels connected by reliable switches – performs poorly when significant losses in channel why? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 84 – NET-TL-168 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Congestion Control Closed-Loop Implicit Control • Implicit control – missing ACK assumed to be congestion – reasonable when all losses are due to congestion • fiber optic channels connected by reliable switches – performs poorly when significant losses in channel • mobile wireless links • under-provisioned CDMA (including optical CDMA) 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-169 © James P.G. Sterbenz E2E Congestion Control Closed-Loop Implicit Control • Implicit control – missing ACK assumed to be congestion – reasonable when all losses are due to congestion • fiber optic channels connected by reliable switches – performs poorly when significant losses in channel • mobile wireless links • under-provisioned CDMA (including optical CDMA) Alternatives? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 85 – NET-TL-170 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Congestion Control Closed-Loop Explicit Control • Explicit control – explicit congestion notification (ECN) • throttle with ECN message – some decoupling of error and congestion control • throttle before packet loss • not sufficient for lossy wireless link 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-171 © James P.G. Sterbenz E2E Congestion Control Closed-Loop Explicit Control • Explicit control – explicit congestion notification (ECN) • throttle with ECN message – some decoupling of error and congestion control • throttle before packet loss • not sufficient for lossy wireless link – not sufficient for discrimination of corrupted packets • ELN (explicit loss notification) necessary more in lecture TQ 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 86 – NET-TL-172 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Transmission Control Closed-Loop Control: Steady State • Implicit control – standard – with fast retransmit • Explicit control A0 A1 A2 A3 A4 A5 – ECN A6 A7 tack A7 A7 A7 A7 A7 A7 A7 A7 A8 A9 implicit fast retransmit 0 0 0 1 0 1 0 1 0 2 1 2 1 2 1 3 2 3 2 3 2 3 4 5 4 6 5 7 6 8 7 9 A0 A1 A2 A3 A4 A5 A6 10 A71 3 4 5 4 6 5 7 6 8 7 9 10 11 11 12 12 A72 13 A73 14 15 A7 16 A7 8 A7 9 8 10 9 11 10 12 11 A8 A9 A10 A11 A0 4 A2 A3 A4 A5 ECN A6 A9 13 A10 A11 8 A12 9 8 10 9 11 10 12 11 13 12 14 12 5 4 6 5 7 6 8 7 9 A8 A13 A14 A15 A16 A17 A18 13 KU EECS 780 – Comm Nets – E2E Transport ITTC 3 A1 A7 14 12 21 February 2011 explicit 8 10 9 11 10 12 11 13 12 14 13 15 14 16 15 17 16 18 17 19 18 20 19 21 20 21 NET-TL-173 © James P.G. Sterbenz E2E Transmission Control Hybrid Control • Dynamic rate control – open-loop rate control modified by network feedback • example: ATM ABR • Pacing to reduce burstiness – sender base rate control augments closed-loop control – window transmission spread over RTT – options • pace initial window, allow ACK self clocking to take over • periodic repacing to compensate for ACK compression • continuous pacing 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 87 – NET-TL-174 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transport Layer TL.3 Internet Transport Protocols TL.1 Transport Services and interfaces TL.2 End-to-end functions and mechanisms TL.3 Internet transport protocols TL.3.1 UDP TL.3.2 RTP introduction TL.3.3 TCP TL.4 Multipoint communication and reliable multicast 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-175 © James P.G. Sterbenz Internet Transport Protocols History • ARPANET / Internet transport protocol history – – – – – NCP (network control program) original ARPANET protocol replaced with TCP in 1977 TCP split from IP in 1978 UDP added in 1980 RTP RFC published 1996 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 88 – NET-TL-176 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Internet Transport Protocols Overview • UDP: user datagram protocol [RFC 0768 / STD 0006] – basic end-to-end multiplexing and error checking – no error, flow, or congestion control • RTP: real-time protocol [RFC 3550 / STD 0064] – support for end-to-end real-time synchronisation – typical implementations run over UDP • TCP: transmission control protocol [RFC 0793 / STD 0007] – connection-oriented reliable byte-stream protocol – full error, flow, and congestion control 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-177 © James P.G. Sterbenz Internet Transport Protocols Important Examples Protocol Name Function Status Ref TCP transmission control protocol reliable data transfer with congestion control standard RFC 0793 STD 0007 UDP user datagram protocol socket access to unreliable IP datagrams standard RFC 0768 STD 0006 RTP real-time protocol real-time synchronisation (typically over UDP) standards track RFC 3550 STD 0064 T/TCP TCP for transactions low connection setup overhead for transactions experimental RFC 1644 RDP reliable data protocol reliable data transfer with no congestion control experimental RFC 0908 SCTP stream control transmission protocol signalling proposed for wireless proposed standard RFC 2960 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 89 – NET-TL-178 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Internet Transport Protocols TL.3.1 UDP TL.1 Transport services and interfaces TL.2 End-to-end functions and mechanisms TL.3 Internet transport protocols TL.3.1 UDP TL.3.2 RTP introduction TL.3.3 TCP TL.4 Multipoint communication and reliable multicast 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-179 © James P.G. Sterbenz User Datagram Protocol Overview and Transfer Mode • UDP: user datagram protocol [RFC 0768 / STD 0006] • Basic access to Internet datagram transfer mode – no connection establishment • each UDP segment handled independently • no connection setup penalty • no connection state to maintain – basic end-to-end multiplexing – no reliability – no flow or congestion control 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 90 – NET-TL-180 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz User Datagram Protocol Segment Format and Multiplexing • Relatively small header – source and destination port – length [B] including header – checksum source port# length destination port # checksum • Multiplexing: UDP socket – dest (IP addr, port#) • Demux – receiver passes to port# • source addr, port irrelevant application payload (= length – 8B) – negotiated or well-known – may use source port to reply 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-181 © James P.G. Sterbenz User Datagram Protocol Multiplexing app j app i TCP port n pd TCP TCP port x TCP port y port demux TCP UDP port z pd UDP 06 17 transport demux (IP protocol id) network demux (IP address) • Interface to IP: protocol mux/demux (UDP=17) • Interface to application: port mux/demux 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 91 – NET-TL-182 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz User Datagram Protocol Error Detection • Recall E2E arguments: error check must be done E2E • Error checking: checksum – sequence of 16-bit integers – binary addition source port# destination port # length checksum • carry overflows wrapped; • 1’s complement of sum 1110011001100110 +1101010101010101 application payload (= length – 8B) 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-183 © James P.G. Sterbenz User Datagram Protocol Error Detection • Recall E2E arguments: error check must be done E2E • Error checking: checksum – sequence of 16-bit integers – binary addition source port# destination port # length checksum • carry overflows wrapped; • 1’s complement of sum 1110011001100110 +1101010101010101 11011101110111011 application payload (= length – 8B) 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 92 – NET-TL-184 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz User Datagram Protocol Error Detection • Recall E2E arguments: error check must be done E2E • Error checking: checksum – sequence of 16-bit integers – binary addition source port# destination port # length checksum • carry overflows wrapped; • 1’s complement of sum 1110011001100110 +1101010101010101 11011101110111011 1011101110111100 21 February 2011 application payload (= length – 8B) KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-185 © James P.G. Sterbenz User Datagram Protocol Error Detection • Recall E2E arguments: error check must be done E2E • Error checking: checksum – sequence of 16-bit integers – binary addition source port# destination port # length checksum • carry overflows wrapped; • 1’s complement of sum 1110011001100110 +1101010101010101 11011101110111011 1011101110111100 0100010001000011 21 February 2011 application payload (= length – 8B) KU EECS 780 – Comm Nets – E2E Transport – 93 – NET-TL-186 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz User Datagram Protocol Error Detection • Recall E2E arguments: error check must be done E2E • Error checking: checksum – sequence of 16-bit integers – binary addition source port# destination port # length checksum • carry overflows wrapped; • 1’s complement of sum 1110011001100110 +1101010101010101 11011101110111011 1011101110111100 0100010001000011 – sender computes+inserts – receiver compute+compares – weak protection [RFC 3385] application payload (= length – 8B) • No retransmission at L4 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-187 © James P.G. Sterbenz User Datagram Protocol Flow Control and Congestion Control • No flow control – sender blasts; may overwhelm receiver • No congestion control – sender may congest network – no mechanism for sender to back off 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 94 – NET-TL-188 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz User Datagram Protocol Typical Applications • Typical application: multimedia streaming why? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-189 © James P.G. Sterbenz User Datagram Protocol Typical Applications • Typical application: multimedia streaming – loss tolerant – rate sensitive (do not adapt well to TCP congestion control) – research community considering alternatives 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 95 – NET-TL-190 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz User Datagram Protocol Typical Applications • Typical application: multimedia streaming – loss tolerant – rate sensitive (do not adapt well to TCP congestion control) – research community considering alternatives • Other applications: network control protocols – e.g. DNS 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-191 © James P.G. Sterbenz Internet Transport Protocols TL.3.2 RTP Introduction TL.1 Transport services and interfaces TL.2 End-to-end functions and mechanisms TL.3 Internet transport protocols TL.3.1 UDP TL.3.2 RTP introduction TL.3.3 TCP TL.4 Multipoint communication and reliable multicast 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 96 – NET-TL-192 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Real-Time Protocol Overview and Transfer Mode • RTP: real-time protocol [RFC 3550 / STD 0064] • Streaming of data with real-time properties – uses UDP for basic transport • • • • no connection establishment basic end-to-end multiplexing no reliability no flow or congestion control – adds real-time support fields • sequence number • timestamp • source identifiers More in Lecture MS 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-193 © James P.G. Sterbenz Real-Time Protocol Segment Format • Encapsulated in UDP • RTP header – – – – – – – version = 02 P: padding bytes at end X: extension header CC: CSRC count (4b) PT: payload type (7b) sequence # (16b) timestamp (32b) source port# length 02 P X CC checksum PT sequence # timestamp SSRC: synchronisation source id CSRC list: contributing source ids ... • resolution app dependent – source identifiers • SSRC • CSRC (mixed in) 21 February 2011 destination port # application payload optional padding KU EECS 780 – Comm Nets – E2E Transport – 97 – #B pad NET-TL-194 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Real-Time Protocol RTP Payloads • PT: payload type – [www.iana.org/assignments/rtp-parameters] • Payload formats and encodings – specified in various RFCs – audio: RFC 3551, etc. – video: RFC 2250, etc. 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-195 © James P.G. Sterbenz Real-Time Protocol Control Protocol Overview • RTCP: real-time control protocol [RFC 3550 / STD 0064] – monitoring quality of service – convey participant status information 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 98 – NET-TL-196 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Internet Transport Protocols TL.3.3 TCP TL.1 Transport services and interfaces TL.2 end-to-end functions and mechanisms TL.3 Internet transport protocols TL.3.1 UDP TL.3.2 RTP introduction TL.3.3 TCP TL.4 Multipoint communication and reliable multicast 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-197 © James P.G. Sterbenz Transmission Control Protocol Overview • TCP: transmission control protocol RFC 0793 / STD 0007 + + + + + RFC RFC RFC RFC RFC 1122 1323 2018 2581 3168 implementation requirements high performance extensions SACK (selective acknowledgements) congestion control ECN (explicit congestion notification) • IANA defines name/number space for some fields – – – – Internet Assigned Numbers Authority: protocol types for IP (TCP = 06) option kinds well known port numbers 21 February 2011 www.iana.org/numbers.html KU EECS 780 – Comm Nets – E2E Transport – 99 – NET-TL-198 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Transfer Mode and Characteristics • Connection-oriented transfer mode – latency of connection setup – connection state must be maintained on each end system • Point-to-point full-duplex – reliable byte stream: no message boundaries – pipelined transfer (not just stop-and-wait) • Flow control – will not overwhelm receiver • Congestion control – attempt to avoid congesting network – implicit and optional ECN 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-199 ITTC © James P.G. Sterbenz Transmission Control Protocol Segment Format: Overview1 • Relatively large header 32 bits • Variable length payload • Options [options (variable length)] source port # dest port # – fixed length & position fields sequence number – variable length options ack number – header length4b in Bytes HL HL flags receive window • = 40 + |options| B checksum urg data pointer – may not be present (details later) • Checksum on entire segment – same algorithm as UDP 21 February 2011 application payload (variable length) KU EECS 780 – Comm Nets – E2E Transport – 100 – NET-TL-200 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Segment Format: Overview2 C W R E C E U R G A C K P S H R S T S Y N F I N 32 bits • Control flags (1 bit each) – – – – – – – – CWR cong. win. reduced ECE ECN echo URG urgent data ACK acknowledgement PSH push data RST reset connection SYN connection setup FIN connection teardown (details later) 21 February 2011 source port # dest port # sequence number ack number HL CEUAPRSF receive window checksum urg data pointer options (variable length) application payload (variable length) KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-201 © James P.G. Sterbenz Transmission Control Protocol Segment Format: No Options • Header with no options – 20B long 32 bits source port # dest port # sequence number ack number 20B 20 flags receive window checksum urg data pointer application payload (variable length) 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 101 – NET-TL-202 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Segment Format: No Options Nor Data • Entire segment 32 bits source port # dest port # sequence number ack number 20B 20 flags receive window checksum urg data pointer – 20B long • Example: – ACKs – significant fraction of Internet packets 40B why? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-203 ITTC © James P.G. Sterbenz Transmission Control Protocol Segment Format: Options • Options • 32 bits source port # dest port # – standardised extensions sequence number – experimental use ack number Used for 20B HL flags receive window – control: negotiation in SYN checksum urg data pointer – data: alternate processing • Format (max 40B total) ≤40B – kind1B (assigned by IANA) – length1B – option fields (variable) 21 February 2011 options (variable length) application payload (variable length) KU EECS 780 – Comm Nets – E2E Transport – 102 – NET-TL-204 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Selected Options • Selected TCP options http://www.iana.org/assignments/tcp‐parameters 00 end of option list 01 no operation (for padding) 02 MSS (max. segment size) 03 window scale factor 04 SACK permitted 05 SACK blocks 08 timestamp 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-205 © James P.G. Sterbenz Transmission Control Protocol Segment Format: Multiplexing • Socket: 5-tuple – assign source port # – network: IP address source port # dest port # sequence number ack number HL flags receive window checksum urg data pointer • Receiver demultiplexing options (variable length) – 〈sp, sa, dp, da, prot〉 • Sender multiplexing – network: IP address – IP: protocol # • UDP • TCP = 17 = 06 – TCP: destination port # determines receiving app 21 February 2011 application payload (variable length) KU EECS 780 – Comm Nets – E2E Transport – 103 – NET-TL-206 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Multiplexing app j app i TCP port n TCP port x pd TCP port y port demux TCP TCP UDP port z pd UDP 06 17 transport demux (IP protocol id) network demux (IP address) • Interface to IP: protocol mux/demux (TCP = 06) • Interface to application: port mux/demux 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-207 © James P.G. Sterbenz Transmission Control Protocol Connection Management: Segment Format • Flags define segment type – ACK segment • ACK for SYN or FIN • SYNACK may be piggybacked • ACK for data source port # dest port # sequence number ACK number CEUAPRSF receive window HL checksum urg data pointer options (variable length) – RST (reset) segment • e.g. bad port received – SYN (synchronise) segment • connection setup – FIN (finish) segment application payload (variable length) • connection release 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 104 – NET-TL-208 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Connection Management: Setup • C Three way handshake – “client” and “server” 1. SYN (init seq#) → • SYN (ISNs) buffer alloc randomised for security 2. ← SYNACK (init seq#) • • • S net buffer alloc SYN(ISNc)ACK ACK data segments randomised for security after buffer allocation SYN flood vulnerability estab. state data segments FIN ACK 3. ACK → – buffer allocation – segment may include data – client may send more ACK FIN 4. server may return data 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-209 © James P.G. Sterbenz Transmission Control Protocol Connection Management: Teardown • – – each independent half-close may occur simultaneously – ACK can’t be piggybacked • • SYN data segments Client closes socket data segments 21 February 2011 FIN ACK buffer free twait Server closes socket 1. ← FIN 2. ACK → S net SYNACK ACK full close 1. FIN → 2. ← ACK – timed wait before close • C Two two-way handshakes FIN ACK buffer free closed KU EECS 780 – Comm Nets – E2E Transport – 105 – NET-TL-210 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol RFC 0793 State Machine +---------+ ---------\ active OPEN | CLOSED | \ ----------+---------+<---------\ \ create TCB | ^ \ \ snd SYN passive OPEN | | CLOSE \ \ ------------ | | ---------\ \ create TCB | | delete TCB \ \ V | \ \ +---------+ CLOSE | \ | LISTEN | ---------- | | +---------+ delete TCB | | rcv SYN | | SEND | | ----------| | ------| V +---------+ snd SYN,ACK / \ snd SYN +---------+ | |<---------------------------------->| | | SYN | rcv SYN | SYN | | RCVD |<-----------------------------------------------| SENT | | | snd ACK | | | |------------------------------------| | +---------+ rcv ACK of SYN \ / rcv SYN,ACK +---------+ | -------------| | ----------| x | | snd ACK | V V | CLOSE +---------+ | ------| ESTAB | | snd FIN +---------+ | CLOSE | | rcv FIN V ------| | ------+---------+ snd FIN / \ snd ACK +---------+ | FIN |<---------------------------------->| CLOSE | | WAIT-1 |-----------------| WAIT | +---------+ rcv FIN \ +---------+ | rcv ACK of FIN ------| CLOSE | | -------------snd ACK | ------- | V x V snd FIN V +---------+ +---------+ +---------+ |FINWAIT-2| | CLOSING | | LAST-ACK| +---------+ +---------+ +---------+ | rcv ACK of FIN | rcv ACK of FIN | | rcv FIN -------------- | Timeout=2MSL -------------- | | ------x V -----------x V \ snd ACK +---------+delete TCB +---------+ ------------------------>|TIME WAIT|------------------>| CLOSED | +---------+ +---------+ 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-211 © James P.G. Sterbenz Transmission Control Protocol Actual Connection State Machine [Sewell] http://www.cl.cam.ac.uk/users/pes20/Netsem 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 106 – NET-TL-212 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Segment Format: Sequence and Window • Sequence # – forward data transfer – 1st byte # in segment • ACK number – – – – reverse acknowledgements seq # of next byte expected if ACK flag set data segment may piggyback ACK source port # dest port # sequence number ACK number CEUAPRSF receive window HL checksum urg data pointer options (variable length) application payload (variable length) • Receive window – # unACKed bytes 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-213 ITTC © James P.G. Sterbenz Transmission Control Protocol Unidirectional Data Transfer • Data is sequence of bytes C – number by byte # (not segment #) net S SYN (ISNs) SYN(ISNc)ACK ACK 1 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 107 – NET-TL-214 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Unidirectional Data Transfer • Data is sequence of bytes C – number by byte # (not segment #) – each segment ≤ MSS B S net SYN (ISNs) SYN(ISNc)ACK ACK data segment (MSS bytes) SN=? • Sequence numbers – byte # in byte stream of 1st byte in segment 2 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-215 ITTC © James P.G. Sterbenz Transmission Control Protocol Unidirectional Data Transfer • Data is sequence of bytes – number by byte # (not segment #) – each segment ≤ MSS B C S net SYN (ISNs) SYN(ISNc)ACK ACK data segment (MSS bytes) SN=ISNs • Sequence numbers ACK AN=? – byte # in byte stream of 1st byte in segment • ACK numbers – seq # of next byte expected 3 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 108 – NET-TL-216 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Unidirectional Data Transfer • Data is sequence of bytes C – number by byte # (not segment #) – each segment ≤ MSS B S net SYN (ISNs) SYN(ISNc)ACK ACK data segment (MSS bytes) SN=ISNs • Sequence numbers ACK AN=ISNs+MSS – byte # in byte stream of 1st byte in segment data segment (MSS bytes) SN=? • ACK numbers – seq # of next byte expected 4 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-217 ITTC © James P.G. Sterbenz Transmission Control Protocol Unidirectional Data Transfer • Data is sequence of bytes – number by byte # (not segment #) – each segment ≤ MSS B C S net SYN (ISNs) SYN(ISNc)ACK ACK data segment (MSS bytes) SN=ISNs • Sequence numbers ACK AN=ISNs+MSS – byte # in byte stream of 1st byte in segment data segment (MSS bytes) SN=ISNs+MSS • ACK numbers – seq # of next byte expected – cumulative ACKs ACK AN=? 5 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 109 – NET-TL-218 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Unidirectional Data Transfer • Data is sequence of bytes C – number by byte # (not segment #) – each segment ≤ MSS B S net SYN (ISNs) SYN(ISNc)ACK ACK data segment (MSS bytes) SN=ISNs • Sequence numbers ACK AN=ISNs+MSS – byte # in byte stream of 1st byte in segment data segment (MSS bytes) SN=ISNs+MSS • ACK numbers ACK AN=ISNs+2MSS – seq # of next byte expected – cumulative ACKs 6 what next? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-219 ITTC © James P.G. Sterbenz Transmission Control Protocol Unidirectional Data Transfer • Data is sequence of bytes – number by byte # (not segment #) – each segment ≤ MSS B C SYN (ISNs) SYN(ISNc)ACK ACK data segment (MSS bytes) SN=ISNs • Sequence numbers ACK AN=ISNs+MSS – byte # in byte stream of 1st byte in segment data segment (MSS bytes) SN=ISNs+MSS • ACK numbers – seq # of next byte expected – cumulative ACKs ACK AN=ISNs+2MSS data segment (MSS bytes) SN=ISNs+2MSS what next? 21 February 2011 S net KU EECS 780 – Comm Nets – E2E Transport – 110 – 7 NET-TL-220 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Unidirectional Data Transfer • Data is sequence of bytes C – number by byte # (not segment #) – each segment ≤ MSS B SYN (ISNs) SYN(ISNc)ACK ACK data segment (MSS bytes) SN=ISNs • Sequence numbers – byte # in byte stream of 1st byte in segment ACK AN=ISNs+MSS data segment (MSS bytes) SN=ISNs+MSS • ACK numbers – seq # of next byte expected – cumulative ACKs ACK AN=ISNs+2MSS data segment (MSS bytes) SN=ISNs+2MSS • Out of order arrival ACK AN=ISNs+3MSS – implementation specific 21 February 2011 S net 8 KU EECS 780 – Comm Nets – E2E Transport NET-TL-221 ITTC © James P.G. Sterbenz Transmission Control Protocol Bidirectional Data Transfer C • Data both directions S net – ACKs returned both ways SYN (ISNs) SYN(ISNc)ACK ACK data segment (MSS bytes) SN=ISNs ACK AN=ISNs+MSS what next? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 111 – 1 NET-TL-222 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Bidirectional Data Transfer C • Data both directions S net – ACKs returned both ways – may be piggybacked SYN (ISNs) SYN(ISNc)ACK ACK data segment (MSS bytes) SN=ISNs ACK AN=ISNs+MSS data segment (MSS bytes) SN=ISNc 2 what next? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-223 ITTC © James P.G. Sterbenz Transmission Control Protocol Bidirectional Data Transfer C • Data both directions – ACKs returned both ways – may be piggybacked – delayed ACK waits briefly S net SYN (ISNs) SYN(ISNc)ACK ACK data segment (MSS bytes) SN=ISNs ACK AN=ISNs+MSS data segment (MSS bytes) SN=ISNc ACK AN=ISNc+MSS data segment (MSS bytes) SN=ISNs+MSS what next? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 112 – 3 NET-TL-224 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Bidirectional Data Transfer C • Data both directions – ACKs returned both ways – may be piggybacked – delayed ACK waits briefly • Bidirectional stream S net SYN (ISNs) SYN(ISNc)ACK ACK data segment (MSS bytes) SN=ISNs ACK AN=ISNs+MSS – data segments – piggybacked ACKs data segment (MSS bytes) SN=ISNc ACK AN=ISNc+MSS data segment (MSS bytes) SN=ISNs+MSS 4 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-225 © James P.G. Sterbenz Transmission Control Protocol Segment Format: Push • Push – PSH flag set – receiver should immediately send to application – don’t wait to fill buffer – example use: telnet source port # dest port # sequence number ACK number HL CEUAPRSF receive window checksum urg data ptr options (variable length) • avoid buffering delay application payload (variable length) 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 113 – NET-TL-226 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Segment Format: Urgent Mode • Urgent mode – URG flag set, urgent pointer • Urgent data range – sn + up points to last byte • Example uses source port # dest port # sequence number ACK number HL CEUAPRSF receive window checksum urg data ptr – interrupt for telnet, rlogin – FTP abort why? 21 February 2011 options (variable length) application payload (variable length) KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-227 © James P.G. Sterbenz Transmission Control Protocol Window-Based Feedback Control • Windowing used for a combined: – error control – flow control – congestion control • Window limits amount of unACKed data transmitted 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 114 – NET-TL-228 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Error Control: Original Go-Back-N • TCP provides reliable byte stream • Cumulative ACKs using window: go-back-n – byte number rather than segment number • Corrupted data – checksum fails • Packet loss in network – timeout events – triple duplicate ACKS (fast retransmit) 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-229 © James P.G. Sterbenz Transmission Control Protocol Error Control: SACK • TCP provides reliable byte stream – cumulative ACKs perform poorly if loss rate not very low – cumulative ACKs limit ability to reorder • Selective ACKs [RFC2018] – selective repeat ARQ mechanism • used in conjunction with cumulative ACK mechanisms – SACK byte range in TCP header option • Retransmissions triggered by: – holes in SACK ranges (SACK is positive ACK) 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 115 – NET-TL-230 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Segment Format: SACK Options • SACK permitted negotiation – kind=4 in SYN • SACK ranges – kind = 05 • after kind=01 NOP pads – length = 8n+2 B for n SACK blocks • max of 3 SACK blocks – assuming another option 32 bits source port # dest port # sequence number ack number HL flags receive window checksum urg data pointer 01 01 05 len seq num of 1st byte seq num after last byte – each block: • seq num of 1st byte • seq num of last byte +1 – ACK semantics unchanged 21 February 2011 application payload (variable length) KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-231 © James P.G. Sterbenz Transmission Control Protocol Error Control: SACK Operation • Capability announced with SYN – SACK permitted option 5 • Cumulative ACKs as before – ACK byte in last segment – with no missing prior segments • Selective ACKs – sent only when non-contiguous segments received – indicate byte range received – holes between SACK blocks indicate missing byte ranges 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 116 – NET-TL-232 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Timeout How to set TCP timeout value? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-233 © James P.G. Sterbenz Transmission Control Protocol Timeout • How to set TCP timeout value? – longer than RTT, but RTT varies – too short: premature timeout; unnecessary retransmissions – too long: slow reaction to segment loss Implication? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 117 – NET-TL-234 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Timeout • How to set TCP timeout value? – longer than RTT, but RTT varies – too short: premature timeout; unnecessary retransmissions – too long: slow reaction to segment loss • Need a good estimate of RTT 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-235 © James P.G. Sterbenz Transmission Control Protocol Round Trip Time Estimate • RTT Estimate – sample RTTsamp: measured time from segment transmission until ACK receipt – ignore retransmissions • Estimated RTTest is smoothed – average several recent measurements – EWMA: exponentially weighted moving average • influence of past sample decreases exponentially – RTTest = (1–α) RTTest + α RTTsamp • typical value: α = 0.125 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 118 – NET-TL-236 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol RTT Estimate Example RTT: gaia.cs.umass.edu to fantasia.eurecom.fr RTT (milliseconds) 350 300 250 200 150 SampleRTT Estimated RTT 100 1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106 time (seconds) 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-237 © James P.G. Sterbenz Transmission Control Protocol Fast Retransmit • Time-out period often too long – long delay before resending lost packet • Detect lost segments via duplicate ACKs – sender often sends many segments back-to-back – if lost there will likely be many duplicate ACKs • If sender receives 3 duplicate ACKs – 4th identical ACK – assume that segment after ACKed data was lost 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 119 – NET-TL-238 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Flow Control • Sender matches transmission rate to receiver – receive window dynamically adjusted • Receiver advertises its window – transmitted in each TCP segment header • Sender limits unACKed data to receive window size RcvWindow from IP 21 February 2011 spare room data in buffer to application KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-239 © James P.G. Sterbenz Transmission Control Protocol Congestion Control • Slow start to probe capacity • Implicit congestion control – lack of expected ACK assumed to be congestion-based loss – sender halves congestion window (AIMD) • Recovery – then retransmits (go-back-n or SACK block) – begins increase of congestion window (AIMD) • 1 MSS (max. segment size) every RTT 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 120 – NET-TL-240 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Congestion Control initialisation steady state phase congestion detection sending rate AI slow start MD time • Initialisation phase: slow start • Steady-state phase: AIMD 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-241 © James P.G. Sterbenz Transmission Control Protocol Congestion Control Optimisations • Fast recovery – 1/2 congestion window after 3dupACK rather than slow start • RED: random early detection (discard) [Floyd 1993] – discard packets when router queue threshold exceeded – throttle TCP source earlier before congestion occurs more in Lecture TQ • ECN: explicit congestion notification [Floyd 1994] – use IP ECN to trigger multiplicative decrease 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 121 – NET-TL-242 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol Explicit Congestion Notification • Network nodes set congestion indication – hist. ICMP source quench – ECN bits in IP header • TCP reacts – uses flags for signalling source port # dest port # sequence number ACK number CEUAPRSF receive window HL checksum urg data pointer options (variable length) more in lecture TQ application payload (variable length) 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-243 © James P.G. Sterbenz Transmission Control Protocol Congestion Control Implementations • Tahoe – slow start and congestion avoidance algorithms – fast retransmit after triple duplicate ACKs • Reno – widely implemented – Tahoe + – fast recovery • NewReno [Floyd 1999] – Reno + – partial ACK recovery 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 122 – NET-TL-244 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol High-Bandwidth-×-Delay Optimisations • High bandwidth-×-delay paths (long fat pipes) problem? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-245 © James P.G. Sterbenz Transmission Control Protocol High-Bandwidth-×-Delay Optimisations • High bandwidth-×-delay paths (long fat pipes) – problem: large number of bits in flight Implications to TCP? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 123 – NET-TL-246 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transmission Control Protocol High-Bandwidth-×-Delay Optimisations • High bandwidth-×-delay paths (long fat pipes) – problem: large number of bits in flight • Implications to TCP – – – – max window size is 64KB (why? ) (problem? ) packet loss has significant impact on goodput only one RTT measurement per window sequence numbers limited to 32 bit (problem? ) 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-247 © James P.G. Sterbenz Transmission Control Protocol High-Bandwidth-×-Delay Optimisations • High bandwidth-×-delay paths (long fat pipes) – problem: large number of bits in flight • Modifications [RFC 1323] – – – – window scale option (kind=3) SACK [RFC 2018] timestamp option (kind=8) enables RTT per segment PAWS uses timestamp to detect duplicate seq. numbers (protection against wrapped sequence numbers) more about this in EECS 881 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 124 – NET-TL-248 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Transport Layer TL.4 Multipoint Communication TL.1 TL.2 TL.3 TL.4 Transport services and interfaces End-to-end functions and mechanisms Internet transport protocols Multipoint communication and reliable multicast 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-249 © James P.G. Sterbenz E2E Multipoint Communication Motivation for E2E Multicast • End-to-end multicast is necessary if: • Network layer multicast not available why? • Reliability is needed why? 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 125 – NET-TL-250 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz E2E Multipoint Communication Motivation for E2E Multicast • End-to-end multicast is necessary if: • Network layer multicast not available – intradomain multicast limited – interdomain multicast not available lecture NL • Reliability is needed – recall end-to-end arguments – options: transport-layer multicast application-layer multicast 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport NET-TL-251 ITTC © James P.G. Sterbenz E2E Multipoint Communication Closed Loop Retransmission: Multicast R R ACK ACK×6 NAK×2 6 ACK×4 ACK 6 NAK NAK ACK 5 ACK×2 ACK 1 5 NAK ACK×2 ACK 2 ACK 3 NAK NAK 4 1 2 3 4 • ACK implosion: ACK suppression needed o NAKs (negative ACKs) with liveness polling o localised hop-by-hop buffering and retransmission – significant reduction of traffic on relatively reliable links 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 126 – NET-TL-252 KU EECS 780 – Communication Networks – End-to-End Transport ITTC © James P.G. Sterbenz Further Reading • W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols, Addison-Wesley, Reading MA, 1994. • Michael Welzl, Network Congestion Control, John Wiley, Chichester UK, 2005. 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport ITTC NET-TL-253 © James P.G. Sterbenz Acknowledgements Some material in these foils comes from the textbook supplementary materials: • Kurose & Ross, Computer Networking: A Top-Down Approach Featuring the Internet • Sterbenz & Touch, High-Speed Networking: A Systematic Approach to High-Bandwidth Low-Latency Communication http://hsn‐book.sterbenz.org 21 February 2011 KU EECS 780 – Comm Nets – E2E Transport – 127 – NET-TL-254