public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: rshaper-1.01, for linux-2.0
       [not found] <m0z56qq-000aNFC@the-village.bc.nu>
@ 1998-08-08 14:56 ` Andi Kleen
  0 siblings, 0 replies; only message in thread
From: Andi Kleen @ 1998-08-08 14:56 UTC (permalink / raw)
  To: Alan Cox; +Cc: Taral, rubini, linux-kernel

alan@lxorguk.ukuu.org.uk (Alan Cox) writes:

> > Actually, if you're clever with the window, you can limit incoming traffic.
> 
> Try playing with the window on a UDP session, on a header with IP-AH or
> IP-ESP present etc. There are fudged ways of emulating receive flow control
> for tcp - both fiddling with the packets to fake window sizes (dangerous)
> or dropping some acks (running a model on the receive side to see which frames
> didnt logically make it through) but nothing will keep the flow right on
> the receive side the moment someone uses something like NFS or realaudio
> over it

If Real Audio uses some congestion avoidance algorithm it should be 
possible to model the conditions that get the sender to slow down.
SunRPC/NFS uses congestion avoidance so it is possible. One possible
way would be too simply do the shaping for incoming traffic and wait
until congestion avoidance on the sender kicks in.

Some links for TCP rate control are at http://www.packeteer.com/tcprate/

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~1998-08-08 16:45 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <m0z56qq-000aNFC@the-village.bc.nu>
1998-08-08 14:56 ` rshaper-1.01, for linux-2.0 Andi Kleen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox