[3367] in linux-net channel archive
Re: Traffic shaper
daemon@ATHENA.MIT.EDU (Mike Kilburn)
Thu Jun 20 16:44:53 1996
To: "Theodore Y. Ts'o" <tytso@mit.edu>
cc: Mike Kilburn <mike@lserv.conexio.co.za>, alan@lxorguk.ukuu.org.uk,
roque@di.fc.ul.pt, linux-net@vger.rutgers.edu
In-reply-to: Your message of "Thu, 20 Jun 1996 12:50:50 -0400."
<9606201650.AA08450@dcl.MIT.EDU>
Date: Thu, 20 Jun 1996 19:01:54 +0200
From: Mike Kilburn <mike@lserv.conexio.co.za>
>>
> P.S. You do see why you have to start dropping packets eventually,
> right? If your long delay buffer is of a fixed size, and you're filling
> it faster than you're taking data out of it, eventually it will fill.
>
Yes. The purpose of the buffer is like the 'elastic' buffers used to
overcome small differences in clock rates between sync devices who are
not slaved or clocked by the same master. It just seems like the right
thing to do because it more approximates a slow link than just dropping
packets. For most protocols I thought the sender would stop when the window
fills. I realize now TCP is not that simple but I want to see how it
works anyway. I am also one of those folks who has a hard time dropping
packets. Being in the modem business for a number of years does that
to you :).
sync devices
