Chapter 3: Transport Layer

Chapter 3: Transport Layerour goals: understandprinciples behindtransport layerservices: learn about Internettransport layerprotocols: UDP: connectionlesstransport TCP: connection-orientedreliable transport TCP congestion control multiplexing,demultiplexing reliable data transfer flow control congestion controlTransport Layer 3-1Chapter 3 outline3.1 transport-layerservices3.2 multiplexing anddemultiplexing3.3 connectionlesstransport: UDP3.4 principles of reliabledata transfer3.5 connection-orientedtransport: TCP segment structurereliable data transferflow controlconnection management3.6 principles of congestioncontrol3.7 TCP congestion controlTransport Layer 3-21

Transport services and protocols provide logical communicationbetween app processesrunning on different hoststransport protocols run inend systems send side: breaks appmessages into segments,passes to network layer rcv side: reassemblessegments into messages,passes to app layermore than one transportprotocol available to apps Internet: TCP and UDPapplicationtransportnetworkdata linkphysicalapplicationtransportnetworkdata linkphysicalTransport Layer 3-3Transport vs. network layernetwork layer: logicalcommunicationbetween hosts transport layer:logicalcommunicationbetween processes relies on, enhances,network layerserviceshousehold analogy:12 kids in Ann’s house sendingletters to 12 kids in Bill’shouse: hosts houses processes kids app messages letters inenvelopes transport protocol Annand Bill who demux to in-house siblings network-layer protocol postal serviceTransport Layer 3-42

Internet transport-layer protocols applicationtransportnetworkdata linkphysicalreliable, in-orderdelivery (TCP) congestion control flow control connection setup networkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicalunreliable, unordereddelivery: UDP no-frills extension of“best-effort” IP networkdata linkphysicalnetworkdata linkphysicalservices not available:networkdata linkphysicalnetworkdata linkphysicalapplicationtransportnetworkdata linkphysical delay guarantees bandwidth guaranteesTransport Layer 3-5Chapter 3 outline3.1 transport-layerservices3.2 multiplexing anddemultiplexing3.3 connectionlesstransport: UDP3.4 principles of reliabledata transfer3.5 connection-orientedtransport: TCP segment structurereliable data transferflow controlconnection management3.6 principles of congestioncontrol3.7 TCP congestion controlTransport Layer 3-63

Multiplexing/demultiplexingmultiplexing at sender:handle data from multiplesockets, add transport header(later used for demultiplexing)demultiplexing at receiver:use header info to deliverreceived segments to lTransport Layer 3-7How demultiplexing works host receives IP datagrams each datagram has source IPaddress, destination IPaddress each datagram carries onetransport-layer segment each segment has source,destination port number host uses IP addresses &port numbers to directsegment to appropriatesocket32 bitssource port #dest port #other header fieldsapplicationdata(payload)TCP/UDP segment formatTransport Layer 3-84

Connectionless demultiplexing created socket has host-localport #: DatagramSocket mySocket1 new DatagramSocket(12534); when host receives UDPsegment: checks destination port #in segment directs UDP segment tosocket with that port #when creating datagram tosend into UDP socket,must specify destination IP address destination port #IP datagrams with samedest. port #, but differentsource IP addresses and/or source port numberswill be directed to samesocket at destTransport Layer 3-9Connectionless demux: exampleDatagramSocketmySocket2 newDatagramSocket(9157);DatagramSocketserverSocket newDatagramSocketDatagramSocketmySocket1 icalsource port: 6428dest port: 9157source port: 9157dest port: 6428source port: ?dest port: ?source port: ?dest port: ?Transport Layer 3-105

Connection-oriented demux TCP socket identifiedby 4-tuple:source IP addresssource port numberdest IP addressdest port number server host may supportmany simultaneous TCPsockets: each socket identified byits own 4-tuple demux: receiver usesall four values to directsegment toappropriate socketweb servers havedifferent sockets foreach connecting client non-persistent HTTP willhave different socket foreach requestTransport Layer 3-11Connection-oriented demux: physicalhost: IPaddress Atransportnetworklinkserver: IPaddress Bsource IP,port: B,80dest IP,port: A,9157source IP,port: A,9157dest IP, port: B,80three segments, all destined to IP address: B,dest port: 80 are demultiplexed to different socketsphysicalsource IP,port: C,5775dest IP,port: B,80host: IPaddressCsource IP,port: B,9157dest IP,port: B,80Transport Layer 3-126

Connection-oriented demux: examplethreaded calhost: IPaddress Atransportnetworklinkserver: IPaddress Bsource IP,port: B,80dest IP,port: A,9157physicalhost: IPaddressCsource IP,port: C,5775dest IP,port: B,80source IP,port: A,9157dest IP, port: B,80source IP,port: B,9157dest IP,port: B,80Transport Layer 3-13Chapter 3 outline3.1 transport-layerservices3.2 multiplexing anddemultiplexing3.3 connectionlesstransport: UDP3.4 principles of reliabledata transfer3.5 connection-orientedtransport: TCP segment structurereliable data transferflow controlconnection management3.6 principles of congestioncontrol3.7 TCP congestion controlTransport Layer 3-147

UDP: User Datagram Protocol [RFC 768] “no frills,” “bare bones”Internet transportprotocol“best effort” service, UDPsegments may be: lost delivered out-of-orderto appconnectionless: no handshakingbetween UDP sender,receiver each UDP segmenthandled independentlyof others UDP use: streaming multimediaapps (loss tolerant, ratesensitive) DNS SNMP reliable transfer overUDP: add reliability atapplication layer application-specific errorrecovery!Transport Layer 3-15UDP: segment header32 bitssource port #dest port #lengthchecksumapplicationdata(payload)length, in bytes ofUDP segment,including headerwhy is there a UDP? UDP segment format no connectionestablishment (which canadd delay)simple: no connectionstate at sender, receiversmall header sizeno congestion control:UDP can blast away asfast as desiredTransport Layer 3-168

UDP checksumGoal: detect “errors” (e.g., flipped bits) in transmittedsegmentsender:receiver: treat segment contents,including header fields,as sequence of 16-bitintegerschecksum: addition(one’s complementsum) of segmentcontentssender puts checksumvalue into UDPchecksum field compute checksum ofreceived segmentcheck if computedchecksum equals checksumfield value: NO - error detected YES - no error detected.But maybe errorsnonetheless? More later .Transport Layer 3-17Internet checksum: exampleexample: add two 16-bit integers1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 01 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1Note: when adding numbers, a carryout from the mostsignificant bit needs to be added to the resultTransport Layer 3-189

Chapter 3 outline3.1 transport-layerservices3.2 multiplexing anddemultiplexing3.3 connectionlesstransport: UDP3.4 principles of reliabledata transfer3.5 connection-orientedtransport: TCP segment structurereliable data transferflow controlconnection management3.6 principles of congestioncontrol3.7 TCP congestion controlTransport Layer 3-19Principles of reliable data transfer important in application, transport, link layers top-10 list of important networking topics! characteristics of unreliable channel will determinecomplexity of reliable data transfer protocol (rdt)Transport Layer 3-2010

Principles of reliable data transfer important in application, transport, link layers top-10 list of important networking topics! characteristics of unreliable channel will determinecomplexity of reliable data transfer protocol (rdt)Transport Layer 3-21Principles of reliable data transfer important in application, transport, link layers top-10 list of important networking topics! characteristics of unreliable channel will determinecomplexity of reliable data transfer protocol (rdt)Transport Layer 3-2211

Reliable data transfer: getting startedrdt send(): called from above,(e.g., by app.). Passed data todeliver to receiver upper layerdeliver data(): called byrdt to deliver data to uppersendsidereceivesideudt send(): called by rdt,to transfer packet overunreliable channel to receiverrdt rcv(): called when packetarrives on rcv-side of channelTransport Layer 3-23Reliable data transfer: getting startedwe’ll: incrementally develop sender, receiver sides ofreliable data transfer protocol (rdt) consider only unidirectional data transfer but control info will flow on both directions! use finite state machines (FSM) to specify sender,receiverevent causing state transitionactions taken on state transitionstate: when in this“state” next stateuniquely determinedby next eventstate1eventactionsstate2Transport Layer 3-2412

rdt1.0: reliable transfer over a reliable channel underlying channel perfectly reliable no bit errors no loss of packets separate FSMs for sender, receiver: sender sends data into underlying channel receiver reads data from underlying channelWait forcall fromaboverdt send(data)packet make pkt(data)udt send(packet)senderWait forcall frombelowrdt rcv(packet)extract (packet,data)deliver data(data)receiverTransport Layer 3-25rdt2.0: channel with bit errors underlying channel may flip bits in packet checksum to detect bit errors the question: how to recover from errors: acknowledgements (ACKs): receiver explicitly tells senderthat pkt received OK negative acknowledgements (NAKs): receiver explicitly tellssender that pkt had errors senderretransmitspkt onrecoverreceipt ofNAK“errors”Howdo humansfromnew mechanisms in rdt2.0 (beyond rdt1.0):during conversation? error detection receiver feedback: control msgs (ACK,NAK) rcvr- senderTransport Layer 3-2613

rdt2.0: channel with bit errors underlying channel may flip bits in packet checksum to detect bit errors the question: how to recover from errors: acknowledgements (ACKs): receiver explicitly tells senderthat pkt received OK negative acknowledgements (NAKs): receiver explicitly tellssender that pkt had errors sender retransmits pkt on receipt of NAKnew mechanisms in rdt2.0 (beyond rdt1.0): error detection feedback: control msgs (ACK,NAK) from receiver tosenderTransport Layer 3-27rdt2.0: FSM specificationrdt send(data)sndpkt make pkt(data, checksum)udt send(sndpkt)rdt rcv(rcvpkt) &&isNAK(rcvpkt)Wait forWait forcall fromACK orudt send(sndpkt)aboveNAKrdt rcv(rcvpkt) && isACK(rcvpkt)Λsenderreceiverrdt rcv(rcvpkt) &&corrupt(rcvpkt)udt send(NAK)Wait forcall frombelowrdt rcv(rcvpkt) &¬corrupt(rcvpkt)extract(rcvpkt,data)deliver data(data)udt send(ACK)Transport Layer 3-2814

rdt2.0: operation with no errorsrdt send(data)snkpkt make pkt(data, checksum)udt send(sndpkt)rdt rcv(rcvpkt) &&isNAK(rcvpkt)Wait forWait forcall fromACK orudt send(sndpkt)aboveNAKrdt rcv(rcvpkt) && isACK(rcvpkt)Λrdt rcv(rcvpkt) &&corrupt(rcvpkt)udt send(NAK)Wait forcall frombelowrdt rcv(rcvpkt) &¬corrupt(rcvpkt)extract(rcvpkt,data)deliver data(data)udt send(ACK)Transport Layer 3-29rdt2.0: error scenariordt send(data)snkpkt make pkt(data, checksum)udt send(sndpkt)rdt rcv(rcvpkt) &&isNAK(rcvpkt)Wait forWait forcall fromACK orudt send(sndpkt)aboveNAKrdt rcv(rcvpkt) && isACK(rcvpkt)Λrdt rcv(rcvpkt) &&corrupt(rcvpkt)udt send(NAK)Wait forcall frombelowrdt rcv(rcvpkt) &¬corrupt(rcvpkt)extract(rcvpkt,data)deliver data(data)udt send(ACK)Transport Layer 3-3015