Subject: Re: [tcpm] New ID available: RFC2988bis (RTO calculation)

From: Alexander Zimmermann <[email-masked]>
Date: Wed, 24 Feb 2010 15:47:07 +0100

Hi Mark,

what a quick response :-)

Am 24.02.2010 um 14:45 schrieb Mark Allman:

> 
>> currently the document only suggests lowering the initial RTO.
>> IMHO we should also discuss if we want to lower the minimal RTO, too.
> 
> I have two responses to this ...
> 
>  - First, I sent a technical note to the list on Feb/11 about changing
>    the min.  

Sure? On this list...?
Anyway, since you appended the text, I can read it.

> I am appending that to this note.
> 
>  - Second, it seems that we should keep these two questions independent
>    to me.  It seems to me that changing the initRTO is pretty minor and
>    well-scoped, whereas changing the minRTO has more unknowns.  So, I
>    am not at all opposed to thinking about both changes as you suggest,
>    but coupling them is likely to hinder progress on the initRTO
>    (IMO). 

Yes, full ACK. However, I suggest that we add some text (like
your appended note below or your comments here 
http://www.ietf.org/mail-archive/web/tcpm/current/msg02937.html)
to the draft, why we not lower minRTO at this time.

Alex

> 
> Just my 2c.
> 
> allman
> 
> 
> 
> 
>> Is it time to reconsider a smaller minimum RTO as well? 
> 
> One problem with the minimum is we don't know what to set it at [*].
> The finding in [AP99] is that as you reduce the min you take more
> spurious timeouts.  The tradeoff seemed fundamental to us.  But, given
> our methodology (trace driven simulation) we could not really tell the
> impact of the spurious timeouts.  So, we just sought to minimize them in
> the spec.  I know some TCP implementations are being pretty aggressive
> with the min these days.  But, it is not at all clear to me whether this
> is a net win or net lose.  I.e., is the win in terms of peppiness to
> needed retransmits still a win when it is played against the
> consequences of a spurious transmit (i.e., setting cwnd = 1)?  Perhaps
> there is a sweet spot that is < 1sec whereby this tradeoff better
> balances and we should be using that.  But, it'd take a big experiment
> to show that, I think.
> 
> [*] Maybe there is work that I just don't know about and if so I'd like
>    to be pointed at it.
> 
> Another thing I have wondered about from time to time .... Much like
> Early Retransmit could we have some sort of early RTO when the cwnd size
> is small?  When the window size is small it seems that the downside of
> making a bad rexmt decision is not as bad as when the cwnd is large so
> it might pay in terms of responsiveness to RTO sooner.  Also, as the
> cwnd gets larger we have better loss recovery techniques that should
> come into play that can repair lots of loss without involving the RTO
> and so perhaps by being overly aggressive in the RTO we just hurt
> ourselves.  Finally, as the cwnd gets bigger that means we are
> transferring more data.  And, the longer a connection goes the less
> important the fine-grained responsiveness matters.  Just a random
> thought ...
> 
> allman
> 
> 
> 

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22220
// email: [email-masked]
// web: http://www.umic-mesh.net
//