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

[Yuchung Cheng <[e-mail]>]

On Tue, Nov 26, 2013 at 11:51 AM, <[e-mail]> wrote:

> See below...
>
> > 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
> >
>
> The description is basically OK - but I don't agree on two points:
>
> My point is that this DOES change the congestion control in the most
> critical starvation prevention mode (i.e. under heavy load): It allows a
> single TCP session to send up to IW bytes into the network without
> confirming the path is available. This is not a trivial change. It makes
> significant assumptions about the buffering on the path, and the level of
> current congestion - for high rate links this may be OK (likely no impact)
> for low rate links this is a change that I would expect could make a
> significant difference.
>

> I don't understand why this is described as  "slightly" when a standard
> TCP sends 40B in 1 packet before it has validated the path, and this
> proposed change can send up to IW (10?) packets - that 10x the rate - in
> bytes this increases to x250 the sending rate (which may be what matters
> for slow links).
>
I will remove the word "slightly" if you can stop using "significantly",
b/c both are subjective w/o good data to back-up


> Whether this matters I think needs to be determined, especially if there
> are robust ways to prevent this happening repeatedly over the same path.
>
What's your idea?


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