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

["Scharf, Michael (Michael)" <[e-mail]>]

> >>> 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.

My 2 cents, with chair hat off...

Michael