3rd edition chapter 3第三版3章

Transport Layer,3-1,Chapter 3Transport Layer,Computer Networking: A Top Down Approach 5th edition. Jim Kurose, Keith RossAddison-Wesley, April 2009.,Transport Layer,3-2,Chapter 3: Transport Layer,Our goals: understand principles behind transport layer services:multiplexing/demultiplexingreliable data transferflow controlcongestion control,learn about transport layer protocols in the Internet:UDP: connectionless transportTCP: connection-oriented transportTCP congestion control,Transport Layer,3-3,Chapter 3 outline,3.1 Transport-layer services3.2 Multiplexing and demultiplexing3.3 Connectionless transport: UDP3.4 Principles of reliable data transfer,3.5 Connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 Principles of congestion control3.7 TCP congestion control,Transport Layer,3-4,Transport services and protocols,provide 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 UDP,Transport Layer,3-5,Transport vs. network layer,network layer: logical communication between hoststransport layer: logical communication between processes relies on, enhances, network layer services,Household analogy:12 kids sending letters to 12 kidsprocesses = kidsapp messages = letters in envelopeshosts = housestransport protocol = Ann and Billnetwork-layer protocol = postal service,传输层与网络层的关系,网络层功能：主机通信协议：IP特点：hop-by-hop传输层功能：进程通信协议：UDP和TCP特点：end-to-end,IP地址和端口,Transport Layer,3-8,Internet transport-layer protocols,reliable, in-order delivery (TCP)congestion control flow controlconnection setupunreliable, unordered delivery: UDPno-frills extension of “best-effort” IPservices not available: delay guaranteesbandwidth guarantees,Transport Layer,3-9,Chapter 3 outline,3.1 Transport-layer services3.2 Multiplexing and demultiplexing3.3 Connectionless transport: UDP3.4 Principles of reliable data transfer,3.5 Connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 Principles of congestion control3.7 TCP congestion control,Transport Layer,3-10,Multiplexing/demultiplexing,application,transport,network,link,physical,P1,application,transport,network,link,physical,application,transport,network,link,physical,P2,P3,P4,P1,host 1,host 2,host 3,= process,= socket,delivering received segmentsto correct socket,gathering data from multiplesockets, enveloping data with header (later used for demultiplexing),UDP多路复用,Transport Layer,3-12,How demultiplexing works,host receives IP datagramseach datagram has source IP address, destination IP addresseach datagram carries 1 transport-layer segmenteach segment has source, destination port number host uses IP addresses & port numbers to direct segment to appropriate socket,source port #,dest port #,32 bits,applicationdata (message),other header fields,TCP/UDP segment format,TCP/UDP 众所周知端口号,Transport Layer,3-14,Connectionless demultiplexing,Create sockets with port numbers:DatagramSocket mySocket1 = new DatagramSocket(12534);DatagramSocket mySocket2 = new DatagramSocket(12535);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 socket,Transport Layer,3-15,Connectionless demux (cont),DatagramSocket serverSocket = new DatagramSocket(6428);,SP provides “return address”,Transport Layer,3-16,Connection-oriented demux,TCP socket identified by 4-tuple: source IP addresssource port numberdest IP addressdest port numberrecv host uses all four values to direct segment to appropriate socket,Server 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 request,Transport Layer,3-17,Connection-oriented demux (cont),ClientIP:B,serverIP: C,SP: 9157,DP: 80,D-IP:C,S-IP: A,D-IP:C,S-IP: B,D-IP:C,S-IP: B,Transport Layer,3-18,Connection-oriented demux: Threaded Web Server,ClientIP:B,serverIP: C,SP: 9157,DP: 80,P4,D-IP:C,S-IP: A,D-IP:C,S-IP: B,D-IP:C,S-IP: B,Transport Layer,3-19,Chapter 3 outline,3.1 Transport-layer services3.2 Multiplexing and demultiplexing3.3 Connectionless transport: UDP3.4 Principles of reliable data transfer,3.5 Connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 Principles of congestion control3.7 TCP congestion control,Transport Layer,3-20,UDP: User Datagram Protocol RFC 768,“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 others,Why 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 desired,Transport Layer,3-21,UDP: more,often used for streaming multimedia appsloss tolerantrate sensitiveother UDP usesDNSSNMPreliable transfer over UDP: add reliability at application layerapplication-specific error recovery!,source port #,dest port #,32 bits,Applicationdata (message),UDP segment format,length,checksum,Length, inbytes of UDPsegment,includingheader,7.2 UDP协议,提供主机通信IP服务特性报文可能丢失报文可能出错报文可能乱序到达报文在网络上可能被延迟任意长时间支持多路复用,提供进程通信UDP服务特性报文可能丢失报文可能出错报文可能乱序到达报文在网络上可能被延迟任意长时间支持多路复用,IP与UDP关系,IP提供主机通信通信对象命名是IP 地址IP地址定位到主机,UDP提供进程通信通信对象命名是Port 号Port号定位到进程,Transport Layer,3-24,UDP checksum,Sender:treat segment contents as sequence of 16-bit integerschecksum: addition (1s complement sum) of segment contentssender puts checksum value into UDP checksum field,Receiver:compute checksum of received segmentcheck if computed checksum equals checksum field value:NO - error detectedYES - no error detected. But maybe errors nonetheless? More later .,Goal: detect “errors” (e.g., flipped bits) in transmitted segment,Transport Layer,3-25,Internet Checksum Example,NoteWhen adding numbers, a carryout from the most significant bit needs to be added to the resultExample: add two 16-bit integers,1 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 11 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 11 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 01 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1,wraparound,sum,checksum,Transport Layer,3-26,Chapter 3 outline,3.1 Transport-layer services3.2 Multiplexing and demultiplexing3.3 Connectionless transport: UDP3.4 Principles of reliable data transfer,3.5 Connection-oriented transport: TCPsegment structurereliable data transferflow controlconnection management3.6 Principles of congestion control3.7 TCP congestion control,Transport Layer,3-27,Principles of Reliable data transfer,important in app., transport, link layerstop-10 list of important networking topics!,characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt),Transport Layer,3-28,Principles of Reliable data transfer,important in app., transport, link layerstop-10 list of important networking topics!,characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt),Transport Layer,3-29,Principles of Reliable data transfer,important in app., transport, link layerstop-10 list of important networking topics!,characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt),Transport Layer,3-30,Reliable data transfer: getting started,sendside,receiveside,Transport Layer,3-31,Reliable data transfer: getting started,Well: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, receiver,event causing state transition,actions taken on state transition,state: when in this “state” next state uniquely determined by next event,Transport Layer,3-32,Rdt1.0: reliable transfer over a reliable channel,underlying channel perfectly reliableno bit errorsno loss of packetsseparate FSMs for sender, receiver:sender sends data into underlying channelreceiver read data from underlying channel,Wait for call from above,packet = make_pkt(data)udt_send(packet),rdt_send(data),extract (packet,data)deliver_data(data),Wait for call from below,rdt_rcv(packet),sender,receiver,上交数据,启动,启动,Transport Layer,3-33,Rdt1.0 存在何问题？,It is a idealization !在目前的技术条件下，假设不合理的!How dose the network protocol grow up!网络协议是怎样炼成的？！,Transport Layer,3-34,Rdt2.0: channel with bit errors,underlying 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-sender,Transport Layer,3-35,rdt2.0: FSM specification,Wait for call from above,snkpkt = make_pkt(data, checksum)udt_send(sndpkt),extract(rcvpkt,data)deliver_data(data)udt_send(ACK),rdt_rcv(rcvpkt) & notcorrupt(rcvpkt),rdt_rcv(rcvpkt) & isACK(rcvpkt),udt_send(sndpkt),rdt_rcv(rcvpkt) & isNAK(rcvpkt),sender,receiver,rdt_send(data),L,重传,等待调用,上交数据,发送ACK,报文错,报文对,发送NAK,Transport Layer,3-36,rdt2.0: operation with no errors,Wait for call from above,snkpkt = make_pkt(data, checksum)udt_send(sndpkt),extract(rcvpkt,data)deliver_data(data)udt_send(ACK),rdt_rcv(rcvpkt) & notcorrupt(rcvpkt),rdt_rcv(rcvpkt) & isACK(rcvpkt),udt_send(sndpkt),rdt_rcv(rcvpkt) & isNAK(rcvpkt),Wait for call from below,rdt_send(data),L,Transport Layer,3-37,rdt2.0: error scenario,Wait for call from above,snkpkt = make_pkt(data, checksum)udt_send(sndpkt),extract(rcvpkt,data)deliver_data(data)udt_send(ACK),rdt_rcv(rcvpkt) & notcorrupt(rcvpkt),rdt_rcv(rcvpkt) & isACK(rcvpkt),udt_send(sndpkt),rdt_rcv(rcvpkt) & isNAK(rcvpkt),Wait for call from below,rdt_send(data),L,启动,Transport Layer,3-38,rdt2.0 has a fatal flaw!,What happens if ACK/NAK corrupted?ACK/NAK 出错后会怎么样？sender doesnt know what happened at receiver!cant just retransmit: possible duplicate,Handling duplicates: sender retransmits current pkt if ACK/NAK garbledsender adds sequence number to each pktreceiver discards (doesnt deliver up) duplicate pkt,Sender sends one packet, then waits for receiver response,Transport Layer,3-39,rdt2.1: sender, handles garbled (混淆) ACK/NAKs,Wait for call 0 from above,sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt),rdt_send(data),udt_send(sndpkt),rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) |isNAK(rcvpkt) ),sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt),rdt_send(data),rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & isACK(rcvpkt),udt_send(sndpkt),rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) |isNAK(rcvpkt) ),rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & isACK(rcvpkt),L,L,重传,发送报文#1,重传,发送报文#0,启动,Transport Layer,3-40,rdt2.1: receiver, handles garbled(混淆) ACK/NAKs,sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt),rdt_rcv(rcvpkt) & not corrupt(rcvpkt) & has_seq0(rcvpkt),rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & has_seq1(rcvpkt),extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt),rdt_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),sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt),rdt_rcv(rcvpkt) & not corrupt(rcvpkt) & has_seq1(rcvpkt),rdt_rcv(rcvpkt) & (corrupt(rcvpkt),sndpkt = make_pkt(ACK, chksum)udt_send(sndpkt),sndpkt = make_pkt(NAK, chksum)udt_send(sndpkt),收到报文#0,发送ACK,收到报文#1,发送ACK,收到报文#1,发送ACK,发送NAK,发送NAK,收到报文#0,发送ACK,启动,Transport Layer,3-41,rdt2.1: discussion,Sender: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 sender,Transport Layer,3-42,Rdt2.1 是否有改进的地方？,只使用ACK 应答机制，协议能否正常工作？,Transport Layer,3-43,rdt2.2: a NAK-free protocol,same 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 (ACK number)duplicate ACK at sender results in same action as NAK: retransmit current pkt重复ACK意味着需要重传某帧,rdt2.2: sender,Transport Layer,3-44,rdt2.2: receiver,Transport Layer,3-45,Transport Layer,3-46,rdt2.2: sender, receiver fragments,sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt),rdt_send(data),udt_send(sndpkt),rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) | isACK(rcvpkt,1) ),rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & isACK(rcvpkt,0),sender FSMfragment,rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & has_seq1(rcvpkt),extract(rcvpkt,data)deliver_data(data)sndpkt = make_pkt(ACK, 1, chksum)udt_send(sndpkt),rdt_rcv(rcvpkt) & (corrupt(rcvpkt) | has_seq1(rcvpkt),udt_send(sndpkt),receiver FSMfragment,L,重传,启动,发送ACK1,启动,发送ACK1,Transport Layer,3-47,Rdt2.2 存在的问题是什么？,信道不丢包的假设不合理 如果丢包则协议无法正常工作 ?,Transport Layer,3-48,rdt3.0: channels with errors and loss,New assumption: underlying channel can also lose packets (data or ACKs)checksum, seq. #, ACKs, retransmissions will be of help, but not enough,Approach: sender waits “reasonable” amount of time for ACK - timerretransmits 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 timer,Transport Layer,3-49,rdt3.0 sender,sndpkt = make_pkt(0, data, checksum)udt_send(sndpkt)start_timer,rdt_send(data),rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) |isACK(rcvpkt,1) ),sndpkt = make_pkt(1, data, checksum)udt_send(sndpkt)start_timer,rdt_send(data),rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & isACK(rcvpkt,0),rdt_rcv(rcvpkt) & ( corrupt(rcvpkt) |isACK(rcvpkt,0) ),rdt_rcv(rcvpkt) & notcorrupt(rcvpkt) & isACK(rcvpkt,1),stop_timer,stop_timer,udt_send(sndpkt)start_timer,timeout,udt_send(sndpkt)start_timer,timeout,rdt_rcv(rcvpkt),L,rdt_rcv(rcvpkt),L,L,L,启动,启动定时器,发送报文#0,发送报文#1,启动定时器,重传报文#0,重传报文#1,Transport Layer,3-50,rdt3.0 in action,Transport Layer,3-51,rdt3.0 in action,过早超时,Transport Layer,3-52,Rdt3.0 存在何问题？,上述协议都基于”停等”思路，称为停等协议（Stop-Wait Protocao）,协议的效率如何 ？,Transport Layer,3-53,Performance of rdt3.0,rdt3.0 works, but performance stinksex: 1 Gbps link, 15 ms prop. delay, 8000 bit packet:,U sender: utilization fraction of time sender busy sending,1KB pkt every 30 msec - 33kB/sec thruput over 1 Gbps linknetwork protocol limits use of physical resources!,Transport Layer,3-54,rdt3.0: stop-and-wait operation,first packet bit transmitted, t = 0,sender,receiver,RTT,last packet bit transmitted, t = L / R,first packet bit arrives,last packet bit arrives, send ACK,ACK arrives, send next packet, t = RTT + L / R,Transport Layer,3-55,Pipelined protocols,Pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pktsrange of sequence numbers must be increasedbuffering at sender and/or receiver,Two generic forms of pipelined protocols: go-Back-N, selective repeat,Transport Layer,3-56,Pipelining: increased utilization,first packet bit transmitted, t = 0,sender,receiver,RTT,last bit transmitted, t = L / R,first packet bit arrives,last packet bit arrives, send ACK,ACK arrives, send next packet, t = RTT + L / R,last bit of 2nd packet arrives, send ACK,last bit of 3rd packet arrives, send ACK,Increase utilizationby a factor of 3!,Transport Layer,3-57,Pipelining Protocols,Go-back-N: big picture:Sender can have up to N unacked packets in pipelineRcvr only sends cumulative acksDoesnt ack packet if theres a gapSender has timer for oldest unacked packetIf timer expires, retransmit all unacked packets,Selective Repeat: big picSender can have up to N unacked packets in pipelineRcvr acks individual packetsSender maintains timer for each unacked packetWhen timer expires, retransmit only unack packet,Transport Layer,3-58,Go-Back-N,Sender:k-bit seq # in pkt header“window” of up to N, consecutive unacked pkts allowed,ACK(n): ACKs all pkts up to, inclu