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

[Joe Touch <[e-mail]>]

Hi,

On 7/20/2012 2:43 PM, Yuchung Cheng wrote:
> 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?

Not sure - it's been a long time since I cared about this ;-) The doc 
should explain what you need to figure it out...

Joe

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