[e2e] interaction between TCP and rate limiting in routers

[Shivkumar Kalyanaraman]

Jon,

I think it is well understood that the Packeteer box works only at the
access and cannot discover congestion at downstream points (i.e. it
cannot find the shadow prices of those points). I surmised that the
folks here also wanted a rate-shaper at the entry point of an ISP.

-Shiv


>
> unless you figorue out what to do about shadow pricing for routes,
> this is on a hiding to nowhere...
>
> In message <Pine.GSO.4.40.0204021029330.13842-100000 at shiv.ecse.rpi.edu>, Shivkumar Kalyanaraman type
> d:
>
>  >>Check out packeteer.com which has been doing this since 1995.
>  >>
>  >>We wrote a paper with them in 2000 (TCP Rate control). See:
>  >>http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc-2000.html
>  >>or
>  >>http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers-rpi.html#tcp
>  >>and references therein.
>  >>
>  >>best
>  >>-Shiv
>  >>===
>  >>Shivkumar Kalyanaraman
>  >>Associate Professor, Dept of ECSE, Rensselaer Polytechnic Institute (RPI)
>  >>
>  >>On Tue, 2 Apr 2002, Antonio Jose Elizondo wrote:
>  >>
>  >>> Hi, I am also a lurker on this list, and also read it from time to (much) time.
>  >>>
>  >>> I presented a paper on "Capped Leaky Buckets" in ITC17 (2001). The goal of this
>  >>> bucket consists of providing a configured rate to each TCP flow.
>  >>>
>  >>> I've looked for the ITC17 proceedings in the web, but it seems that they are not
>  >>> published. However, you can find a previous work in the web, where capped leaky
>  >>> buckets are introduced:
>  >>>  http://www.eurescom.de/~pub-deliverables/p1000-series/p1006/TI_5/P1006TI5_merged.pdf
>  >>>
>  >>> If anybody wants the most recent paper, the ITC17 version, please let me know.
>  >>>
>  >>> Regards,
>  >>>            Antonio J. Elizondo
>  >>>
>  >>> JFellows at coppermountain.com wrote:
>  >>>
>  >>> > I'm a long time lurker on this list, but would like to now raise an issue
>  >>> > that I suspect is old hat to many of the members of this list.
>  >>> >
>  >>> > I'm searching for the current best practice for implementing per flow or per
>  >>> > subscriber rate limits in edge routers.  This is becoming a common request
>  >>> > from consumer oriented ISPs in both the cable and DSL markets.  I've done
>  >>> > the Google search and read a half dozen papers that touch on this subject.
>  >>> > Many of the published papers refer to the classic 'sawtooth' behaviour of
>  >>> > TCP in this configuration.   Some suggest that, in order to avoid multiple
>  >>> > consecutive discards, the token bucket that implements the rate limiter
>  >>> > should have a depth at least equal to the RTT*configured rate.
>  >>> >
>  >>> > Are there any non-invasive (not involving on-the-fly modification of TCP
>  >>> > headers) implementations of rate limiters that allow TCP to run fairly
>  >>> > smoothly at the configured rate?
>  >>> >
>  >>> > Jonathan
>  >>>
>  >>
>
>  cheers
>
>    jon
>