[e2e] how to control the traffic rate below a defined value at the network node????

Chong Poh Kit thesoothsayer at pd.jaring.my
Wed Oct 9 18:38:06 PDT 2002


----- Original Message ----- >
> Message: 2
> Date: Tue, 8 Oct 2002 12:28:14 -0700
> From: Luigi Rizzo <rizzo at icir.org>
> Subject: Re: [e2e] how to control the traffic rate below a defined value
at the network node????
>
> On Tue, Oct 08, 2002 at 11:30:22AM -0700, Greg Minshall wrote:
> > i think Packeteer (sp?) used a method (probably patented by them?) in
which
> > they would pace the returning *ACK* stream (in the reverse direction),
which
> > would cause the rate of transmission in the forward direction to slow
down.
> > that seemed clever.
>
> I also thought that the packeteer-like approach was very clever,
> so once i sat down trying to implement it in dummynet.
>
> Then i realised (fortunately before writing any additional code)
> that since acks are generated in response to incoming data, you
> achieve exactly the same result by pacing incoming data (before the
> stack has a chance to see them, as dummynet does) or outgoing acks.
>
> This also saved patent-related hassles :)


I'm thinking about pacing the incoming data as well (hopefully you didn't
patent it yet ;) ) but if you pace incoming data you wouldn't be able to
change the TCP window advertisement size in the ACKs like what the Packeteer
router is doing, right? Also, wouldn't it be less space efficient to pace
incoming data as opposed to ACKs which are generally smaller?

I'm not sure if this is an issue, but if you pace the data packets and
there's no congestion at the routers, would there come a time when the
advertised window size becomes large enough that the amount of data sent
will cause the buffer at the router to overflow?

"Real programmers don't document. If it was hard to write, it should be hard
to understand." ;)

Regards,

Chong Poh Kit
Multimedia University, Malaysia




More information about the end2end-interest mailing list