All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Mestnik <cheako911@yahoo.com>
To: lartc@vger.kernel.org
Subject: [LARTC] Re: Modems: Cable or DSL digital blunders that lartc may help with.
Date: Fri, 25 Jun 2004 16:59:48 +0000	[thread overview]
Message-ID: <20040625165948.62281.qmail@web11902.mail.yahoo.com> (raw)
In-Reply-To: <87n02t6sg2.fsf@stark.xeocode.com>

--- 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/

      reply	other threads:[~2004-06-25 16:59 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-24 12:39 [LARTC] Re: Modems: Cable or DSL digital blunders that lartc may help with Greg Stark
2004-06-25 16:59 ` Mike Mestnik [this message]

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=20040625165948.62281.qmail@web11902.mail.yahoo.com \
    --to=cheako911@yahoo.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.