Subject: Re: rate based pacing

From: Shivkumar Kalyanaraman <[email-masked]>
Date: Sat, 31 Jan 1998 09:15:11 -0500 (EST)

Mohit,

We have done some initial work in this area.

See:
http://networks.ecse.rpi.edu/~shivkuma/tm-papers.html

Please note that we will have a revised version of the paper there soon.

I believe a paper of Dr. KK Ramakrishnan 
on the same topic which will appear in INFOCOM 98. 

There are some limitations currently of writing directly into the TCP
headers (esp w/ authentication or security), but we hope it will have some
relevance in the diff serv work, where the network edge could respond to
feedback if not the source (through a proprietary protocol if not through
TCP headers).

regards
-Shiv

===
Shivkumar Kalyanaraman   
Assistant Professor, Dept of Electrical, Computer and Systems Engg,
Rensselaer Polytechnic Institute (RPI)
110, 8th Street, Rm JEC 6042, Troy NY 12180-3590
Ph: 518 276 8979  Secy (6313)	 Fax: 518 276 2433
Email: [email-masked]
Internet: http://www.ecse.rpi.edu/Homepages/shivkuma

On Fri, 30 Jan 1998, Mohit Aron wrote:

> Hi,
> 	there have been some suggestions about using rate based pacing in
> TCP for improving performance. Can someone please send me some pointers on
> work done on this issue. Thanks,
> 
> 
> 
> - Mohit
>

---

From: Jon Crowcroft <[email-masked]>
Date: Sat, 31 Jan 1998 15:44:24 +0000

In message <[email-masked]>, Shivkumar K

 >>http://networks.ecse.rpi.edu/~shivkuma/tm-papers.html

see also our tcp work a while back
at
ftp://cs.ucl.ac.uk/darpa/multcp.ps
based on frank kelly's theoretical work
at:

http://www.statslab.cam.ac.uk/~frank/pf/ 

 >>feedback if not the source (through a proprietary protocol if not through
 
sounds interesting!
 >>> work done on this issue. Thanks,

 cheers

   jon

---

From: John Heidemann <[email-masked]>
Date: Sat, 31 Jan 1998 10:32:19 -0800

>work done on this issue. Thanks,

We've looked at using pacing to help TCP resume transmission after a
connection goes idle.  A tech report describing the work is available
at <http://www.isi.edu/~johnh/PAPERS/Visweswaraiah97b.html>.

   -John Heidemann
    USC/ISI

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 03 Feb 1998 00:41:33 +0000

>>at <http://www.isi.edu/~johnh/PAPERS/Visweswaraiah97b.html>.
 
John 

[email-masked],[email-masked]

restart of idle TCP - 
whats the cost of the clock interrupt for the RBP rate?
or is there a neat hack?
 cheers

   jon

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 03 Feb 1998 00:40:52 +0000

>>http://networks.ecse.rpi.edu/~shivkuma/tm-papers.html

1/
couldn't you just trigger RED rather than rewriting the Rx advertised Window 
2/
what if route change ? don't you get real bad sender behaviour
(esp. if route flap!) - get burst of W and W' alternating?

?

nice stuff though...

---

From: Shivkumar Kalyanaraman <[email-masked]>
Date: Mon, 2 Feb 1998 20:50:12 -0500 (EST)

> couldn't you just trigger RED rather than rewriting the Rx advertised Window 

We are evaluating a host of choices including ECN and RED. 
We have recently found that pacing acks (what we refer to as "ack-bucket") 
based upon ABR scheme explicit rate seems to give us fairness. Yes this
has problems with asymmetric paths ...

> (esp. if route flap!) - get burst of W and W' alternating?

Yes ... this can get rough. Our goal was to float the concept and see
how far it can go. We are trying to avoid writing to the Rx using
the alternatives mentioned above - to avoid requiring knowledge of
RTT.

Cheers
Shivkumar

---

From: John Heidemann <[email-masked]>
Date: Wed, 04 Feb 1998 17:07:03 -0800

>whats the cost of the clock interrupt for the RBP rate?

The cost is small, of course :->

Unlike other timers in BSD TCPs we only enable RBP timers when pacing
is going on.  Since we use pacing to recover from idle periods and
such periods are ~1 RTT, this cost is quite small.  In fact, the cost
of the timer is less than the cost of the bookkeeping for a higher
resolution RTT estimate.

Specifically, in our experiment we retrieved 4 web pages from Yahoo's
hierarchy (actually, copies of the pages).  Pacing was used on 3 of
them (on the first we used normal slow start).  We found only about 2%
of the time spent in TCP-related code was spent in the interrupt
service routine.

There's also a marketing argument, to stray slightly from the
technical:  CPUs (in web servers) are cheap, web users are expensive.
Trading a little CPU time to get your content there faster is probably
a good deal for some people.

   -John Heidemann