Re: [tcpm] ] WGLC for draft-ietf-tcpm-fastopen-05

[Yuchung Cheng <[e-mail]>]

On Tue, Nov 26, 2013 at 6:05 AM, Scharf, Michael (Michael) <
[e-mail]> wrote:

> > >>> 3) seeding the SYN RTT from a lower value makes the sender more
> > >>> aggressive in heavily congested networks. The sender is also made
> > more
> > >>> aggressive by sending IW data packets before there is any
> > indication the
> > >>> path can contain even a single data segment. This is significant
> > change to
> > >>> standard behaviour. If the proposal is to use IW 3 (as standard) it
> > still
> > >>> needs to be called out. If the proposal is to use a larger
> > experimental
> > >>> number then I have concerns here that this is a significant change
> > that
> > >>> needs an automated recovery method to prevent significant
> > collateral damage
> > >>> on capacity-limited paths - there needs to be a way to stop a
> > server doing
> > >>> this each time resulting in recurring loss!
> > >>
> > >>
> > >> when the IW of packets are not all acked, loss recovery is triggered
> > >> and window is reduced. this is part of standard CC.
> > >>
> > >> also when you use "significant" four times, please back up with a
> > good
> > >> theory or data or both. and abuse that word does not it make more
> > >> significant.
> > >>
> > > So let's see if we can see agree on what happens:
> > >
> > > - If the path is very lossey - severe congestion:
> > > TCP standard sends one SYN segment with some probability of loss, and
> > if it
> > > sees loss backs off and retransmits the SYN. As (over)load increases,
> > new
> > > sessions add 40B and the new sessions will often defer start-up,
> > controlling
> > > their rate.
> > >
> > > - If TFO path is very lossey - severe congestion: IW full-sized
> > segments are
> > > sent. Each new session does this, adding to the load.
> > > Each new session adds  MSS*IW = 6000B (IW=3) or 15000B (IW=10).
> > >
> > > I concede this applies to severe congestion. Under this case, it
> > seems 150x
> > > more traffic to me and this before before CC is engaged. Or is this
> > wrong?
> > I can make similar case for any recent proposal that will blow up the
> > network, e.g., rto-restart, newcwv. The question is how practical and
> > common those cases are. if the link is thin, not doing Fast Open with
> > same IW will experience similar heavy losses. Let's face it: if the
> > capacity is not enough to handle the demand, there is little can be
> > done.
> >
> > The concern has been raised by Michael Scharf's, and the step 6 in
> > Section 4.2.2 does mention that. I did ask the list for any better
> > solution for that but I've never heard back any suggestion.
>
> Indeed, I was (and I still am) worried by the combination of TFO and IW10.
> Because of that, we have already had similar list discussions about highly
> congested links. I am less concerned about TFO with IW3, because bursts of
> that size are sent by TCP anyway pretty frequently.
>
> However, given the explicit reference to RFC 3390 in the current draft, I
> have not further objected during the WGLC.
>
> Since this question still seems to trigger discussion, what about some
> additional explanation of "slightly more aggressive"? For instance:
>
> OLD:
>
>       Note that if SYN-ACK is lost, regular TCP reduces the initial
>       congestion window before sending any data. In this case TFO is
>       slightly more aggressive in the first data round trip even though
>       it does not change the congestion control.
>
> NEW:
>
>       Note that in some cases TFO can be slightly more aggressive than
> regular TCP.
>       If SYN-ACK is lost, regular TCP reduces the initial congestion
> window before sending any data.
>       On such a congested link, TFO could first send a burst according to
> the initial window [RFC3390],
>         and the server would then back-off after one round trip time if
> one or more packets are lost. In this case TFO is
>       slightly more aggressive in the first data round trip even though it
> does not change the congestion control.
>
sure

>
> My 2 cents, with chair hat off...
>
> Michael
>