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

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

[Greg Stark]

Ed Wildgoose <lists@wildgooses.com> 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.

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.


-- 
greg

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

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

[Mike Mestnik]

--- Greg Stark <gsstark@mit.edu> wrote:
> 
> Ed Wildgoose <lists@wildgooses.com> 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@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/