Subject: [Tsvwg] slow-start restart

From: mbashyam <[email-masked]>
Date: Thu, 20 Feb 2003 08:41:11 -0800

Hi

Is the problem of persistent HTTP connections slow starting after an
idle period of a round trip time  been addressed?  I know the problem is
well understood and there are solutions which can preserve the
conservative spirit  behind  slow starting and also maintain  the
congestion window high enough for the subsequent transfers, but are
there any standards/drafts in progress that address this issue already?
If not is there a need to write one?

Murali

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Feb 2003 11:09:29 -0800

> If not is there a need to write one?

http://www/touch/pubs/draft-hughes-restart-00.txt

This is pending an implementation to proceed... interested ;-)?

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Feb 2003 11:21:00 -0800

> This is pending an implementation to proceed... interested ;-)?

It's also pending a better URL ;-0

http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt

Joe

---

From: Murali Bashyam <[email-masked]>
Date: Fri, 28 Feb 2003 10:37:48 -0800

> http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt

The timeout u are referring to in BOL, is the same receive timeout that exists
in today's BSD implementations, correct?  If so then BOL suffers from the same
problems of using a receive timeout,
correct? Wouldn't it be better to have a last-snd-time in TCP control block
and detect send idle
period?

Murali

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 Feb 2003 12:59:54 -0800

Murali Bashyam wrote:
> The timeout u are referring to in BOL, is the same receive timeout that 
> exists in today's BSD implementations, correct? 

There is no timeout in BOL. It's a bucket. If you send as fast as the 
bucket fills with ACKs, you can sustain the send rate. If you don't, 
then you lose the ability to burst, except for the size of the bucket. 
The loss is immediate upon reception of more ACKs than fit in the bucket.

Joe

---

From: Murali Bashyam <[email-masked]>
Date: Fri, 28 Feb 2003 15:32:48 -0800

> The loss is immediate upon reception of more ACKs than fit in the bucket.

Here's a snippet from the draft with the code for BOL, the timeout u are
referring to in the snippet is the receive timeout, correct?

Murali

The code is as follows:

          /* define the state for BOL */
               int  ack_ratio,     /* max number of packets per ack */
               int  bucket,        /* max burst size */

          #DEFINE init_win 2

          /* set the bucket on ACK receipt */
               bucket = ack_ratio * 2 + 1;

          /* set bucket on timeout */
               bucket = init_win;

          /* decrement the bucket accordingly */
               can_send = min(bucket - want_send, 0);
               bucket -= can_send;
               do_send(can_send);
               return can_send;

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 Feb 2003 16:38:23 -0800

> Joe Touch wrote:
...
>>>>>mbashyam wrote:
...
>>>>>>idle period of a round trip time  been addressed?  
...
>>>>http://www.isi.edu/touch/pubs/draft-hughes-restart-00.txt
...
 >                can_send = min(bucket - want_send, 0);

The primary function of that part of the code is to set the bucket on 
the timeout, (i.e., when it's smaller than init_win before the timeout) 
rather than to empty it down.

The use of the receive timer and init_win is designed to make this 
variant behave conservatively when the ACK clock is lost. For that, 
receive timout is correct. The problem with current code is that it uses 
"time since last received", rather than setting a flag on timeout.

Joe