All of lore.kernel.org
 help / color / mirror / Atom feed
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/

  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.