Subject: Re: [tcpm] Adopting draft-fairhurst-tcpm-newcwv

From: [email-masked]
Date: Mon, 3 Dec 2012 09:02:49 -0000

I suggested "PS" - largely because I did not see a need for a specific
experiment if the WG successfully finished the draft (and know it can be
implemented).
Here's my thinking:

Reasons why I think it could be PS:

 - the 5 minute period is simply a judgment call - we can decide to change
this if the WG wishes, but I suggest it always will be just a constant we
choose.

- CWV was itself EXP. The present authors suggest the experiment has now
concluded - it was safe (implemented in Linux), but was not that useful -
because many apps do not use it by default. In doing this experiment we
understand more about CWV and this new-cwv follows that work.

- There has (alas) been a process flaw - the IET-specified method has not
been deployed - instead we have a mixture of TCP behaviours some of which
do no decay of cwnd at all, and since then, the default behaviour for many
apps does not follow any RFC (STD or EXP). In this respect, if the IETF
wishes to change that now deployed base, then I recommend PS.

Reasons why EXP may be best:

- We have no implementation yet of the new method (we're working on this
and would love others to join us or to do this work themselves).

- pipeACK is new (true - implementation is needed at least for PS, but
this is planned).

- We may wish to update STD TCP's tail-cwnd behaviour during fast recovery
(see draft), but we don't know whether this should be part of the draft
yet.

- There may be other new issues emerge: e.g. would we need pacing and know
what to standardise? (see draft).

To me, I just want to get it deployed, and  recognise that the final
status will only be determined at the end of the standards process. I'm
happy to add/update whatever the draft with  text the WG suggests at the
start of this draft - e.g. explaining why the draft needs to be EXP or why
the standards status could change from PS to EXP as the work progresses.
Other thoughts?

Gorry

> On Thu, Nov 29, 2012 at 8:11 PM, Pasi Sarolahti <[email-masked]>
> wrote:
>> Hi,
>>
>> The other adoption call we did in the Atlanta meeting was about
>> draft-fairhurst-tcpm-newcwv-05. In the room there was unanimous support
>> for adopting this, but we did not discuss much about the intended status
>> of the document. I understood the authors' current preference is to go
>> for Proposed Standard, and this is what the draft header suggests. Any
>> thoughts about this? Does anyone think Experimental would be more
>> appropriate at this point (and on what basis)?
>>
> According to RFC2026 PS:
> "A Proposed Standard specification is generally stable, has resolved
>    known design choices, is believed to be well-understood, has received
>    significant community review, and appears to enjoy enough community
>    interest to be considered valuable.  However, further experience
>    might result in a change or even retraction of the specification
>    before it advances.
>
>    Usually, neither implementation nor operational experience is
>    required for the designation of a specification as a Proposed
>    Standard.  However, such experience is highly desirable, and will
>    usually represent a strong argument in favor of a Proposed Standard
>    designation."
>
> Has the idea "pipeAck" and 5min idle-time been implemented and
> evaluated in real systems/networks?
>
>
>> - Pasi
>>
>> _______________________________________________
>> tcpm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tcpm
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 5 Dec 2012 18:46:51 -0800

> (see draft), but we don't know whether this should be part of the draft
I see the draft a good starting point to challenge some fundamental flaws of
(standard) TCP. Currently people think of TCP as bulk bit-stream and saw-tooth
behavior, but it's simply not true for the Web. Most HTTP (or SPDY) are short
bursts, including videos served with progressive download. Even video chunks
are most likely being throttled by the applications.

I would suggest forgetting about updating RFC 2861. Let's solve the bigger
problem: it's common TCP does not have enough data to fill cwnd when
receiving ACKs partly due to the overdose of persistent connections.

I'd like to develop the pipe-ACK idea to solve this problem. Neal Cardwell
and I are actually experimenting a similar idea and gathering data. But
can't promise I have something to show before the next meeting

IMO, the pipe-ACK idea, if works, should just update RFC5681 as its an
important design for modern traffic. That's why I would like to see.

Thanks.

---

From: Pasi Sarolahti <[email-masked]>
Date: Fri, 7 Dec 2012 16:01:11 +0200

> experiment if the WG successfully finished the draft (and know it can be

RFC 2026 does not require that Experimental RFC defines any specific experiment. 

> Here's my thinking:

Thanks, useful reasoning about both cases.

[...]

> the standards status could change from PS to EXP as the work progresses.

It would be best if we could decide on the status early, because it may affect how people review the document. If the WG is not confident about going for PS (for example, if people feel the design options have not been sufficiently investigated), then EXP should be the default option, I think. On the other hand, if we had to change the status at a late phase, I'd be much more comfortable at downgrading from PS to EXP than promoting a document to PS after people have thought they have been looking at an experimental document.

I think it is a good idea to add some text discussing the status, for example based on what you had in the Email. This could be something to be removed from the final version, but might support us in discussing this issue further, for example in the next meeting.

- Pasi