Chapter 3: Transport Layer

of 60

Please download to get full document.

View again

All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
PDF
60 pages
0 downs
3 views
Share
Description
Our goals: understand principles behind transport layer services: multiplexing/demultiplexing reliable data transfer flow control congestion control. learn about transport layer protocols in the Internet: UDP: connectionless transport TCP: connection-oriented transport
Transcript
Our goals:understand principles behind transport layer services:multiplexing/demultiplexingreliable data transferflow controlcongestion controllearn about transport layer protocols in the Internet:UDP: connectionless transportTCP: connection-oriented transportTCP congestion controlChapter 3: Transport LayerTransport Layer3.1 Transport-layer services3.2 Multiplexing and demultiplexing3.3 Connectionless transport: UDP3.4 Principles of reliable data transfer3.5 Connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection managementChapter 3 outlineTransport Layerprovide logical communication between app processes running on different hoststransport protocols run in end systems send side: breaks app messages into segments, passes to network layerrcv side: reassembles segments into messages, passes to app layermore than one transport protocol available to appsInternet: TCP and UDPapplicationtransportnetworkdata linkphysicalapplicationtransportnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicallogical end-end transportTransport services and protocolsTransport Layernetwork layer: logical communication between hoststransport layer: logical communication between processes relies on, enhances, network layer servicesHousehold analogy:12 kids sending letters to 12 kidsprocesses = kidsapp messages = letters in envelopeshosts = housestransport protocol = Ann and Billnetwork-layer protocol = postal serviceTransport vs. network layerTransport Layerreliable, in-order delivery (TCP)congestion control flow controlconnection setupunreliable, unordered delivery: UDPno-frills extension of “best-effort” IPservices not available: delay guaranteesbandwidth guaranteesapplicationtransportnetworkdata linkphysicalapplicationtransportnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicalnetworkdata linkphysicallogical end-end transportInternet transport-layer protocolsTransport Layer3.1 Transport-layer services3.2 Multiplexing and demultiplexing3.3 Connectionless transport: UDP3.4 Principles of reliable data transfer3.5 Connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 Principles of congestion control3.7 TCP congestion controlChapter 3 outlineTransport LayerapplicationapplicationapplicationtransporttransporttransportP4P2P3P1P1networknetworknetworklinklinklinkphysicalphysicalphysicalMultiplexing at send host:Demultiplexing at rcv host:host 3host 2host 1Multiplexing/demultiplexingdelivering received segmentsto correct socketgathering data from multiplesockets, enveloping data with header (later used for demultiplexing)= socket= processTransport Layerhost receives IP datagramseach datagram has source IP address, destination IP addresseach datagram carries 1 transport-layer segmenteach segment has source, destination port number (recall: well-known port numbers for specific applications)host uses IP addresses & port numbers to direct segment to appropriate socketHow demultiplexing works32 bitssource port #dest port #other header fieldsapplicationdata (message)TCP/UDP segment formatTransport LayerCreate sockets with port numbers:DatagramSocket mySocket1 = new DatagramSocket(99111);DatagramSocket mySocket2 = new DatagramSocket(99222);UDP socket identified by two-tuple:(dest IP address, dest port number)When host receives UDP segment:checks destination port number in segmentdirects UDP segment to socket with that port numberIP datagrams with different source IP addresses and/or source port numbers directed to same socketConnectionless demultiplexingTransport LayerP3P2P1P1SP: 9157client IP: ADP: 6428ClientIP:BserverIP: CSP: 5775SP: 6428SP: 6428DP: 6428DP: 9157DP: 5775Connectionless demux (cont)DatagramSocket serverSocket = new DatagramSocket(6428);SP provides “return address”Transport LayerTCP socket identified by 4-tuple: source IP addresssource port numberdest IP addressdest port numberrecv host uses all four values to direct segment to appropriate socketServer host may support many simultaneous TCP sockets:each socket identified by its own 4-tupleWeb servers have different sockets for each connecting clientnon-persistent HTTP will have different socket for each requestConnection-oriented demuxTransport LayerSP: 9157SP: 5775P1P1P2P4P3P6P5client IP: ADP: 80DP: 80Connection-oriented demux (cont)S-IP: BD-IP:CSP: 9157DP: 80ClientIP:BserverIP: CS-IP: AS-IP: BD-IP:CD-IP:CTransport LayerSP: 9157SP: 5775P1P1P2P3client IP: ADP: 80DP: 80Connection-oriented demux: Threaded Web ServerP4S-IP: BD-IP:CSP: 9157DP: 80ClientIP:BserverIP: CS-IP: AS-IP: BD-IP:CD-IP:CTransport Layer3.1 Transport-layer services3.2 Multiplexing and demultiplexing3.3 Connectionless transport: UDP3.4 Principles of reliable data transfer3.5 Connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 Principles of congestion control3.7 TCP congestion controlChapter 3 outlineTransport Layer“no frills,” “bare bones” Internet transport protocol“best effort” service, UDP segments may be:lostdelivered out of order to appconnectionless:no handshaking between UDP sender, receivereach UDP segment handled independently of othersWhy is there a UDP?no connection establishment (which can add delay)simple: no connection state at sender, receiversmall segment headerno congestion control: UDP can blast away as fast as desiredUDP: User Datagram Protocol [RFC 768]Transport Layeroften used for streaming multimedia appsloss tolerantrate sensitiveother UDP usesDNSSNMPreliable transfer over UDP: add reliability at application layerapplication-specific error recovery!UDP: more32 bitssource port #dest port #Length, inbytes of UDPsegment,includingheaderchecksumlengthApplicationdata (message)UDP segment formatTransport Layer3.1 Transport-layer services3.2 Multiplexing and demultiplexing3.3 Connectionless transport: UDP3.4 Principles of reliable data transfer3.5 Connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 Principles of congestion control3.7 TCP congestion controlChapter 3 outlineTransport Layerimportant in app., transport, link layerstop-10 list of important networking topics!characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)Principles of Reliable data transferTransport Layerrdt_send():called from above, (e.g., by app.). Passed data to deliver to receiver upper layerdeliver_data():called by rdt to deliver data to upperudt_send():called by rdt,to transfer packet over unreliable channel to receiverrdt_rcv():called when packet arrives on rcv-side of channelReliable data transfer: getting startedsendsidereceivesideTransport LayerWe’ll:incrementally develop sender, receiver sides of reliable data transfer protocol (rdt)consider only unidirectional data transferbut control info will flow on both directions!use finite state machines (FSM) to specify sender, receivereventstate1state2actionsReliable data transfer: getting startedevent causing state transitionactions taken on state transitionstate: when in this “state” next state uniquely determined by next eventTransport Layerunderlying channel perfectly reliableno bit errorsno loss of packetsseparate FSMs for sender, receiver:sender sends data into underlying channelreceiver read data from underlying channelRdt1.0: reliable transfer over a reliable channelrdt_send(data)rdt_rcv(packet)Wait for call from belowWait for call from aboveextract (packet,data)deliver_data(data)packet = make_pkt(data)udt_send(packet)senderreceiverTransport Layerunderlying channel may flip bits in packetchecksum to detect bit errorsthe question: how to recover from errors:acknowledgements (ACKs): receiver explicitly tells sender that pkt received OKnegative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errorssender retransmits pkt on receipt of NAKnew mechanisms in rdt2.0 (beyond rdt1.0):error detectionreceiver feedback: control msgs (ACK,NAK) rcvr->senderRdt2.0: channel with bit errorsTransport LayerWait for ACK or NAKrdt_rcv(rcvpkt) && corrupt(rcvpkt)udt_send(NAK)Wait for call from belowrdt2.0: FSM specificationrdt_send(data)receiversnkpkt = make_pkt(data, checksum)udt_send(sndpkt)rdt_rcv(rcvpkt) && isNAK(rcvpkt)Wait for call from aboveudt_send(sndpkt)rdt_rcv(rcvpkt) && isACK(rcvpkt)Lsenderrdt_rcv(rcvpkt) && notcorrupt(rcvpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)Transport LayerWait for ACK or NAKrdt_rcv(rcvpkt) && corrupt(rcvpkt)udt_send(NAK)rdt2.0: operation with no errorsrdt_send(data)snkpkt = make_pkt(data, checksum)udt_send(sndpkt)rdt_rcv(rcvpkt) && isNAK(rcvpkt)Wait for call from aboveudt_send(sndpkt)rdt_rcv(rcvpkt) && isACK(rcvpkt)Wait for call from belowLrdt_rcv(rcvpkt) && notcorrupt(rcvpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)Transport LayerWait for ACK or NAKrdt_rcv(rcvpkt) && corrupt(rcvpkt)udt_send(NAK)rdt2.0: error scenariordt_send(data)snkpkt = make_pkt(data, checksum)udt_send(sndpkt)rdt_rcv(rcvpkt) && isNAK(rcvpkt)Wait for call from aboveudt_send(sndpkt)rdt_rcv(rcvpkt) && isACK(rcvpkt)Wait for call from belowLrdt_rcv(rcvpkt) && notcorrupt(rcvpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)Transport LayerWhat happens if ACK/NAK corrupted?sender doesn’t know what happened at receiver!can’t just retransmit: possible duplicateHandling duplicates: sender adds sequence number to each pktsender retransmits current pkt if ACK/NAK garbledreceiver discards (doesn’t deliver up) duplicate pktstop and waitrdt2.0 has a fatal flaw!Sender sends one packet, then waits for receiver responseTransport LayerWait for ACK or NAK 0Wait for call 1 from aboveWait for ACK or NAK 1rdt2.1: sender, handles garbled ACK/NAKsrdt_send(data)sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )Wait for call 0 from aboveudt_send(sndpkt)rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt)rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) LLrdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isNAK(rcvpkt) )rdt_send(data)sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)udt_send(sndpkt)Transport LayerWait for 0 from belowWait for 1 from belowrdt2.1: receiver, handles garbled ACK/NAKsrdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)rdt_rcv(rcvpkt) && (corrupt(rcvpkt)rdt_rcv(rcvpkt) && (corrupt(rcvpkt)sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt)rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt)rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt)extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt)Transport LayerSender:seq # added to pkttwo seq. #’s (0,1) will suffice. Why?must check if received ACK/NAK corrupted twice as many statesstate must “remember” whether “current” pkt has 0 or 1 seq. #Receiver:must check if received packet is duplicatestate indicates whether 0 or 1 is expected pkt seq #note: receiver can not know if its last ACK/NAK received OK at senderrdt2.1: discussionTransport Layersame functionality as rdt2.1, using ACKs onlyinstead of NAK, receiver sends ACK for last pkt received OKreceiver must explicitly include seq # of pkt being ACKed duplicate ACK at sender results in same action as NAK: retransmit current pktrdt2.2: a NAK-free protocolTransport LayerWait for ACK0Wait for call 0 from aboveWait for 0 from belowrdt2.2: sender, receiver fragmentsrdt_send(data)sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,1) )udt_send(sndpkt)sender FSMfragmentrdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)rdt_rcv(rcvpkt) && (corrupt(rcvpkt) ||has_seq1(rcvpkt))Lreceiver FSMfragmentudt_send(sndpkt)rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK1, chksum)udt_send(sndpkt)Transport LayerNew assumption: underlying channel can also lose packets (data or ACKs)checksum, seq. #, ACKs, retransmissions will be of help, but not enoughApproach: sender waits “reasonable” amount of time for ACK retransmits if no ACK received in this timeif pkt (or ACK) just delayed (not lost):retransmission will be duplicate, but use of seq. #’s already handles thisreceiver must specify seq # of pkt being ACKedrequires countdown timerrdt3.0: channels with errors and lossTransport LayerWait for ACK0Wait for ACK1Wait for call 1 from aboveWait for call 0from aboverdt3.0 senderrdt_send(data)rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,1) )sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)start_timerLrdt_rcv(rcvpkt)Ltimeoutudt_send(sndpkt)start_timerrdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1)rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0)stop_timerstop_timertimeoutudt_send(sndpkt)start_timerrdt_rcv(rcvpkt)Lrdt_send(data)rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) ||isACK(rcvpkt,0) )sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)start_timerLTransport Layerrdt3.0 in actionTransport Layerrdt3.0 in actionTransport Layerrdt3.0 works, but performance stinksexample: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet:Performance of rdt3.0L (packet length in bits)8kb/pktT=== 8 microsectransmitR (transmission rate, bps)10**9 b/sec
  • U sender: utilization – fraction of time sender busy sending
  • 1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link
  • network protocol limits use of physical resources!
  • Transport Layerrdt3.0: stop-and-wait operationsenderreceiverfirst packet bit transmitted, t = 0last packet bit transmitted, t = L / Rfirst packet bit arrivesRTTlast packet bit arrives, send ACKACK arrives, send next packet, t = RTT + L / RTransport LayerPipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pktsrange of sequence numbers must be increasedbuffering at sender and/or receiverTwo generic forms of pipelined protocols: go-Back-N, selective repeatPipelined protocolsTransport LayerPipelining: increased utilizationsenderreceiverfirst packet bit transmitted, t = 0last bit transmitted, t = L / Rfirst packet bit arrivesRTT last packet bit arrives, send ACKlast bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACKACK arrives, send next packet, t = RTT + L / RIncrease utilizationby a factor of 3!Transport LayerSender:k-bit seq # in pkt header“window” of up to N, consecutive unack’ed pkts allowedGo-Back-N
  • ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK”
  • may deceive duplicate ACKs (see receiver)
  • timer for each in-flight pkt
  • timeout(n): retransmit pkt n and all higher seq # pkts in window
  • Transport LayerWaitGBN: sender extended FSMrdt_send(data)if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ }else refuse_data(data)Lbase=1nextseqnum=1timeoutstart_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])…udt_send(sndpkt[nextseqnum-1])rdt_rcv(rcvpkt) && corrupt(rcvpkt)rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base = getacknum(rcvpkt)+1If (base == nextseqnum) stop_timer else start_timerTransport LayerACK-only: always send ACK for correctly-received pkt with highest in-order seq #may generate duplicate ACKsneed only remember expectedseqnumout-of-order pkt: discard (don’t buffer) -> no receiver buffering!Re-ACK pkt with highest in-order seq #GBN: receiver extended FSMdefaultudt_send(sndpkt)rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) LWaitextract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(expectedseqnum,ACK,chksum)udt_send(sndpkt)expectedseqnum++expectedseqnum=1sndpkt = make_pkt(expectedseqnum,ACK,chksum)Transport LayerGBN inactionTransport Layerreceiver individually acknowledges all correctly received pktsbuffers pkts, as needed, for eventual in-order delivery to upper layersender only resends pkts for which ACK not receivedsender timer for each unACKed pktsender windowN consecutive seq #’sagain limits seq #s of sent, unACKed pktsSelective RepeatTransport LayerSelective repeat: sender, receiver windowsTransport Layerdata from above :if next available seq # in window, send pkttimeout(n):resend pkt n, restart timerACK(n) in [sendbase,sendbase+N]:mark pkt n as receivedif n smallest unACKed pkt, advance window base to next unACKed seq # receiversenderSelective repeatpkt n in [rcvbase, rcvbase+N-1]
  • send ACK(n)
  • out-of-order: buffer
  • in-order: deliver (also deliver buffered, in-order pkts), advance window to next not-yet-received pkt
  • pkt n in [rcvbase-N,rcvbase-1]
  • ACK(n)
  • otherwise:
  • ignore
  • Transport LayerSelective repeat in actionTransport LayerExample: seq #’s: 0, 1, 2, 3window size=3receiver sees no difference in two scenarios!incorrectly passes duplicate data as new in (a)Q: what relationship between seq # size and window size?Selective repeat: dilemmaTransport Layer3.1 Transport-layer services3.2 Multiplexing and demultiplexing3.3 Connectionless transport: UDP3.4 Principles of reliable data transfer3.5 Connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 Principles of congestion control3.7 TCP congestion controlChapter 3 outlineTransport Layerfull duplex data:bi-directional data flow in same connectionMSS: maximum segment sizeconnection-oriented:handshaking (exchange of control msgs) init’s sender, receiver state before data exchangeflow controlled:sender will not overwhelm receiverpoint-to-point:one sender, one receiverreliable, in-order byte steam:no “message boundaries”pipelined:TCP congestion and flow control set window sizesend & receive buffersTCP: OverviewRFCs: 793, 1122, 1323, 2018, 2581Transport Layer32 bitssource port #dest port #sequence numberacknowledgement numberheadlennotusedReceive windowUAPRSFchecksumUrg data pnterOptions (variable length)applicationdata (variable length)TCP segment structureURG: urgent data (generally not used)countingby bytes of data(not segments!)ACK: ACK #validPSH: push data now(generally not used)# bytes rcvr willingto acceptRST, SYN, FIN:connection estab(setup, teardowncommands)Internetchecksum(as in UDP)Transport LayerSeq. #’s:byte stream “number” of first byte in segment’s dataACKs:seq # of next byte expected from other sidecumulative ACKQ: how receiver handles out-of-order segmentsA: TCP spec doesn’t say, - up to implementortimeTCP seq. #’s and ACKsHost BHost AUsertypes‘C’Seq=42, ACK=79, data = ‘C’host ACKsreceipt of‘C’, echoesback ‘C’Seq=79, ACK=43, data = ‘C’host ACKsreceipt of echoed‘C’Seq=43, ACK=80simple telnet scenarioTransport LayerQ: how to set TCP timeout value?longer than RTTbut RTT variestoo short: premature timeoutunnecessary retransmissionstoo long: slow reaction to segment lossQ: how to estimate RTT?SampleRTT: measured time from segment transmission until ACK receiptignore retransmissionsSampleRTT will vary, want estimated RTT “smoother”average several recent measurements, not just current SampleRTTTCP Round Trip Time and TimeoutTransport LayerTCP Round Trip Time and TimeoutEstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
  • Exponential weighted moving average
  • influence of past sample decreases exponentially fast
  • t
  • Related Search
    We Need Your Support
    Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

    Thanks to everyone for your continued support.

    No, Thanks