Subject: RE: [tcpm] revising 2581: setting ssthresh on RTOs

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Mon, 31 Jul 2006 08:27:07 -0700

Mark:

Here is my take :
- I am fine to make this change in RFC2581bis. Although I really don't
have a strong argument one way or the other regarding the scope, I would
vote for making this change in RFC2581.

- Option #2 is the way I would go. My argument on favour of #2 is that
vast majority of the internet has undergone a sea change in terms of
processing HP of the routers, bandwidth, speed of the link etc., and
recovery mechanisms needs to quickly adapt to the transient conditions
arising in these networks. I think having a larger ssthresh than before
(after successive RTO's) is fine and I see no major issues here.

$0.02,
-Anantha  

> -----Original Message-----
> From: Mark Allman [mailto:[email-masked]] 
> Sent: Monday, July 31, 2006 4:47 AM
> To: [email-masked]
> Subject: [tcpm] revising 2581: setting ssthresh on RTOs
> 
>  
> Folks-
> 
> We have talked about setting ssthresh after RTOs on this list 
> a number of times and we talked about it in Montreal.  I'd 
> like to verify what seemed the general mood in Montreal here 
> on the list.  I think this is the last bit we need to work 
> out on 2581bis.  If you have something else that you think 
> needs done to the document, please yell.
> 
> RFC 2581 says that on each RTO a TCP reduces ssthresh to 
> FlightSize / 2.  Consider a lost retransmit.  Say we RTO on 
> segment X, cut ssthresh to Y segments (Y > 2 - just for the 
> example), cwnd becomes 1 segment and the RTO is backed off.  
> Now, say we RTO on segment X again.  The cwnd will stay at 
> one, but the FlightSize is now 1 and so ssthresh takes its 
> minimum value of 2 segments.
> 
> The observation is that this forces linear growth for a 
> potentially long time if this loss hiccup was caused by some 
> small network issue like a handoff.  In that case, it'd be 
> nice to be able to keep ssthresh higher and use slow start 
> when packets started flowing again.
> 
> Also, as a practical matter I don't think the above scenario 
> is the way we intended things to work.  Rather, I think we 
> envisioned (but, alas, did not write) suggestion #1:
> 
> Suggestion #1: On the first RTO for some segment, set 
> ssthresh to FlightSize/2.  On each subsequent RTO for the 
> given segment halve ssthresh (ssthresh =/ 2).
> 
> Basically, this slowly degrades ssthresh as the RTO gets 
> backed off, such that the longer TCP has been transmitting 
> into a lousy network the less the TCP gets to use exponential 
> increase when packets start flowing again.
> 
> In addition, another variant has been suggested in the meantime, ...
> 
> Suggestion #2: On the first RTO for some segment, set 
> ssthresh to FlightSize/2.  On each subsequent RTO for the 
> given segment do not adjust ssthresh at all.
> 
> This variant means that a TCP always gets to re-probe with 
> slow start based on the pre-loss conditions no matter how 
> long it took to fix the loss. 
> 
> Both #1 and #2 are quite safe.  If the network is in a really 
> lousy state then the TCP is going to continue to get losses 
> even after getting out of RTO backoff without increasing the 
> congestion window all that much.  And, if that happens then 
> ssthresh will get further reduced (probably to its minimum).  
> Essentially, if the network is heavily loaded all of the 
> sudden then this additional loss isn't really going to be 
> exacerbated by the first couple RTTs of slow start.  If the 
> backoff was caused by something other than a suddenly 
> massively congested network then this tweak lets TCP get back 
> to a reasonable operating point more rapidly.
> 
> So, a couple of questions ... and, the authors current hits ...
> 
> (1) Is this change in-scope for 2581bis?  We said "no algorithmic
>     tweaks" and so one view is that this should be cooked 
> elsewhere and
>     rolled in later.
> 
>     The author's hit on this is that the behavior of slamming ssthresh
>     down on the first backed off RTO is not our intent and so tweaking
>     this seems in-scope.  
> 
> (2) Assuming folks are fine with making a change then which change
>     should we make?  Suggestion #1 or #2?
> 
>     The author's chatted and we feel like #2 is fine.  As noted above,
>     neither case really aggravates the state of the network 
> in suddenly
>     heavily loaded situations.  So, #2 seems OK.
> 
> What do people think?  Is #2 OK?  Or, something else?
> 
> Thanks in advance for the feedback!
> 
> allman
> 
> 
> 
> 

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: "Mahdavi, Jamshid" <[email-masked]>
Date: Mon, 31 Jul 2006 13:15:27 -0700

I also agree with option #2.

--Jamshid 

-----Original Message-----
Date: Mon, 31 Jul 2006 07:47:29 -0400
From: Mark Allman <[email-masked]>
Subject: [tcpm] revising 2581: setting ssthresh on RTOs
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Folks-

We have talked about setting ssthresh after RTOs on this list a number
of times and we talked about it in Montreal.  I'd like to verify what
seemed the general mood in Montreal here on the list.  I think this is
the last bit we need to work out on 2581bis.  If you have something else
that you think needs done to the document, please yell.

RFC 2581 says that on each RTO a TCP reduces ssthresh to FlightSize /
2.  Consider a lost retransmit.  Say we RTO on segment X, cut ssthresh
to Y segments (Y > 2 - just for the example), cwnd becomes 1 segment and
the RTO is backed off.  Now, say we RTO on segment X again.  The cwnd
will stay at one, but the FlightSize is now 1 and so ssthresh takes its
minimum value of 2 segments.

The observation is that this forces linear growth for a potentially long
time if this loss hiccup was caused by some small network issue like a
handoff.  In that case, it'd be nice to be able to keep ssthresh higher
and use slow start when packets started flowing again.

Also, as a practical matter I don't think the above scenario is the way
we intended things to work.  Rather, I think we envisioned (but, alas,
did not write) suggestion #1:

Suggestion #1: On the first RTO for some segment, set ssthresh to
FlightSize/2.  On each subsequent RTO for the given segment halve
ssthresh (ssthresh =/ 2).

Basically, this slowly degrades ssthresh as the RTO gets backed off,
such that the longer TCP has been transmitting into a lousy network the
less the TCP gets to use exponential increase when packets start flowing
again.

Suggestion #2: On the first RTO for some segment, set ssthresh to
FlightSize/2.  On each subsequent RTO for the given segment do not
adjust ssthresh at all.

This variant means that a TCP always gets to re-probe with slow start
based on the pre-loss conditions no matter how long it took to fix the
loss. 

Both #1 and #2 are quite safe.  If the network is in a really lousy
state then the TCP is going to continue to get losses even after getting
out of RTO backoff without increasing the congestion window all that
much.  And, if that happens then ssthresh will get further reduced
(probably to its minimum).  Essentially, if the network is heavily
loaded all of the sudden then this additional loss isn't really going to
be exacerbated by the first couple RTTs of slow start.  If the backoff
was caused by something other than a suddenly massively congested
network then this tweak lets TCP get back to a reasonable operating
point more rapidly.

(1) Is this change in-scope for 2581bis?  We said "no algorithmic
    tweaks" and so one view is that this should be cooked elsewhere and
    rolled in later.

    The author's chatted and we feel like #2 is fine.  As noted above,
    neither case really aggravates the state of the network in suddenly
    heavily loaded situations.  So, #2 seems OK.

allman