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: Thu, 28 Apr 2011 20:55:01 +0200
Message-ID: <BBF498F2D030E84AB1179E24D1AC41D61478DFCA8A@ESESSCMS0362.eemea.ericsson.se>
>> 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).
The attacker in this case would be a (hacked) browser as the web developer can do no such thing. Of course larger data chunks increases the risk of not getting it over. This may be problematic: how can you explain this to the web developer in an understandable way?
Received on Thursday, 28 April 2011 11:55:01 GMT

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