[Iccrg] Re: [tcpm] Review of draft-fairhurst-tcpm-newcwv-03

[[e-mail] (Yuchung Cheng)]

On Fri, Jul 20, 2012 at 8:25 AM, Joe Touch <[e-mail]> wrote:
>
>
> On 7/20/2012 7:37 AM, Yuchung Cheng wrote:
> ...
>
>>> The server receives the request, and then sends a response. The server
>>> has a
>>> response that's typically larger - thus the burst. The server decides
>>> "how
>>> long has it been since I *received* anything? Since that time is very
>>> short,
>>
>>
>> but RFC 2861 does not use the most recently received timing? not in their
>> main algorithm (section 3.2) at least.
>
>
> I'm referring to the algorithm  as per Standard TCP [RFC5681] which, resets
> CWND to the restart window after the app goes idle (as described in this
> doc). However, RFC  2681 failed to note that the restart algorithm was
> widely deployed at the time, and was based on erroneous logic in a footnote
> of an unpublished extension of Van Jacobson's 1988 congestion control paper
> (ax explained in detail in draft-hughes-restart-00.txt).
>
>
>>> there's no slow-start restart, and the burst goes out.
>>>
>>> The only time the server would timeout and do slowstart restart would be
>>> if
>>> it decides to send something a while after anything has been received -
>>> that
>>> might occur for auto-refresh pages, but not much else.
>>>
>>> The issue is explained in detail here: J. Heidemann, K. Obraczka, J.
>>> Touch,
>>> ?Modeling the Performance of HTTP Over Several Transport Protocols,?
>>> IEEE/ACM Transactions on Networking, V5, N5, Oct. 1997, pp.616-630.
>>
>>
>> But why does receiving something recently justify the sending cwnd is safe
>> to
>>   not cause burst-induced losses? Sorry but I can't find the explanation
>> in
>> the paper.
>
>
> It doesn't justify it - it was an incorrect conclusion. The goal is "restart
> if you haven't SENT in a while", but Van's footnote said that most
> implementations at that time had a 'time since last received' timer, but not
> a 'time since last sent', and that because TCP is symmetric you can use the
> receive timer instead of the send one. That logic was false, and persistent
> HTTP turned out to have exactly that pattern.
>
> However, the mechanism proposed in this doc still allows most HTTP exchanges
> to burst an entire window - because it would be very likely that users will
> click on URLs within a received page within the 5 minute timeout.
>
> I.e., I don't think section 4 of this doc is appropriate (it still amounts
> to a send timer), and still favor the "burst-or-lose" style approach as
> recommended in draft-hughes-restart-00.txt.
I enjoy reading this draft. Very nice summary of all the mechanisms proposed!
I also like burst-or-lose due to its simplicity (and is interested in
rate-pacing as well).

In burst-or-lose, do the acks of the N packets increment the cwnd if
FlightSize < cwnd?

I'd recommend newcwv draft to cite and discuss hugest-restart draft.
>
> Joe
>
>
>