[whatwg] MTU Size PeerConnection send method (was RE: PeerConnection feedback)
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 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. 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)
[whatwg] Current status of hyperlink authoring (a.k.a. the ping attribute) and some suggestions
Hey there, I've researched hyperlink authoring (http://bit.ly/pingspec), which IMO is a great feature, and it looks like the only browser which implements it today is Chrome - Check out http://bit.ly/chromeping and try for yourself: http://bit.ly/pingfiddle . Not sure why implementation and buzz around this are so minor and why it seems stuck 6 years after proposal, but I have some suggestions to make which will hopefully help make some progress. - This feature *must* come with a standard means of feature-detection. The reason link gateways became popular is that they're bulletproof - no one can bypass the ping. If authors can't be sure ping will work, they won't use it. However, regular feature-detection or UA sniffing won't suffice because the user can disable the feature*. So ideally, we could have a boolean property like Navigator.features.ping, so we could do if(!Navigator.features.ping) runPingShim(). On a side note, having a Navigator.features object for similar user-pref-controlled features might be useful in more cases. - I believe the following paragraph should be either removed or changed to use *may*: When the ping attribute is present, user agents should clearly indicate to the user that following the hyperlink will also cause secondary requests to be sent in the background, possibly including listing the actual target URLs. No one will use a ping-system which freaks out users and tells them they're being tracked. What do you think? Ronny * Anyway, I can't think of a decent way to feature-detect this. Having the attribute on the node doesn't reveal support. So what, we should actually ping a test domain and set a cookie from it? Too slow and painful for that server. Any idea is appreciated. -- Ronny Orbach Front End Developer Conduit
Re: [whatwg] Dynamic pseudo-classes on video/audio element to allow styling of controls
A markup and CSS example would make things clearer. How do you think it would look? Silvia. On Sun, Apr 24, 2011 at 9:40 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Sat, Apr 23, 2011 at 1:57 PM, Philip Jägenstedt phil...@opera.com wrote: On Sat, 23 Apr 2011 21:32:06 +0200, Dimitri Glazkov dglaz...@chromium.org wrote: On Sat, Apr 23, 2011 at 11:37 AM, Philip Jägenstedt phil...@opera.com wrote: On Sat, 23 Apr 2011 17:02:56 +0200, Dimitri Glazkov dglaz...@chromium.org wrote: On Sat, Apr 23, 2011 at 2:57 AM, Philip Jägenstedt phil...@opera.com wrote: On Sat, 23 Apr 2011 05:25:20 +0200, Dimitri Glazkov dglaz...@chromium.org wrote: I wonder if it makes sense to introduce a set of pseudo-classes on the video/audio elements, each reflecting a state of the media on the controls (playing/paused/error/etc.)? Then, we could use just CSS to style media controls (whether native or custom), and not have to listen to DOM events just to tweak their appearance. With a sufficiently large set of pseudo-classes it might be possible to do *display* most of the interesting state, but how would you *change* the state without using scripts? Play/pause, seek, volume, etc... This is not the goal of using pseudo-classes: they just provide you with a uniform way to react to changes. In other words, one would still have to rely heavily on scripts to actually implement custom controls? Heavily is subjective. But yep :) Also, how would one style a progress bar using pseudo-classes? How about a displaying elapsed/remaining time on the form MM:SS? I am not in any way trying to invent a magical way to style media controls entirely in CSS. Just trying to make the job of controls developers easier and use CSS where it's well... useful? :) Very well, what specific set pseudo-classes do you think would be useful? I can infer what would be useful from WebKit's media controls as a first stab? :DG -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Dynamic pseudo-classes on video/audio element to allow styling of controls
Based on WebKit's current media controls, let's start with these pseudo-classes:
Play state:
- loading
- playing
- streaming
- error
Capabilities:
- no-audio
- no-video
- has-closed-captioning
So, to show a status message while the control is loading or streaming
and hide when it's done:
video -webkit-media-controls-status-display {
display: none;
}
video:loading -webkit-media-controls-status-display, video:streaming
-webkit-media-controls-status-display {
display: initial;
...
}
Similarly, to hide volume controls when there's no audio:
video:no-audio -webkit-media-controls-volume-slider-container {
display: none;
}
Once I put these pseudo-classes in place for WebKit, a lot of the code
in
http://codesearch.google.com/codesearch/p#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/html/shadow/MediaControlRootElement.cppexact_package=chromium
will go away, being replaced with straight CSS.
:DG
On Sun, Apr 24, 2011 at 8:31 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
A markup and CSS example would make things clearer. How do you think
it would look?
Silvia.
On Sun, Apr 24, 2011 at 9:40 AM, Dimitri Glazkov dglaz...@chromium.org
wrote:
On Sat, Apr 23, 2011 at 1:57 PM, Philip Jägenstedt phil...@opera.com wrote:
On Sat, 23 Apr 2011 21:32:06 +0200, Dimitri Glazkov dglaz...@chromium.org
wrote:
On Sat, Apr 23, 2011 at 11:37 AM, Philip Jägenstedt phil...@opera.com
wrote:
On Sat, 23 Apr 2011 17:02:56 +0200, Dimitri Glazkov
dglaz...@chromium.org
wrote:
On Sat, Apr 23, 2011 at 2:57 AM, Philip Jägenstedt phil...@opera.com
wrote:
On Sat, 23 Apr 2011 05:25:20 +0200, Dimitri Glazkov
dglaz...@chromium.org
wrote:
I wonder if it makes sense to introduce a set of pseudo-classes on the
video/audio elements, each reflecting a state of the media on the
controls (playing/paused/error/etc.)? Then, we could use just CSS to
style media controls (whether native or custom), and not have to
listen to DOM events just to tweak their appearance.
With a sufficiently large set of pseudo-classes it might be possible to
do
*display* most of the interesting state, but how would you *change* the
state without using scripts? Play/pause, seek, volume, etc...
This is not the goal of using pseudo-classes: they just provide you
with a uniform way to react to changes.
In other words, one would still have to rely heavily on scripts to
actually
implement custom controls?
Heavily is subjective. But yep :)
Also, how would one style a progress bar using pseudo-classes? How about
a
displaying elapsed/remaining time on the form MM:SS?
I am not in any way trying to invent a magical way to style media
controls entirely in CSS. Just trying to make the job of controls
developers easier and use CSS where it's well... useful? :)
Very well, what specific set pseudo-classes do you think would be useful?
I can infer what would be useful from WebKit's media controls as a first
stab?
:DG
--
Philip Jägenstedt
Core Developer
Opera Software
