Part1: Lecture 2! Beyond TCP!

Transcription

1 Part1: Lecture 2 Beyond TCP

2 Summary of last time TCP congestion control - Sender side that avoid loss of packets - State machine Cwnd increase and relation to ACKs and RTT TCP flow control Congestion signals timeouts Triple duplicate ACKS

3 Λ cwnd = 4Kbytes ssthresh = rwnd dupackcount = 0 timeout ssthresh = cwnd/2 cwnd = 1 MSS dupackcount = 0 retransmit missing segment dupackcount == 3 ssthresh= cwnd/2 cwnd = ssthresh + 3 retransmit missing segment duplicate ACK dupackcount++ slow start Summary New ACK new ACK cwnd = cwnd+mss dupackcount = 0 transmit new segment(s), as allowed cwnd > ssthresh Λ timeout ssthresh = cwnd/2 cwnd = 4 KBytes dupackcount = 0 retransmit missing segment timeout ssthresh = cwnd/2 cwnd = 1 dupackcount = 0 retransmit missing segment fast recovery duplicate ACK new ACK cwnd = cwnd + MSS (MSS/cwnd) dupackcount = 0 transmit new segment(s), as allowed cwnd = ssthresh dupackcount = 0 congestion avoidance New ACK New ACK cwnd = cwnd + MSS transmit new segment(s), as allowed. New ACK duplicate ACK dupackcount++ dupackcount == 3 ssthresh= cwnd/2 cwnd = ssthresh + 3MSS retransmit missing segment

4 Error recovery

5 Positive acknowledgements with retransmission It uses a positive acknowledgement schema: The ACKNOWLEDGEMENT NUMBER in the header specifies the sequence number of next missing octet (the stream flowing in the opposite direction of the segment) Events at sender side Events at receiver side Send Packet 1 Receive Packet 1 Send ACK 1 Receive ACK 1 Send Packet 2 Receive Packet 2 Send ACK 2 Receive ACK 2

6 Error recovery How does TCP handle problems in the transmission? What to do when some segments are lost? And when can you actually say in TCP that a segment is actually lost?

7 Retransmission It uses an adaptive retransmission algorithm to determine the timeout value before retransmission. Events at sender side Send Packet 1 Start timer ACK would normally arrive Events at receiver side Packet should arrive ACK should be sent Timer expires Retransmit Packet 1 Start timer Receive ACK 1 Receive Packet 1 Send ACK 1 Cancel timer How do you determine what is the ideal RTO (retransmission timeout)?

8 RTT Round trip time (RTT). The time taken by the signal to be transmitted from sender to receiver Plus acknowldegement for receipt to go from receiver to sender Speed of light in fiber: 200km/ms

9 Know more: Computing TCP s retransmission timers RFC 6298 June 2011 RTT estimation SampleRTT is measured once per RTT for packets that have been transmitted once One RTT measure per ACK if timestamp option is ON. SmoothedRTT SRTT - is the weighted average of the SampleRTTs values collected: an exponential weighted moving average SRTT = (1 α) SRTT + α SampleRTT if α = 1/ 8 = SRTT = SRTT SampleRTT

10 Timeout interval Sample RTT SRTT RTTVAR is the variation on the RTT the EWMA of the difference between SampleRTT and SRTT RTTVAR = (1 β) RTTVAR + β SampleRTT SRTT β =1/ 4 = 0.25 RTO = SRTT + max(clock, 4 DevRTT )

11 Complex TCP retransmission Premature timeout Cumulative ACKs Host A Seq=92 timeout Seq=92, 8 bytes data Seq=100, 20 bytes data Seq=92, 8 bytes data Host B Host A timeout Seq=92, 8 bytes data Seq=100, 20 bytes data X loss ACK=100 Host B Seq=92 timeout ACK=120 time time

12 TCP ACK generation Event at Receiver Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed Arrival of in-order segment with expected seq #. One other segment has ACK pending Arrival of out-of-order segment higher-than-expect seq. #. Gap detected Arrival of segment that partially or completely fills gap TCP Receiver action Delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK Immediately send single cumulative ACK, ACKing both in-order segments Immediately send duplicate ACK, indicating seq. # of next expected byte Immediate send ACK, provided that segment starts at lower end of gap

13 Performance

14 Flow control Sliding window: Initial window Acknowledged packets Window slides --->

15 Link capacity In TCP you are limited by the receive window (your upper bound). Imagine you don t have such buffers constrains: How fast you put them in? Your bandwidth in bits/sec How long you have to wait for an ACK? Your RTT in seconds What about when you have links with different bandwidth and different RTT?

16 BDP The BDP - Bandwidth Delay Product = bandwidth (bits per second) of bottleneck link * round trip time(in seconds) A network with a large BDP (>10 5 bits>12.5kbytes) is called a LFN - long fat network.

17 Problems with LFN Receive window size (wasting bandwidth) Need better RTT measurements (used for timeouts calculation) Wrapping of sequence numbers (32bits) Packet loss reduce dramatically throughput More information to be found at: Enabling High Performance Data Transfers

18 Refinements through options

19 TCP options End of option Kind =0 No operation Kind =1 Maximum segment size Kind =2 Len=4 MSS Window scale factor Kind =3 Len=3 Shift count Timestamp Kind =4 Len=10 Timestamp value Timestamp echo reply SACK Kind =5 Len=10 Left edge of 1 st block Right edge of 1 st block Left edge of N th block Right edge of N th block

20 MTU MTU - Maximum Transmission Unit: largest packet size that can travel through the network, in bytes Ethernet: 1500 bytes Ethernet w/ Jumbo frames : 9000 bytes Path MTU: the smallest MTU on an IP path, as discovered by Path MTU Discovery - or - the largest packet size that will transverse the network without fragmentation

21 Fragmentation IP packets are encapsulated in frames: DATAGRAM HEADER DATAGRAM DATA FRAME HEADER FRAME DATA IP packets are fragmented to fit within the Path MTU FRAGMENT1 HEADER FRAGMENT2 HEADER DATA2 DATA1

22 Know more: Path MTU discovery RFC Nov MSS MSS - Maximum Segment Size: the largest amount of data in bytes that a device can handle in a single and un-fragmented piece. Announced at the start of the TCP transmission in the SYN packet. The resulting IP datagram will be MSS+40bytes (20bytes TCP header and 20 bytes IP header). MTU Frame header IP header TCP header TCP data MSS

23 Window scaling option The standard receive window on TCP systems is 65K bytes. RFC 1323 TCP Large Window Extensions introduced the WSCALE option: A scale factor for the receive window Negotiated at start up (in a SYN packet), and cannot be renogotiated Cannot exceed the maximum permitted buffer size by the system Receive window should be: equal to the BPDP or better BPDP < window < BPDB + B (buffer size at intermediate routers) 11:44: IP u x.uva.nl > rembrandt0.uva.netherlight.nl.ssh: Flags [S], seq , win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val ecr 0,sackOK,eol], length 0

24 Timestamp option A timestamp is placed in very segment and used for more accurate RTT calculation, based on each received ACK. Receivers echoes back what he receives. No need to clock synchronization Provides Protection Against Wrapped Sequence Numbers (PAWS) 15:10: IP u x.uva.nl > rembrandt0.uva.netherlight.nl.ssh: Flags [P.], seq 1094:1110, ack 1609, win 65535, options [nop,nop,ts val ecr ], length 16 15:10: IP rembrandt0.uva.netherlight.nl.ssh > u x.uva.nl.55721: Flags [.], ack 1110, win 283, options [nop,nop,ts val ecr ], length 0 1

25 SACKs Know more: TCP Selective Acknowledgements Option RFC 2018 Oct An extension to the Selective Acknowledgements (SACK) Option for TCP RFC 2883 Jul It allows to acknowledge out-of-order segments selectively. It can be combined with selective retransmission. DSACK: acknowledges duplicate packets using the SACK field, using the first block. Transmitted Segment Received Segment ACK Sent (Including SACK Blocks) (data packet dropped) , SACK= , SACK= Duplicated packet , SACK= ,

26 Congestion control improvements

27 Congestion control improvements cwnd = cwnd a*cwnd (when loss is detected) cwnd = cwnd + b/cwnd (when an ACK arrives) Scalable TCP: A = and b = 0.01 = congestion window does not oscillate, throughput increases slightly High-speed TCP (HSTCP) a(w) and b(w). Particularly suitable for large BPDP networks Westwood TCP Improves on Reno, particularly on wireless links.

28 TCP CUBIC The congestion window is a cubic function of time since the last congestion event, with the inflection point set to the window prior to the event. "CUBIC: A New TCP-Friendly High-Speed TCP Variant", Injong Rhee, and Lisong Xu

29 CUBIC algorithm ACK received Recovery Update K with: cwnd = C ( t K) 3 +W max K = 3 β Wmax / C C is a scaling factor t is the elapsed time from the last window reduction Wmax is the window size just before the last window reduction K is updated at the time of last lost event Update Wmax with: W max = β W max β is a constant multiplication decrease factor

30 TCP fairness

31 TCP Fairness fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K TCP connection 1 TCP connection 2 bottleneck router capacity R

32 Why is TCP fair? Two competing sessions: additive increase gives slope of 1, as throughout increases multiplicative decrease decreases throughput proportionally R equal bandwidth share Connection 2 throughput loss: decrease window by factor of 2 congestion avoidance: additive increase loss: decrease window by factor of 2 congestion avoidance: additive increase Connection 1 throughput R

33 Fairness Fairness and UDP Fairness and parallel TCP connections multimedia apps often do not use TCP do not want rate throttled by congestion control instead use UDP: pump audio/video at constant rate, tolerate packet loss nothing prevents app from opening parallel connections between 2 hosts.

34 MPTCP Slides of this component courtesy of O. Bonaventure

35 What technology provides 3G celltower IP IP When IP addresses change TCP connections have to be re-established

36 The new bytestream model Client Server ABCDEF XYZZ D C B A IP: IP: IP: IP:

37 Principle Multipath TCP Connection establishment SYN, MP_CAPABLE SYN+ACK, MP_CAPABLE ACK, MP_CAPABLE seq=123, DSeq=1, "abc"

38 Multipath TCP Data transfer Two levels of sequence numbers ABCDEF socket Multipath TCP TCP1 TCP2 Data sequence # TCP1 sequence # TCP2 sequence # socket Multipath TCP TCP1 TCP2

39 Multipath TCP Data transfer Dseq=0,seq=123,"a" DAck=1,ack=124 DSeq=2, seq=124,"c" DAck=3, ack=125 DSeq=1, seq=456,"b" DAck=2,ack=457

40 UDP

41 Related RFC: User Datagram Protocol RFC Aug UDP UDP - User Datagram Protocol - provide an unreliable connectionless delivery service using IP to transport messages. It adds: protocol ports to distinguish between applications running on recipient machine checksum to detect and discard corrupted packets Provides data re-assembly of fragmented datagrams by combining the appropriate IP packets Source Port Length Destination Port Checksum Data octects

42 Who uses UDP? Applications that don t need reliability or byte streams. DNS, NTP, DHCP, TFTP and multicast and broadcast traffic, such as RTP (Real-time Transport Protocol)

43 TFTP - Trivial File Transfer Protocols What is useful for? For applications that don t need the full functionalities ( and complexity of FTP). Think of embedded computers. TFTP is is encoded in the ROM and can be used for the bootstrapping process.

44 Exam question An application uses UDP to send data. Describe at least two methods you could use to guarantee ordered delivery of the content at the receiving end.

45 UDP-based protocols New UDP -based protocols developed in the last years: suitable for networks with large RTT and high bandwidths (LFN - Long Fat Networks) provide reliability extend, augment or adopt portions of TCP transmission rate is governed by the application requirements RBUDP - Reliable Blast UDP UDT - UDP-based Data Transfer protocol

46 RBUDP 1. Blast (transmission) phase: Sender: send entire payload via UDP at user-specified rate Receiver: keeps track of received packets 2. Synchronization phase: Sender: sends a DONE message via TCP Receiver:sends ACK with list of received packets. Repeat blast until no missing data Send-receive rates kept in balance: Reduced memory copies Windowless flow control mechanism Learn more: Reliable Blast UDP: Predictable High Performance Bulk Data Transfer URL:

47 UDT UDP based Data Transfer protocol (UDT) developed from the early 2000 s at the University of Chicago. Configurable congestion control, selective ACKs. Used by GridFTP as data transfer protocol.

48 Beyond TCP and UDP A short journey in SCTP and QUIC

49 Test

50 SCTP

51 SCTP New features Multi homing: increased resilience to network failures Multiple streams between endpoints Bundle of SCTP messages in one SCTP packet increase performance Security features against flooding and attacks.

52 SCTP Multi-homing Every IP address of the peer is considered as a path. All paths are continuously supervised and initially confirmed. One path, the so called primary path, is used for initial data transmission. In the case of (timer based) retransmissions an alternate path is used. Loadsharing is not part of RFC 4960 but subject of ongoing research.

53 SCTP data transfer Multiplexing and demultiplexing for ordered delivery of messages. Only data sent within the same stream is delivered in sequence relative to that stream. This minimizes the impact of head of line blocking in case of message loss.

54 QUIC Some of the next slides courtesy of: QUIC: next generation multiplexed transport over UDP

55 The narrow waist of the Internet Applications IP Access technologies IP known as the narrow wast of the Internet. Changes in Internet traffic are moving the focus. HTTP as the new narrow waist, i.e. a future where most of the traffic runs over HTTP. See: HTTP as the Narrow Waist of the Future Internet by L. Popa et al.

56 QUIC Developed by Google and under standardization

57 Latency reduction

58 1 st and 2 nd time client

59 Head-of-line blocking

60 QUIC multiplexing

61 Flow control Per stream Per connection

62 NACK Use of Negative ACKnowledgments. QUIC will report: the largest_observed packet number and packets with sequence numbers lesser than the largest_observed not yet seen. Reneging is not allowed. Simpler on the sender.

63 Forward Error Correction

64 Home reading For the test on Apr. 11 read: Controlling queue delays by Nichols and Jabobsen In: ACM Networks Magazine Volume 10 Issue 5, May (up to page 6)

65 Literature Chapter 3: Transport Layer Chapter 7: Transport Over IP Few slides were adapted from: Computer Networking: A Top Down Approach, 5 th edition. Jim Kurose, Keith Ross Addison-Wesley, April 2009