On Mon, 11 Apr 2011, Justin Uberti wrote:
On Mon, Apr 11, 2011 at 7:09 PM, Ian Hickson i...@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.
On Wed, 13 Apr 2011, Harald Alvestrand wrote:
The practical MTU of the current Internet is the Ethernet MTU: 1500
bytes minus headers. The IPv6 minimum maximum of 1280 bytes was chosen
to leave some room for headers, tunnels and so on.
That was my guess, yeah. Certainly once IPv6 is more widely deployed I
think it would obviously make sense to increase the limit.
My suggestion would be to note that applications need to be aware that
due to firewalls and other types of black holes, you might get
consistent packet loss for packets larger than a given size, typically
1280 bytes or 1480 bytes, and leave it at that.
Unlike most other platforms, where authors (programmers) tend to be at
least somewhat experienced and where errors tend to be blamed on the
application, on the Web, many of the authors are amateurs, and
intermittent errors tend to be blamed on the browser. As such, we have to
design our APIs to be as reliable as possible.
On Mon, 11 Apr 2011, Justin Uberti wrote:
On Tue, 29 Mar 2011, Harald Alvestrand wrote:
multiplexing of multiple data streams on the same channel using
SSRC,
I don't follow. What benefit would that have?
If you are in a conference that has 10 participants, you don't want to
have to set up a new transport for each participant. Instead, SSRC
provides an excellent way to multiplex multiple media streams over a
single RTP session (and network transport).
Could you elaborate on this? I have tried finding information on how SSRC
works but cannot find anything useful. Can you point to the relevant parts
of the RFCs that describe this mechanism maybe? I'm having trouble
understanding how it works even for audio/video streams, let alone whether
it would actually be appropriate for data.
On Fri, 8 Apr 2011, Glenn Maynard wrote:
FWIW, I thought the block-of-text configuration string was peculiar
and unlike anything else in the platform. I agree that using a
configuration object (of some kind) makes more sense.
An object wouldn't work very well as it would add additional steps in
the case where someone just wants to transmit the configuration
information to the client as data. Using JSON strings as input as
Harald suggested could work, but seems overly verbose for such a
simple data.
I have a feeling that this configuration information will only start off
simple.
The configuration information mechanism is extensible. But generally
speaking, we should not solve problems we don't yet have.
On Wed, 13 Apr 2011, Harald Alvestrand wrote:
Since Ian seems to prefer to jumble all threads on a
