TCP/IP Over Lossy Links - TCP SACK without Congestion Control - - PDF document

1

TCP/IP Over Lossy Links

• TCP SACK without Congestion Control
• 1. The History of TCP

2.Current TCP Congestion Control 3.Design Ideas: no congestion control at all 4.Measurement Results 5.Future TCP Congestion Control? 6.Conclusion

Organization

2

„Old Tahoe“: slow start and congestion avoidance after a lost packet, wait for a timeout, then perform slowstart to recover „Tahoe“ (`88): also contains fast recovery. After the reception of a triple duplicate ACKs, performs fast retransmit followed by a slowstart [Jaco88]. „Reno“ (`90): fast retransmit extended by fast recovery.

• 1. The History of TCP (incomplete)

[Jaco88] Van Jacobson, “Congestion Avoidance and Control”, ACM SIGCOMM '88 [Jaco90] Van Jacobson, “Modified TCP Congestion Avoidance Algorithm”, email to end2end- interest@ISI.EDU, April 1990

in case multiple packets are lost from a window of data, very likely, TCP „Reno“ has to wait for a timeout followed by slow start to recover [Jaco90].

But

Vegas (`94, never actually implemented): modified congestion behavior. By measuring the output queue size, equilibrium is detemined (Little‘s Law of queuing theory) [BraMalPet94]. „New Reno“ (~`94): small optimization of TCP Reno, uses partial ACKs as an indication that the following packet got lost and immediately retransmits it without leaving fast recovery. [Hoe96]. TCP SACK(~`95): added the SACK option within ACKs. Allows receiver to specify the range of packets that were received out of order. [MatmahFlRo96].

[BraMalPet94] Lawrence S. Brakmo, Sean W. O'Malley, Larry L. Peterson, „TCP Vegas: New Techniques for Congestion Detection and Avoidance“, Sigcomm 1994 [MatMahFlRo96] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, „TCP Selective Acknowledgement Options“, RFC 2018, April 1996 [Hoe96] Janey C. Hoe, “Improving the start-up behavior of a Congestion Control Scheme for TCP, Sigcomm 1996

• 1. The History of TCP (incomplete)

In contrast to all previous flavors, more than

• ne packet per RTT during fast recovery can be send

3

FACK (`96): In fast recovery, congestion window is fixed. TCP FACK uses „pipe“ variable to estimate the data in the network by taking the transmitted out-of-order segments into account, thus preventing premature timeouts [MatMah96].

[MatMah96] M. Mathis and J. Mahdavi, "Forward acknowledgement: Refining TCP congestion control“, ACM Computer Communication Review, Oct 1996.

• 1. The History of TCP (incomplete)

Slow Start: with every received ACK, double the number of packets sent. Slow start adds a window to the sender's TCP: the congestion window, called cwnd as well as a variable called ssthres

• 2. Congestion Control: slow start

The congestion window is flow control imposed by the sender. It is based on the sender's educated guess of perceived network

• congestion. Congestion Control assumes that packets are only lost

due to overfull queues.

Figure taken from [Jaco88]

exponential growth of the Congestion Window up to ssthres, then linear growth

4

• 2. Congestion Control: congestion avoidance in TCP Reno

SS time window CA SS: Slow Start CA: Congestion Avoidance Fast retransmission/fast recovery

• 2. TCP Congestion Control

TCP send rate is determined by three windows:

win=min(snd_cwnd,snd_wnd,snd_bwnd)

Congestion window assumed bottlenecks: queue sizes in the network

Advertised window assumed bottleneck: receiver’s buffer

Bandwidth window, “ACK clock” assumed bottleneck: link capacity

5

• 3. Design Idea: no congestion control at all

In contrast to UDP, the protocol will still guarantee for in-order delivery and will adopt to the link capacity. UDP? Without SACK, this flavor of TCP will perform poorly (waste of bandwidth on duplicate ACKs that can lead to timeouts) The sending rate is given by: win=min(snd_cwnd,snd_wnd,snd_bwnd) Now: win=min(snd_bwnd,snd_wnd) SACK gives us control over the now “static” window

• 4. Measurements: the emulation environment

[emu] www.emulab.net Sender with modified TCP

Router 2

Receiver with modified TCP Sender with original TCP Receiver with original TCP

Router 1 100Mbps 100Mbps 10Mbps delays for each link: 10ms, 100ms and 400ms resulting RTTs: 60ms, 600ms, 2.4 s Node 1 Node 0, „base“ Node 3, „base“ Node 2

On all links, delay=10ms. Loss rates varied from p=0, p=0.001, p=0.01, p=0.1 to p=0.2 Packt loss events are uniformly distributed. Experiment has been set up in the emulab environment [emu].

6

• 4. Measurements: collection of Data

1. Initialize tcpdump on the to-be-observed node:

sudo tcpdump -c num -w file -i if &

2. Start ttcp on the receiving node

ttcp -r -s src

3. Start ttcp on the sending node

ttcp -t -s -n num dst num

• number of packets to be captured

file - name of the dump file if

• interface to be listened to

src

• IP address of the sending node

dst

• IP address of the receiving node

[eth] www.etheral.com, packet sniffer and analyzer

Traces have been analyzed off-line with ethereal [eth].

• 4. Measurements: SACKBASE, lossless link

tcpdump started on the sender, zoomed into connection „set up“ phase

advertised receiver Window+Seq # of last ACK seq # ACKs received

size of the send window in case

• f a link bottleneck: bandwidth-delay product

7

• 4. Measurements: SACKEXP, lossless link

tcpdump started on the sender, zoomed into connection „set up“ phase

• 4. Definitions: Throughput and Goodput

Goodput: The number of packets per unit of time forwarded from sender to receiver, minus any packets lost or retransmitted, minus ACKs. Throughput: The number of packets per unit of time transmitted between sender and receiver.

8

• 4. Measurements: summary of results, competing flows

[KemXinKas04] R. Kempter, B. Xin, S. Kumar Kasera, “Towards a Composable Transport Protocol: TCP without Congestion Control”, SIGCOMM 2004 poster presentation

• 4. Measurements: summary of results, competing flows

[KemXinKas04] R. Kempter, B. Xin, S. Kumar Kasera, “Towards a Composable Transport Protocol: TCP without Congestion Control”, SIGCOMM 2004 poster presentation

9

• 5. Future TCP Congestion Control? ECN bit

Another way to do congestion control: the ECN bit

[RamFloyd99] Ramakrishnan, K.K., and Floyd, S., A Proposal to add Explicit Congestion Notification (ECN) to IP. RFC 2481, January 1999

Instead of dropping packets, a router sends a TCP an explicit message stating that the network is becoming congested. The network determines an explicit rate for a sender [RamFloyd99].

1 IP Packet IP Header ECN bit 1 IP Header TCP ACK ECN Echo

Hop-by-Hop vs. End-to-end congestion control

• 6. Conclusion
• Ambiguity in packet loss  current TCP congestion control

 low throughput over lossy links

• TCP w/o congestion control and without SACK is inefficient
• p=0.1%, SACKEXP = 91% of goodput of lossless link,

TCP SACK = 65% (at identical efficiencies of 91%)

• As losses increase to 20%, SACKEXP = goodputs ~ 700%

at similar efficiencies compared to TCP SACK

• Plan: investigate performance of SACKEXP with

Congestion Control based on the ECN bit/ICMP Source Quench

• Performance of SACKEXP has to be compared to a TCP that can

resort to a Link Layer retransmission scheme.

• What about TCP fairness????

10

Questions are welcome!

THE END

[Jaco88] Van Jacobson, “Congestion Avoidance and Control”, ACM SIGCOMM '88 [Jaco90] Van Jacobson, “Modified TCP Congestion Avoidance Algorithm”, email to end2end- interest@ISI.EDU, April 1990 [BraMalPet94] Lawrence S. Brakmo, Sean W. O'Malley, Larry L. Peterson, „TCP Vegas: New Techniques for Congestion Detection and Avoidance“, Sigcomm 1994 [MatMahFlRo96] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, „TCP Selective Acknowledgement Options“, RFC 2018, April 1996 [Hoe96] Janey C. Hoe, “Improving the start-up behavior of a Congestion Control Scheme for TCP, Sigcomm 1996 [MatMah96] M. Mathis and J. Mahdavi, "Forward acknowledgement: Refining TCP congestion control“, ACM Computer Communication Review, Oct 1996.