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

[Yuchung Cheng]

On Thu, Jul 19, 2012 at 10:37 AM, Joe Touch <touch at isi.edu> wrote:
>
>
> On 7/19/2012 10:26 AM, Yuchung Cheng wrote:
>>
>> On Thu, Jul 19, 2012 at 8:05 AM, Joe Touch <touch at isi.edu> wrote:
>>>
>>>
>>>
>>> On 7/16/2012 4:10 PM, Joe Touch wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On 7/16/2012 3:56 PM, Yuchung Cheng wrote:
>>>>>
>>>>>
>>>>> Summary:
>>>>>
>>>>> First of all the problem this draft is trying to solve is important:
>>>>> AFAIK servers and data-centers disable slow-start after idle because
>>>>> it simply hurts latency too badly.
>>>>
>>>>
>>>>
>>>> If they're mostly doing HTTP, it shouldn't matter at all. HTTP's
>>>> transaction pattern defeats slow-start after idle anyway.
>
>>
>>
>> Why not if the interval between two HTTP responses are large, say two
>> minutes?
>> Your draft below suggested receiving HTTP requests have some effects but
>> I didn't see that in RFC 2861 (and I couldn't find the mailing list
>> discussion
>> cited either).
>
>
> Let's say the connection goes idle for 2 minutes. TCP doesn't do anything
> when a connection goes idle; it only does things when something is sent (in
> general).
>
> The most likely reason the server would have something new to send is that
> the client sends a new request. The client request is short enough to fit in
> 1-2 segments, so shouldn't be an issue (and Nagle should be off, since it's
> interactive with multibyte exchanges).
>
> 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.

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

>
> Joe