W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2011

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

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Sun, 24 Apr 2011 11:34:18 +0200
Message-ID: <BBF498F2D030E84AB1179E24D1AC41D61478BD936D@ESESSCMS0362.eemea.ericsson.se>
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).

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.

Stefan (this isn't really my area of expertise, so maybe I've misunderstood - then please disregard this input)
Received on Sunday, 24 April 2011 02:34:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:03 GMT