Re: Modems: Cable or DSL digital blunders that lartc may help with.

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



--- Greg Stark <gsstark@xxxxxxx> wrote:
> 
> Ed Wildgoose <lists@xxxxxxxxxxxxxx> writes:
> 
> > You need something which works at IP level or above.  TCP (level
> higher) has
> > some stuff, but (I repeat) it basically involves dropping traffic
> until the
> > sender slows down.  There are protocols like ECN, but they are broadly
> > unsupported.  ICMP stuff is frequently dropped by routers/firewalls
> making it
> > problematic (look at how difficult it is just to do MTU discovery!)
> 
> ECN is largely there so that *non*-TCP protocols can implement
> congestion
> control like TCP does.
> 
> The problem that was observed in DRUMS was that UDP based protocols like
> the
> various streaming audio/video protocols that have cropped up in recent
> years
> would push any TCP streams out of their way. Routers would drop UDP
> packets
> but most of them didn't throttle their bandwidth on dropped packets. And
> congestion control using dropped packets required every protocol to
> implement
> its own acknowledgement and windowing infrastructure. The goal was to
> have
> something simple that could be supported at a lower level.
> 
The problem is data in general, both UDP and TCP.  Thought most ppl only
have one computer connected to there modem, so high level protocols like
ECN are overkill.  I therefor recomend that any vendor that creates modems
make sure they incoperate flow controle on ALL there inbound traffic.

> ECN on TCP connections is a bit superfluous. It could be used to
> throttle the
> bandwidth being used before it led to dropped packets, but it's unclear
> that
> would help any. Traditional TCP congestion control is fairly effective
> at
> grabbing all the available bandwidth anyways. ECN would be accomplishing
> largely the same thing that RED accomplishes at much greater expense on
> the
> router.
> 
> Incidentally, ICMP Source Quench turned out to be a bad idea. Modern
> RFCs say
> hosts "SHOULD NOT" send them. The problem is that responding to
> congestion by
> sending more packets exacerbates the congestion.
> 
What about ICMP TTL Expier?  Also ECN's data WILL have the same effect?
thought I know it's validated that both sides of the connection support
ECN.  When EVERY one is using it there will be the same type of traffic
flow for the congestion state.

> 
> -- 
> greg
> 
> 



		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 
_______________________________________________
LARTC mailing list / LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux