[whatwg] PeerConnection feedback

[Ian Hickson]

On Sat, 9 Apr 2011, James Salsman wrote:
>
> Sorry for the top posting, but I would like to reiterate my considered 
> opinion that Speex be supported for recording.  It is the standard 
> format available from Adobe Flash recording, low bandwidth, open source 
> and unencumbered, efficient, and it is high quality for its bandwidth.

My plan with the codecs issue here is to let the implementors figure out 
which codecs they want to implement, and then once there's a common set 
across all the implementations, to require that. So I would recommend 
petitioning the implementors if you have particular codec desires. :-)


On Sun, 24 Apr 2011, Stefan Håkansson LK wrote:
> >>
> >> 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.
> >
> >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).

Doing this would require reimplementing reliable connectivity over UDP. 
Before we introduce that level of complexity, I really think we should 
make sure people are interested in using this API at all.


> 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.

I've added a line in the spec about allowing UAs to implement rate 
control in outgoing data.


On Fri, 29 Apr 2011, Magnus Westerlund wrote:
> 
> I think one do need to consider the need for a Path MTU discovery 
> mechanism. If one has framing and sequencing of data parts, then one can 
> consider to implement a application level PMTU discovery mechanism.

I'm happy to specify something along these lines if it can be made to work 
within the constraints of Web technologies (e.g. we can't rely on authors 
to handle rare but important situations). The best way to progress on this 
would be to make a concrete proposal, so that we can see what exactly you 
would like browsers to implement here.


There were also a number of additional e-mails sent over the past month or 
so on PeerConnection and its related APIs, but all these threads seemed to 
resolve themselves without needing any specification changes, so I have 
not explicitly replied to them. If you would like a specific reply to a 
particular comment, please let me know (either on the list of privately) 
and I'll be happy to take another look and reply.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'