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

[Yuchung Cheng <[e-mail]>]

On Mon, Dec 3, 2012 at 1:02 AM,  <[e-mail]> wrote:
>
> 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.
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.

>
> - 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 <[e-mail]>
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>
>