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

[[e-mail]]

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

Whether this matters I think needs to be determined, especially if there
are robust ways to prevent this happening repeatedly over the same path.

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

Gorry