From: Varun Varma <varun@mindsw.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] TCP Rate Control
Date: Thu, 15 May 2003 17:53:46 +0000 [thread overview]
Message-ID: <marc-lartc-105302063001772@msgid-missing> (raw)
In-Reply-To: <marc-lartc-105291155220508@msgid-missing>
Stef Coene wrote:
>
> You mean something like the gred or red qdisc.
The difference is RED drops the packets after they arrive basing it on
the understanding that the TCP implementations would take this as a hint
and slow down the transmission rates.
Rate control on the other hand takes a more "hands on" approach to the
problem. As Jose mentioned, ack pacing, window sizing etc...it actually
exploits fundamentals in TCP flow control itself.
> But I wonder if it will be a big different between "TCP rate contorl" and
> plain old shaping.
There are lot of comparisions on this. I don't want to get into a debate
here, since people from each group [rate control vs. queueing] feel
very stongly about their stand.
Simply put, there are dozens of queueing disciplines, because some might
"behave better" than other in some cases. I *feel* that rate control
would work better in some particular cases, so I was interested in
knowing if a rate control like implementation is available under Linux.
>
>>Seems to be a patented "idea" in the USA, but I remember someone on this
>>list talked not long ago about he waaas implementing something like this
>>for Linux, from outside the USA. Check the archives for the message:
>>Subject: Re: [LARTC] How far can TC go?
>>From: Patrick McHardy <kaber@trash.net>
>>Date: Sat, 29 Mar 2003 11:08:30 +0100
Thanks for the reference...still need to check it out.
About the patent thing...I know for sure that ack pacing has been
published in paper before. Note: I am not suggesting how to circumvent
this patent in any way. That said, I think it should be possible to work
out other mechanisms, based around TCP flow control, which don't work
the way Packeteer's patent works.
If you google for "linux rate control", you come up with a link like:
http://www.postel.org/pipermail/end2end-interest/2001-April/000701.html
Which is a master's thesis, proposing another way to implement rate control.
Regards,
-Varun
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
next prev parent reply other threads:[~2003-05-15 17:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-14 11:36 [LARTC] TCP Rate Control Varun Varma
2003-05-14 18:00 ` Stef Coene
2003-05-14 19:59 ` Brandis Jaroslav
2003-05-14 20:09 ` Stef Coene
2003-05-14 23:06 ` Jose Luis Domingo Lopez
2003-05-15 17:06 ` Stef Coene
2003-05-15 17:53 ` Stef Coene
2003-05-15 17:53 ` Varun Varma [this message]
2003-05-15 18:34 ` Varun Varma
2003-05-15 19:15 ` Stef Coene
2003-05-15 19:45 ` Stef Coene
2003-05-15 21:11 ` Varun Varma
2003-05-16 9:20 ` Stef Coene
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-105302063001772@msgid-missing \
--to=varun@mindsw.com \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.