[whatwg] MTU Size PeerConnection send method (was RE: PeerConnection feedback)

[Harald Alvestrand]

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<ian at hixie.ch>  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)