Summary of last time!

Transcription

1 Summary of last time Part1: Lecture 2 More TCP and beyond TCP TCP congestion control Multiplexing TCP header TCP flags TCP flow control End-to-end principle Sequence numbers and acks Establish and terminate connection Λ 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 New ACK new ACK cwnd = cwnd + MSS.(MSS/cwnd) dupackcount = 0 transmit new segment(s), as allowed congestion avoidance New ACK New ACK cwnd = ssthresh dupackcount = 0 duplicate ACK dupackcount++ dupackcount == 3 ssthresh= cwnd/2 cwnd = ssthresh + 3MSS retransmit missing segment Error recovery duplicate ACK cwnd = cwnd + MSS transmit new segment(s), as allowed 1

2 Positive acknowledgements with retransmission Error recovery 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 How does TCP handle problems in the transmission? Send Segment 1 Receive Segment 1 What to do when some segments are lost? Receive ACK 1 Send Segment 2 Send ACK 1 Receive Segment 2 And when can you actually say in TCP that a segment is actually lost? Send ACK 2 Receive ACK 2 Retransmission RTT It uses an adaptive retransmission algorithm to determine the timeout value before retransmission. Events at sender side Events at receiver side Send Packet 1 Packet should arrive Start timer ACK would normally arrive Timer expires Retransmit Packet 1 ACK should be sent 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 Start timer Receive ACK 1 Receive Packet 1 Send ACK 1 Cancel timer How do you determine what is the ideal RTO (retransmission timeout)? Speed of light in fiber: 200km/ms 2

3 19/02/18 RTT estimation Know more: Computing TCP s retransmission timers RFC 6298 June 2011 Timeout interval 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 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 ) Bufferbloat Queueing 1. TCP stream starts sending traffic 2. Large buffer on bottleneck node starts filling up 3. TCP does not notice packet loss, increases CWND 4. Large buffer is completely filled 5. Packet loss is only detected when buffer is full 6. Huge delay and jitter 7. Throughput is bad Bufferbloat is the undesirable latency that comes from the existence of excessively large (bloated) buffers in systems, particularly network communication systems. - J Gettys 3

4 19/02/18 Complex TCP retransmission TCP ACK generation Premature timeout Host A Seq=92 timeout Seq=92 timeout time Seq=92, 8 bytes data Seq=100, 20 bytes data ACK=100 ACK=120 Seq=92, 8 bytes data ACK=120 Host B Host A timeout time Cumulative ACKs Seq=92, 8 bytes data Seq=100, 20 bytes data X loss ACK=120 ACK=100 Host B 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 Flow control Sliding window: Initial window Performance Window slides ---> Acknowledged packets

5 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 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. What about when you have links with different bandwidth and different RTT? 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 Refinements through options More information to be found at: Enabling High Performance Data Transfers 5

6 TCP options MTU End of option No operation Maximum segment size Window scale factor Kind =0 Kind =1 Kind =2 Kind =3 Len=4 Len=3 MSS Shift count 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 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 Fragmentation MSS Know more: Path MTU discovery RFC Nov IP packets are encapsulated in frames: FRAME HEADER DATAGRAM HEADER FRAME DATA IP packets are fragmented to fit within the Path MTU FRAGMENT1 HEADER FRAGMENT2 HEADER DATAGRAM DATA2 DATA1 DATA 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). Frame header IP header MTU TCP header TCP data MSS 6

7 19/02/18 Window scaling option Timestamp 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 BDP or better BDP < window < BDB + B (buffer size at intermediate routers) 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 :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 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= Congestion control improvements , SACK= Duplicated packet , SACK= ,

8 19/02/18 Congestion control improvements cwnd = cwnd a*cwnd (when loss is detected) cwnd = cwnd + b/cwnd (when an ACK arrives) 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. 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 BDP networks Westwood TCP Improves on Reno, particularly on wireless links. "CUBIC: A New TCP-Friendly High-Speed TCP Variant", Injong Rhee, and Lisong Xu ACK received CUBIC algorithm 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 Recovery Update K with: cwnd = C ( t K) 3 +W max K = 3 β Wmax / C Update Wmax with: W max = β W max β is a constant multiplication decrease factor TCP fairness 8

9 TCP Fairness Why is TCP fair? fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K Two competing sessions: additive increase gives slope of 1, as throughout increases multiplicative decrease decreases throughput proportionally R equal bandwidth share TCP connection 1 TCP connection 2 bottleneck router capacity R 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 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. MPTCP Slides of this component courtesy of O. Bonaventure 9

10 19/02/18 What technology provides The new bytestream model 3G celltower Client Server ABCDEF IP XYZZ D C B A IP: IP When IP addresses change TCP connections have to be re-established Multipath TCP Connection establishment Principle SYN, MP_CAPABLE IP: IP: Multipath TCP Data transfer Two levels of sequence numbers ABCDEF SYN+ACK, MP_CAPABLE ACK, MP_CAPABLE seq=123, DSeq=1, "abc" IP: socket socket Multipath TCP Multipath TCP TCP1 Data sequence # TCP1 TCP1 sequence # TCP2 TCP2 sequence # TCP2 10

11 Multipath TCP Data transfer Dseq=0,seq=123,"a" DAck=1,ack=124 DSeq=2, seq=124,"c" DAck=3, ack=125 UDP DSeq=1, seq=456,"b" DAck=2,ack=457 UDP Related RFC: User Datagram Protocol RFC Aug Who uses 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 0 appropriate IP packets Source Port Length Destination Port Checksum 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) Data octects 11

12 TFTP - Trivial File Transfer Protocols Exam question 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. 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. 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 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: 12

13 UDT UDP based Data Transfer protocol (UDT) developed from the early 2000 s at the University of Chicago. Configurable congestion control, selective ACKs. Beyond TCP and UDP A short journey in SCTP and QUIC Used by GridFTP as data transfer protocol. Test SCTP 13

14 SCTP New features Multi homing: increased resilience to network failures Multiple streams between endpoints Bundle of SCTP messages in one SCTP packet increase performance 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. Security features against flooding and attacks. 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. QUIC Some of the next slides courtesy of: QUIC: next generation multiplexed transport over UDP 14

15 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. QUIC Developed by Google and under standardization Latency reduction 1 st and 2 nd time client 15

16 Head-of-line blocking QUIC multiplexing Per stream Flow control 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. Per connection 16

17 19/02/18 Forward Error Correction Home reading For the test on Feb. 16 read: Controlling queue delays by Nichols and Jabobsen In: ACM Networks Magazine Volume 10 Issue 5, May (up to page 6) Literature Chapter 3: Transport Layer Chapter 3: Transport Layer Chapter 7: Transport Over IP 17