On 04/24/11 11:34, Stefan Håkansson LK wrote:
On Fri, 22 Apr 2011, Ian Hickson wrote:
On Mon, 11 Apr 2011, Justin Uberti wrote:
On Mon, Apr 11, 2011 at 7:09 PM, Ian Hickson<[email protected]> wrote:
This has made UDP packets larger than the MTU pretty useless.
So I guess the question is do we want to limit the input to a fixed
value that is the lowest used MTU (576 bytes per IPv4), or
dynamically and regularly determine what the lowest possible MTU is?
The former has a major advantage: if an application works in one
environment, you know it'll work elsewhere, because the maximum
packet size won't change. This is a erious concern on the Web, where
authors tend to do limited testing and thus often fail to handle
rare edge cases well.
The latter has a major disadvantage: the path MTU might change,
meaning we might start dropping data if we don't keep trying to
determine the Path MTU. Also, it's really hard to determine the Path
MTU in practice.
For now I've gone with the IPv4 "minimum maximum" of 576 minus
overhead, leaving 504 bytes for user data per packet. It seems
small, but I don't know how much data people normally send along
these low-latency unreliable channels.
However, if people want to instead have the minimum be dynamically
determined, I'm open to that too. I think the best way to approach
that would be to have UAs implement it as an experimental extension
at first, and for us to get implementation experience on how well it
works. If anyone is interested in doing that I'm happy to work with
them to work out a way to do this that doesn't interfere with UAs
that don't yet implement that extension.
In practice, applications assume that the minimum MTU is 1280 (the
minimum IPv6 MTU), and limit payloads to about 1200 bytes so that with
framing they will fit into a 1280-byte MTU. Going down to 576 would
significantly increase the packetization overhead.
Interesting.
Is there any data out there about what works in practice? I've seen very conflicting information, ranging from
"anything above>what IPv4 allows is risky" to "Ethernet kills everything above 1500".
Wikipedia seems to think that while IPv4's lowest MTU is>576, practical path MTUs are only "generally"
higher, which doesn't seem like a good enough guarantee for Web-platform APIs.
I'm happy to change this, but I'd like solid data to base the decision on.
Wouldn't it be possible to abstract this away for the web developer? I.e. the
send method should, like for WebSockets, not have a max size. Instead the
sending UA would be responsible for chopping up (the receiving UA for
re-assembling) the message into packets not larger than the minimum path MTU.
Depending on the UA (and how integrated with the IP stack of the device it is)
different levels of implementation sophistication could be used (e.g. max 576
byte, or select 576/1280 depending on IP version, or even using MTU path
discovery to find out max size).
Yes, we could reimplement UDP's defragmentation mechanism at the higher
level.
There are a few things to keep in mind if you do that (for instance,
there's a well known
resource exhaustion attack where an attacker sends you the first part of
UDP packets and never sends you the rest of it, until you run out of
reassembly buffers, and of course the chance of losing a packet goes up
significantly when all the fragments need to make it in order to achieve
correct reassembly).
At the protocol level, this needs the same kind of mechanisms that UDP
has for correlation between the pieces of a datagram, of course.
Like for WebSockets, a readonly bufferedAmount attribute could be added.
Note: I take for granted that some kind of rate control must be added to the
PeerConnection's "data UDP media stream", so allowing large data chunks to be
sent would not increase the risk for network congestion.
Yes, rate control seems to be the main worry raised in the parallel
discussion over on the RTCWEB mailing list (where DTLS/DCCP/UDP is being
proposed as a possible stack).
Stefan (this isn't really my area of expertise, so maybe I've misunderstood -
then please disregard this input)
