Subject: RE: [Tsvwg] F-RTO - open issues?

From: [email-masked]
Date: Wed, 9 Oct 2002 16:41:20 -0500

Hi,

I would like to point out a couple of issues with FRTO draft which are not clearly stated(I have already pointed this out to Pasi, but I think its important to get IETF opinion. I think its possible to have more innovative solutions that can solve these problems--of course the onus lies on us to provide that. Just hang in there for few more days ...)

-- Since FRTO reduces the value of SS_THRESH after a spurious timeout, if a spurious timeout occurs when the number of outstanding packets is small, the entire throughput of the connection can be seriously degraded because the TCP sender will enter congestion avoidance too early. For example, if the spurious timeout occurs at the start of the connection when packets in flight is 2, the SS_THRESH will get set to 2. If the actual SS_THRESH were to be 100, this connection will spend ~ 98*RTT to reach a reasonable throughput. 

-- In addition to spurious timeout, if there is even a single packet loss into the stalled congestion window, the congestion window will be halved twice--once because of spurious timeout, and once again  because of fast-retransmit fast-recovery. The second rate halving is however not needed since the loss was form the same congestion window. This will again reduce the over all throughput of the connection. I think, any algorithm that tries to change the congestion window MUST recover all lost packets within that window. 

-- If in addition to spurious timeout, if more than 1/2 of the congestion window is lost, the TCP sender will timeout again, because there will not be enough ACKs generated to open up the congestion window to send new data. Again, any algorithm that tries to change the congestion window MUST also recover from all losses without any further need for timeout. Every TCP connection at the end of first slow start--when the SS_THRESH is infinite--has a possibility of losing half of its congestion window, so the event of 1/2 cwnd loss and spurious timeout occurring together is not as unlikely as it may sound.

Although at this point it might seem tempting to get rid of rate halving altogether, but an appropriate congestion control must be used if we want to avoid congestion after a spurious timeout. Please also note that spurious timeouts are not just once-in-while events. They can occur quite frequently with certain network architecture (and probably the right solution will be to change such network architectures, but no one seems to be willing to endorse this view). I think the FRTO draft does not address all these issues adequately. 

Please let me know your opinion.

Thanks
Best Regards
Yogesh

> -----Original Message-----
> From: ext Mark Allman [mailto:[email-masked]]
> Sent: Wednesday, October 09, 2002 3:18 PM
> To: Andrei Gurtov
> Cc: Sarolahti Pasi (NRC/Helsinki); [email-masked]; Reiner Ludwig (EED)
> Subject: Re: [Tsvwg] F-RTO - open issues? 
> 
> 
> 
> > 3. Have you thought about protection against malicious TCP
> > receivers?
> 
> Yes!!!
> 
> Think of a receiver ACK splitting so the first half of the RTO-ed
> segment is acknowledged in one ACK packet and the second half of the
> RTO-ed segment is ACKed seperately in a second ACK packet.  That
> fools your algorithm into thinking the retransmit was spurious and
> not reducing cwnd as much (aiding the receiver).
> 
> Of course, that is pretty easy to fix -- i.e., make sure the first
> ACK covers at least the number of bytes sent in the RTO-ed segment.
> 
> allman
> 
> 
> --
> Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg
> 
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Wed, 9 Oct 2002 20:55:42 -0400 (EDT)

On Wed, 9 Oct 2002 [email-masked] wrote:

<snip>
> Please also note that spurious timeouts are not just once-in-while
> events. They can occur quite frequently with certain network
> architecture (and probably the right solution will be to change such
> network architectures, but no one seems to be willing to endorse this
> view).
<snip>

I don't follow this point. What kind of architectures cause spurious
timeouts and how would you change them to avoid spurious timeouts?

~armando

0--                                                --0
| Armando L. Caro Jr.     |       [email-masked] |
| University of Delaware  |  www.cis.udel.edu/~acaro |
0--                                                --0

---

From: Pasi Sarolahti <[email-masked]>
Date: Thu, 10 Oct 2002 14:50:12 +0300

On Thursday 10 October 2002 00:41, [email-masked] wrote:

> -- Since FRTO reduces the value of SS_THRESH after a spurious
> timeout, if a spurious timeout occurs when the number of outstanding
> packets is small, the entire throughput of the connection can be
> seriously degraded because the TCP sender will enter congestion
> avoidance too early. For example, if the spurious timeout occurs at
> the start of the connection when packets in flight is 2, the
> SS_THRESH will get set to 2. If the actual SS_THRESH were to be 100,
> this connection will spend ~ 98*RTT to reach a reasonable throughput.

Yep. But this is the case also with regular TCP, or when ECN-Echo hits 
the sender. This does not necessary make it any more righteous, but one 
guideline behind F-RTO was to go on with as little modifications to TCP 
as possible.

The one thing I was asking for opinions was about what should be done 
with the congestion control parameters after spurious RTO. I gave a 
couple of points why we thought it may be better to reduce ssthresh 
similarly to standard TCP. But if generally the opinion is for 
reverting congestion control parameters to values before spurious RTO, 
it can be done. The risks of making a wrong decision in that case are 
about the same than Eifel has, as far as I see it. But if there are no 
clear consensus about reverting CC parameters, I still think it would 
be maybe better to let it be as it currently is in the draft. In fact, 
I see the congestion control actions taken after spurious RTO quite 
independent from the F-RTO logic.

(which makes me wonder whether this WG should give general guidelines 
about adjusting CC after spurious RTO in a separate document. The 
different schemes for recovering from spurious RTO should be equally 
aggressive anyway.)

> -- In addition to spurious timeout, if there is even a single packet
> loss into the stalled congestion window, the congestion window will
> be halved twice--once because of spurious timeout, and once again 
> because of fast-retransmit fast-recovery. The second rate halving is
> however not needed since the loss was form the same congestion
> window. This will again reduce the over all throughput of the
> connection. I think, any algorithm that tries to change the
> congestion window MUST recover all lost packets within that window.

Ok. This speaks for reverting congestion control, if one assumes that 
spurious RTO is not a congestion event of its own.

> -- If in addition to spurious timeout, if more than 1/2 of the
> congestion window is lost, the TCP sender will timeout again, because
> there will not be enough ACKs generated to open up the congestion
> window to send new data. Again, any algorithm that tries to change
> the congestion window MUST also recover from all losses without any
> further need for timeout. Every TCP connection at the end of first
> slow start--when the SS_THRESH is infinite--has a possibility of
> losing half of its congestion window, so the event of 1/2 cwnd loss
> and spurious timeout occurring together is not as unlikely as it may
> sound.

I think this is a general characteristic of TCP. If you lose more than 
half the window, you are doomed to RTO in many cases anyway (although 
NewReno happens to avoid it). Besides, in such a case F-RTO has a good 
chance of going into traditional branch, because it looks for the next 
two acks after the one that triggered RTO.

Thanks,
- Pasi