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
Chapter 3 Transport Layer application presentation session transport TCP: connection oriented UDP: connectionless network link physical Transport services and protocols transport protocols run in end systems send side: breaks app messages into segments, passes to network layer rcv side: reassembles segments into messages, passes to app layer more than one transport protocol available to apps Internet: TCP and UDP message segment M datagram Hn Ht M 5/25/2017 application transport network data link physical M Ht frame Hl Hn Ht application transport network data link physical M Transport Layer: copyright J.F Kurose and K.W. Ross 3-2 Internet transport-layer protocols reliable, in-order application transport network data link physical delivery (TCP) congestion control flow control connection setup unreliable, unordered delivery: UDP no-frills extension of “best-effort” IP 5/25/2017 network data link physical network data link physical network data link physicalnetwork network data link physical data link physical network data link physical application transport network data link physical Transport Layer: copyright J.F Kurose and K.W. Ross 3-3 Recall 1. 1. 2. 2. 3. 4. 3. 5. Create a socket with the socket() system call Create a socket with the socket() system call Bind socket to address using the bind() (port and ip address) Connect the socket to the address of the server using the Listen for connections with the listen() system call connect() system call Accept a connection with the accept() system call. Send and receive data. Send and receive data over socket returned by accept TCP socket identified by 4-tuple: source IP address source port number dest IP address dest port number many simultaneous TCP sockets: each socket identified by its own 4-tuple Web servers have receiving host uses all four values to direct segment to appropriate socket Muxing/Demuxing 5/25/2017 Server host may support different sockets for each connecting client non-persistent HTTP will have different socket for each request Transport Layer: copyright J.F Kurose and K.W. Ross 3-4 UDP: User Datagram Protocol [RFC 768] “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 UDP sender, receiver each UDP segment handled independently of others 5/25/2017 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 Transport Layer: copyright J.F Kurose and K.W. Ross 3-5 Ports Well-known ports 0 to 1023 are the well-known ports. FTP 20/21, HTTP 80, Mail 25 Registered ports 1024 to 49151 are the registered ports and are assigned by Internet Assigned Numbers Authority (IANA) Dynamic, private or ephemeral ports 49152–65535 5/25/2017 0 Well-known 1023 1024 Registered 49151 49152 Private 65535 Application Layer: copyright J.F Kurose and K.W. Ross 6 UDP: more often used for streaming multimedia apps loss tolerant rate sensitive Length, in bytes of UDP segment, including header other UDP uses DNS SNMP reliable transfer over UDP: add reliability at application layer application-specific error recovery! 5/25/2017 32 bits source port # dest port # length checksum Application data (message) UDP segment format Transport Layer: copyright J.F Kurose and K.W. Ross 3-7 UDP checksum Goal: detect “errors” (e.g., flipped bits) in transmitted segment Sender: Receiver: treat segment contents compute checksum of as sequence of 16-bit integers checksum: addition (1’s complement sum) of segment contents sender puts checksum value into UDP checksum field 5/25/2017 received segment check if computed checksum equals checksum field value: NO - error detected YES - no error detected. But maybe errors nonetheless? More later …. Transport Layer: copyright J.F Kurose and K.W. Ross 3-8 Internet Checksum Example Note When adding numbers, a carryout from the most significant bit needs to be added to the result Example: add two 16-bit integers 1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 5/25/2017 Transport Layer: copyright J.F Kurose and K.W. Ross 3-9 TCP How ensure reliable data transfer? 5/25/2017 Transport Layer: copyright J.F Kurose and K.W. Ross 3-10 Could acknowledge each packet Based on old character-based protocols ASCII/EBCDIC (ACK = 06/2E, NAK = 15/3D) 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 In packet might be a bit in the TCP header 5/25/2017 Transport Layer: copyright J.F Kurose and K.W. Ross 3-11 ACK/NAK has a fatal flaw! What happens if ACK/NAK corrupted? sender doesn’t know what happened at receiver! can’t just retransmit: possible duplicate Handling duplicates: sender retransmits current pkt if ACK/NAK garbled sender adds sequence number to each pkt receiver discards (doesn’t deliver up) duplicate pkt stop and wait Sender sends one packet, then waits for receiver response 5/25/2017 Transport Layer: copyright J.F Kurose and K.W. Ross 3-12 Efficient? Could go NAK-free protocol instead of NAK, receiver sends ACK for last pkt received OK receiver must explicitly include seq # of pkt being ACKed duplicate ACK at sender results in same action as NAK: retransmit current pkt 5/25/2017 Transport Layer: copyright J.F Kurose and K.W. Ross 3-13 Cuts out one exchange: efficient? 5/25/2017 Transport Layer: copyright J.F Kurose and K.W. Ross 3-14 Pipelined protocols Pipelining: sender allows multiple, “in-flight”, yet-tobe-acknowledged pkts range of sequence numbers must be increased buffering at sender and/or receiver Two generic forms of pipelined protocols: go-Back-N, selective repeat 5/25/2017 Transport Layer: copyright J.F Kurose and K.W. Ross 3-15 Pipelining Protocols Go-back-N: overview sender: up to N unACKed pkts in pipeline receiver: only sends cumulative ACKs Selective Repeat: overview sender: up to N unACKed packets in pipeline receiver: ACKs individual pkts sender: maintains timer for each unACKed pkt doesn’t ACK pkt if there’s a gap sender: has timer for oldest unACKed pkt if timer expires: retransmit only unACKed packet if timer expires: retransmit all unACKed packets 5/25/2017 Transport Layer: copyright J.F Kurose and K.W. Ross 3-16 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, including seq # n - “cumulative ACK” may receive duplicate ACKs (see receiver) timer for each in-flight pkt timeout(n): retransmit pkt n and all higher seq # pkts in window 5/25/2017 Transport Layer: copyright J.F Kurose and K.W. Ross 3-17 GBN in action 5/25/2017 Transport Layer: copyright J.F Kurose and K.W. Ross 3-18 Selective Repeat receiver individually acknowledges all correctly received pkts buffers pkts, as needed, for eventual in-order delivery to upper layer sender only resends pkts for which ACK not received sender timer for each unACKed pkt sender window N consecutive seq #’s again limits seq #s of sent, unACKed pkts 5/25/2017 Transport Layer: copyright J.F Kurose and K.W. Ross 3-19 Selective repeat: sender, receiver windows 5/25/2017 Transport Layer: copyright J.F Kurose and K.W. Ross 3-20 Selective repeat in action 5/25/2017 Transport Layer: copyright J.F Kurose and K.W. Ross 3-21 TCP seq. #’s and ACKs Seq. #’s: byte stream “number” of first byte in segment’s data ACKs: seq # of next byte expected from other side cumulative ACK Q: how receiver handles out-of-order segments A: TCP spec doesn’t say, - up to implementer 5/25/2017 Host A User types ‘C’ Full Duplex Host B host ACKs receipt of ‘C’, echoes back ‘C’ host ACKs receipt of echoed ‘C’ simple telnet scenario Transport Layer: copyright J.F Kurose and K.W. Ross time 3-22 TCP segment structure 32 bits URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) 5/25/2017 source port # dest port # sequence number acknowledgement number head not UA P R S F len used checksum Receive window Urg data pointer Options (variable length) application data (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept length Transport Layer: copyright J.F Kurose and K.W. Ross 3-23 TCP Round Trip Time and Timeout Q: 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 5/25/2017 Q: how to estimate RTT? SampleRTT: measured time from segment transmission until ACK receipt ignore retransmissions SampleRTT will vary, want estimated RTT “smoother” average several recent measurements, not just current SampleRTT Transport Layer: copyright J.F Kurose and K.W. Ross 3-24 TCP Round Trip Time and Timeout EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT Exponential weighted moving average influence of past sample decreases exponentially fast typical value: = 0.125 5/25/2017 Transport Layer: copyright J.F Kurose and K.W. Ross 3-25 Example RTT estimation: RTT: gaia.cs.umass.edu to fantasia.eurecom.fr 350 RTT (milliseconds) 300 250 200 150 100 1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106 time (seconnds) SampleRTT 5/25/2017 Estimated RTT Transport Layer: copyright J.F Kurose and K.W. Ross 3-26 TCP Round Trip Time and Timeout Setting the timeout EstimtedRTT plus “safety margin” large variation in EstimatedRTT -> larger safety margin first estimate of how much SampleRTT deviates from EstimatedRTT: DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT| (typically, = 0.25) Then set timeout interval: TimeoutInterval = EstimatedRTT + 4*DevRTT 5/25/2017 Transport Layer: copyright J.F Kurose and K.W. Ross 3-27 How does TCP ACK [RFC 1122, RFC 2581] Event at Receiver TCP Receiver action Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed Delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK Arrival of in-order segment with expected seq #. One other segment has ACK pending Immediately send single cumulative ACK, ACKing both in-order segments Arrival of out-of-order segment higher-than-expect seq. # . Gap detected Immediately send duplicate ACK, indicating seq. # of next expected byte Arrival of segment that partially or completely fills gap Immediate send ACK, provided that segment starts at lower end of gap 5/25/2017 Transport Layer: copyright J.F Kurose and K.W. Ross 3-28 Fast retransmit time-out period often seq # x1 seq # x2 seq # x3 seq # x4 seq # x5 relatively long: Host A long delay before resending lost packet detect lost segments ACK x1 ACK x1 ACK x1 ACK x1 triple duplicate ACKs sender often sends many segments back-toback if segment is lost, there will likely be many duplicate ACKs for that segment 5/25/2017 X timeout via duplicate ACKs. Host B time Transport Layer: copyright J.F Kurose and K.W. Ross 3-29 TCP Flow Control flow control sender won’t overflow receiver’s buffer by transmitting too much, too fast receive side of TCP connection has a receive buffer: (currently) TCP data application IP unused buffer (in buffer) process datagrams space speed-matching service: matching send rate to receiving application’s drain rate app process may be slow at reading from buffer 5/25/2017 Transport Layer: copyright J.F Kurose and K.W. Ross 3-30 TCP congestion control: goal: TCP sender should transmit as fast as possible, but without congesting network Q: how to find rate just below congestion level decentralized: each TCP sender sets its own rate, based on implicit feedback: ACK: segment received (a good thing!), network not congested, so increase sending rate lost segment: assume loss due to congested network, so decrease sending rate 5/25/2017 Transport Layer: copyright J.F Kurose and K.W. Ross 3-35 TCP congestion control: bandwidth probing “probing for bandwidth”: increase transmission rate on receipt of ACK, until eventually loss occurs, then decrease transmission rate continue to increase on ACK, decrease on loss (since available bandwidth is changing, depending on other connections in network) sending rate ACKs being received, so increase rate X X loss, so decrease rate X X TCP’s “sawtooth” behavior X time 5/25/2017 Transport Layer: copyright J.F Kurose and K.W. Ross 3-36 The End 5/25/2017 Transport Layer: copyright J.F Kurose and K.W. Ross 3-40