Re: [Bloat] How is bufferbloat prevented/fixed for UDP?

Re: [Bloat] How is bufferbloat prevented/fixed for UDP?

[David Collier-Brown]

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

Re: [Bloat] How is bufferbloat prevented/fixed for UDP?

[Hal Murray]

> 1)With UDP, you cannot uniquely identify a flow? This prevents an
> AQM-algorithm to drop packets for an (several) offending UDP flow(s). 

UDP packets have port numbers, just like TCP.


> 2) Unlike TCP, UDP does not back down when encountering packet loss 

Mumble.  The OS doesn't do it.  It has to be done in user code.  But there is 
no reason that it can't be done there even if it isn't done correctly as 
often as we might like.

I think most DNS code is reasonably sane, mostly because the retransmit 
timeout is several seconds and also because it only retransmits a few times.

The poster child for how to do it wrong is the NTP client that was shipped in 
a zillion Netgear home routers with a hard wired NTP server.  Dave Plonka did 
a wonderful writeup.
  http://pages.cs.wisc.edu/~plonka/netgear-sntp/
I call it required reading (and understanding) for anybody interested in 
networks.


-- 
These are my opinions.  I hate spam.

[Bloat] How is bufferbloat prevented/fixed for UDP?

[Forums1000]

[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 752 bytes --]

Re: [Bloat] How is bufferbloat prevented/fixed for UDP?

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

Forums1000 <forums1000@gmail.com> writes:

> 1) With UDP, you cannot uniquely identify a flow? This prevents an
> AQM-algorithm to drop packets for an (several) offending UDP flow(s).

For most cases UDP flows are determined by port number pairs, same as
TCP. Multiple flows can be multiplexed over one "connection", but this
is no different from TCP.

> 2) Unlike TCP, UDP does not back down when encountering packet loss

This is true; i.e. not back-off mechanism is built into the protocol.
However, it is quite possible to build in such a mechanism in whatever
protocol is running *on top of* UDP. Indeed this is done for things like
real-time media protocol, and also bittorrents uTP protocol runs on top
of UDP.

So I guess the answer is "it all depends".

As an aside, if you *do* have an unresponsive UDP flow (whether
misconfigured or malignant), having a flow queueing mechanism like that
of fq_codel helps a lot; the bad UDP flow is then isolated and only
hurts itself, so to speak. :)

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]