From: David Collier-Brown <davec-b@rogers.com>
To: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] How is bufferbloat prevented/fixed for UDP?
Date: Mon, 12 May 2014 16:25:59 -0400 [thread overview]
Message-ID: <53712E57.10906@rogers.com> (raw)
In-Reply-To: <mailman.3.1399921203.1657.bloat@lists.bufferbloat.net>
Forums1000 <forums1000@gmail.com> asked
> Curiously, there is little information to be found regarding bufferbloat
> and UDP.
>
> I did find hints briefly alluding to some problems:
>
> 1)With UDP, you cannot uniquely identify a flow? This prevents an
> AQM-algorithm to drop packets for an (several) offending UDP flow(s).
>
> 2) Unlike TCP, UDP does not back down when encountering packet loss
>
> So how does UDP fit in concerning efforts to combat bufferbloat? Having one
> queue to mange all UDP 'flows' does not seem like a good approach.
>
> Thanks for shining a light on this:-)
>
> Jeroen
Bufferbloat, or more correctly the lack of congestion control in UDP,
is a problem for the designers of individual UDP-using programs. The
behaviour of the program during congestion is a problem for everyone
else (;-))
To oversimplify,
- If the UDP programs is small-data punt and hope, no-one needs care.
Very few such programs exist.
- if the UDP programs is a stop-and-wait one like TFTP, it will be a
self-limiting load on the net, and can be throttled by drops. This is
similar to...
-- if the program is self-limiting, such as VOIP or video, we really
should be prepared to signal congestion to it using AQM or drops, but I
don't know if anyone is doing such using UDP. Someone else on the list
will know.
- if the program uses resends, it will survive congestion control by
drops, and if the program is very heavily used, we may need to provide
congestion control for it, or we'll get "bloated". If everyone in the
world suddenly switched to UDP for web pages, we'd need to identify such
TCP-like streams and throttle them via packet drops, to avoid congestive
collapse.
- if the UDP program is large-data punt-and-hope, it would be both
randomly unreliable and harmful to the net. In that case, I think we
might need to hunt down the author and suggest something, quick before
he goes out of business for bringing down the net.
--dave
--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net | -- Mark Twain
next parent reply other threads:[~2014-05-12 20:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.3.1399921203.1657.bloat@lists.bufferbloat.net>
2014-05-12 20:25 ` David Collier-Brown [this message]
2014-05-13 4:33 Hal Murray
-- strict thread matches above, loose matches on Subject: below --
2014-05-12 7:11 Forums1000
2014-05-12 20:21 ` Toke Høiland-Jørgensen
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
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53712E57.10906@rogers.com \
--to=davec-b@rogers.com \
--cc=bloat@lists.bufferbloat.net \
--cc=davecb@spamcop.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox