1、3: Transport Layer,3a-1,Chapter 3: Transport Layer,Chapter goals: understand principles behind transport layer services: multiplexing/demultiplexing reliable data transfer flow control congestion control instantiation and implementation in the Internet,Chapter overview: transport layer services mult
2、iplexing/demultiplexing connectionless transport: UDP principles of reliable data transfer connection-oriented transport: TCP reliable transfer flow control connection management principles of congestion control TCP congestion control,3: Transport Layer,3a-2,List of Contents,3.1 Introduction and Tra
3、nsport-Layer Services 3.2 Multiplexing and Demultiplexing 3.3 Connectionless Transport: UDP 3.4 Principles of Reliable Data Transfer 3.5 Connection-Oriented Transport: TCP 3.6 Principles of Congestion Control 3.7 TCP Congestion Control 3.8 Summary,3: Transport Layer,3a-3,3.1 Introduction and Transpo
4、rt services,provide logical communication between app processes running on different hosts transport protocols run in end systems transport vs network layer services: network layer: data transfer between devices transport layer: data transfer between hosts, and relies on network layer services,3: Tr
5、ansport Layer,3a-4,Transport-layer protocols,IP services: best-effort delivery no bandwidth guarantees unreliable service Internet transport services: unreliable, unordered or multicast delivery: UDP reliable, in-order unicast delivery (TCP) congestion flow control connection setup,process-to-proces
6、s data transport (multiplexing, demultiplexing)error checking,3: Transport Layer,3a-5,P2,3.2 Multiplexing/demultiplexing,receiver,H,t,segment,segment,M,P1,P3,P4,segment header,application-layer data,function extend the host-to-host delivery to process-to-process delivery,datagram,Demultiplexing: del
7、ivering received segments to correct app layer processes,3: Transport Layer,3a-6,Multiplexing/demultiplexing,multiplexing/demultiplexing: based on sender, receiver port numbers, IP addresses source, dest port #s in each segment recall: well-known port numbers for specific applications,gathering data
8、 from multipleapp processes, enveloping data with header (later used for demultiplexing),source port #,dest port #,32 bits,application data (message),other header fields,TCP/UDP segment format,3: Transport Layer,3a-7,Multiplexing/demultiplexing: examples,host A,server B,port use: simple telnet app,W
9、eb client host A,Web server B,Web client host C,port use: Web server,3: Transport Layer,3a-8,3.3 Connectionless Transport: UDP,“no frills,” “bare bones” Internet transport protocol “best effort” service, UDP segments may be: lost delivered out of order to app connectionless: no handshaking between U
10、DP sender, receiver each UDP segment handled independently of others,Why is there a UDP? no connection establishment (which can add delay) simple: no connection state at sender, receiver small segment header no congestion control: UDP can blast away as fast as desired,3: Transport Layer,3a-9,3.3.1 U
11、DP Segment Structure,often used for streaming multimedia apps loss tolerant rate sensitive other UDP uses (why?): DNS SNMP reliable transfer over UDP: add reliability at application layer application-specific error recover!,source port #,dest port #,32 bits,Application data (message),UDP segment for
12、mat,length,checksum,Length, in bytes of UDP segment, including header,3: Transport Layer,3a-10,3.3.2 UDP Checksum,Sender: treat segment contents as sequence of 16-bit integers checksum: addition (1s complement sum) of segment contents sender puts the 1s complement of the checksum value into UDP chec
13、ksum field,Receiver: compute adding of received segment, include checksum check if computed result equals to all-1: NO - error detected YES - no error detected. But maybe errors nonethless? More later .,Goal: detect “errors” (e.g., flipped bits) in transmitted segment,3: Transport Layer,3a-11,UDP Ch
14、ecksum: example,Suppose transport three 16-bit words:0110011001100000 0101010101010101 1000111100001100,0110011001100000 0101010101010101 1011101110110101,1011101110110101 1000111100001100 0100101011000001,overflow,1011010100111110,1s complement of the sum,checksum,3: Transport Layer,3a-12,3.4 Princ
15、iples of Reliable Data Transfer,important in app., transport, link layers top-10 list of important networking topics!,characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt),3: Transport Layer,3a-13,Reliable data transfer: getting started,send side,re
16、ceive side,3: Transport Layer,3a-14,3.4.1 Build a Reliable Data Transfer,Well: incrementally develop sender, receiver sides of reliable data transfer protocol (rdt) consider only unidirectional data transfer but control info will flow on both directions! use finite state machines (FSM) to specify se
17、nder, receiver,event causing state transition,actions taken on state transition,state: At this “state”, next state uniquely determined by next event,3: Transport Layer,3a-15,Rdt1.0: reliable transfer over a reliable channel,underlying channel perfectly reliable no bit erros no loss of packets separa
18、te FSMs for sender, receiver: sender sends data into underlying channel receiver read data from underlying channel,3: Transport Layer,3a-16,Rdt2.0: channel with bit errors,underlying channel may mistake bits in packet recall: UDP checksum to detect bit errors the question: how to recover from errors
19、? acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors sender retransmits pkt on receipt of NAK Mechanism: Automatic Repeat reQuest, ARQ new mechanisms in rdt2.0 (beyond rdt1.0): error de
20、tection receiver feedback: control msgs (ACK,NAK) rcvr-sender retransmission,3: Transport Layer,3a-17,Rdt2.0: FSM specification (stop-and-wait),sender FSM,receiver FSM,3: Transport Layer,3a-18,Rdt2.0: in action (no errors),sender FSM,receiver FSM,3: Transport Layer,3a-19,Rdt2.0: in action (error sce
21、nario),sender FSM,receiver FSM,3: Transport Layer,3a-20,Rdt2.0 has a fatal flaw!,What happens if ACK/NAK corrupted? sender doesnt know what happened at receiver! cant just retransmit: possible duplicate What to do? Receiver sends ACKs/NAKs to sender? What if ACK/NAK lost? retransmit, but this might
22、cause retransmission of correctly received pkt!,Handling duplicates: sender adds sequence number to each pkt sender retransmits current pkt if ACK/NAK garbled receiver discards (doesnt deliver up) duplicate pkt,Sender sends one packet, then waits for receiver response,3: Transport Layer,3a-21,Rdt2.1
23、: sender, handles garbled ACK/NAKs,3: Transport Layer,3a-22,Rdt2.1: receiver, handles garbled ACK/NAKs,3: Transport Layer,3a-23,Rdt2.1: discussion,Sender: seq # added to pkt two seq. #s (0,1) will suffice. Why? must check if received ACK/NAK corrupted twice as many states state must “remember” wheth
24、er “current” pkt has 0 or 1 seq. #,Receiver: must check if received packet is duplicate state indicates whether 0 or 1 is expected pkt seq #,3: Transport Layer,3a-24,Rdt2.2: a NAK-free protocol,same functionality as rdt2.1 instead of NAK, receiver sends ACK for last pkt received OK receiver must exp
25、licitly include seq # of pkt being ACKed duplicate ACK at sender results in same action as NAK: retransmit current pkt,sender FSM,!,3: Transport Layer,3a-25,Rdt3.0: Channels with Errors and Loss,New assumption: underlying channel can also lose packets (data or ACKs) checksum, seq. #, ACKs, retransmi
26、ssions will be of help, but not enough Q: how to deal with loss? sender waits until certain time or ACK lost, then retransmits drawbacks?,Approach: sender waits “reasonable” amount of time for ACK retransmits if no ACK received in this time if pkt (or ACK) just delayed (not lost): retransmission wil
27、l be duplicate, but use of seq. #s already handles this receiver must specify seq # of pkt being ACKed requires countdown timer,3: Transport Layer,3a-26,Rdt3.0 sender,3: Transport Layer,3a-27,Rdt3.0 in action,3: Transport Layer,3a-28,Rdt3.0 in action,3: Transport Layer,3a-29,3.5 Connection-Oriented
28、Transport: TCP,characteristics the Internets transport-layer connection-oriented reliable transport relies on many of the underlying principles discussed in the previous section,3: Transport Layer,3a-30,3.5.1 The TCP Connection,connection-oriented handshaking (exchange of control msgs) inits sender,
29、 receiver state before data exchange TCP protocol runs only in the end systems and not in the intermediate network elements (routers and link-layer switches) full-duplex service bi-directional data flow in same connection MSS: maximum segment size,3: Transport Layer,3a-31,The TCP Connection,How a TC
30、P connection is established? the client app process initiate a connection with another process (server process)three-way handshake Once a TCP connection is established, the two app process can send data to each other.,Socket clientSocket = new Socket(“hostname”, portNumber);,3: Transport Layer,3a-32
31、,The TCP Connection,TCP segment characteristics maximum segment size (MSS): aiming at app data maximum transmission unit (MTU): aiming at link-layer frame it is passed down to the network layer and separately encapsulated within IP datagrams,3: Transport Layer,3a-33,3.5.2 TCP segment structure,URG:
32、urgent data (generally not used),ACK: ACK # valid,PSH: push data now (generally not used),RST, SYN, FIN: connection establish (setup, teardown commands),# bytes rcvr willing to accept,counting by bytes of data (not segments!),Internet checksum (as in UDP),negotiate the MSS or a window scaling factor
33、,3: Transport Layer,3a-34,TCP seq. #s and ACKs,TCP sequence number byte stream “number” of first byte in segments dataExample: a data stream that consists of 500,000 bytes, and the MSS is 1,000 bytes.,3: Transport Layer,3a-35,TCP seq. #s and ACKs,Seq. #s: byte stream “number” of first byte in segmen
34、ts data ACKs: seq # of next byte expected from other side cumulative ACK Q: how receiver handles out-of-order segments A: TCP spec doesnt say, - up to implementer,Host A,Host B,Seq=42, ACK=79, data = C,Seq=79, ACK=43, data = C,Seq=43, ACK=80,User types C,host ACKs receipt of echoed C,host ACKs recei
35、pt of C, echoes back C,simple telnet scenario,3: Transport Layer,3a-36,3.5.3 Round-Trip Time Estimation and Timeout,Q: how to set TCP timeout value? longer than RTT note: RTT will vary too short: premature timeout unnecessary retransmissions too long: slow reaction to segment loss,Q: how to estimate
36、 RTT? SampleRTT: measured time from segment transmission until ACK receipt ignore retransmissions, cumulatively ACKed segments SampleRTT will vary, want estimated RTT “smoother” use several recent measurements, not just current SampleRTT,3: Transport Layer,3a-37,Round-Trip Time Estimation and Timeou
37、t,EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT,Exponential weighted moving average influence of given sample decreases exponentially fast typical value of x: 0.125,Setting the timeout EstimtedRTT plus “safety margin” large variation in EstimatedRTT - larger safety margin,Timeout = EstimatedRTT +
38、4*Deviation,Deviation = (1-x)*Deviation +x*|SampleRTT-EstimatedRTT|,3: Transport Layer,3a-38,3.5.4 TCP: reliable data transfer,simplified sender, assuming,wait for event,wait for event,event: data received from application above,event: timer timeout for segment with seq # y,event: ACK received, with
39、 ACK # y,create, send segment,retransmit segment,ACK processing,one way data transfer no flow, congestion control,3: Transport Layer,3a-39,TCP: reliable data transfer,00 sendbase = initial_sequence number 01 nextseqnum = initial_sequence number 02 03 loop (forever) 04 switch(event) 05 event: data re
40、ceived from application above 06 create TCP segment with sequence number nextseqnum 07 start timer for segment nextseqnum 08 pass segment to IP 09 nextseqnum = nextseqnum + length(data) 10 event: timer timeout for segment with sequence number y 11 retransmit segment with sequence number y 12 compute
41、 new timeout interval for segment y 13 restart timer for sequence number y 14 event: ACK received, with ACK field value of y 15 if (y sendbase) /* cumulative ACK of all data up to y */ 16 cancel all timers for segments with sequence numbers y sendbase = y 18 if (there are currently any not-yet-ackno
42、wledged segments) 19 start timer 20 21 /* end of loop forever */,Simplified TCP sender,3: Transport Layer,3a-40,TCP: retransmission scenarios,Host A,Seq=100, 20 bytes data,ACK=100,Seq=92 timeout,Segment 100 not retransmitted,Host B,Seq=92, 8 bytes data,ACK=120,Seq=92, 8 bytes data,Seq=100 timeout,AC
43、K=120,Seq=92 timeout,3: Transport Layer,3a-41,TCP: retransmission scenarios,Host A,Seq=100, 20 bytes data,ACK=100,Seq=92 timeout,A cumulative acknowledgement avoids retransmission of the first segment,Host B,Seq=92, 8 bytes data,Seq=100 timeout,ACK=120,loss,X,3: Transport Layer,3a-42,3.5.5 TCP Flow
44、Control,receiver: explicitly informs sender of (dynamically changing) amount of free buffer space RcvWindow field in TCP segment sender: keeps the amount of transmitted, unACKed data less than most recently received RcvWindow,sender wont overrun receivers buffers by transmitting too much,too fast,re
45、ceiver buffering,RcvBuffer = size or TCP Receive BufferRcvWindow = amount of spare room in Buffer,3: Transport Layer,3a-43,3.5.6 TCP Connection Management,Recall: TCP sender, receiver establish “connection” before exchanging data segments initialize TCP variables: seq. #s buffers, flow control info
46、(e.g. RcvWindow) client: connection initiatorSocket clientSocket = new Socket(“hostname“,“port number“); server: contacted by clientSocket connectionSocket = welcomeSocket.accept();,3: Transport Layer,3a-44,Step 1: client end system sends TCP SYN control segment to server SYN - 1 specifies initial s
47、eq # (random client_isn) Step 2: server end system receives SYN, replies with SYNACK control segment ACKs received SYN allocates buffers specifies server- receiver SYN - 1, client_isn + 1, initial seq. # Step 3: client end system receives SYN, replies to server allocates buffers SYN - 0, server_isn
48、+ 1,Three way handshake,3: Transport Layer,3a-45,Three way handshake,client,SYN=1, seq=client_isn,server,SYN=1, seq=server_isn, ack=client_isn+1,SYN=0,seq=client_isn+1, ack=server_isn+1,Connection request,Connection granted,ACK,Time,Time,3: Transport Layer,3a-46,TCP Connection Management (cont.),Clo
49、sing a connection: client closes socket: clientSocket.close(); Step 1: client end system sends TCP FIN control segment to server (FIN=1) Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN.,3: Transport Layer,3a-47,TCP Connection Management (cont.),Step 3: client receives FIN, replies with ACK. Enters “timed wait” - will respond with ACK to received FINs Step 4: server, receives ACK. Connection closed.,
