IP? with a clear "per-5-tuple-only" rule? Sent from my iPhone
On 13. okt. 2013, at 17:29, Kevin Gross <[email protected]> wrote: > There have been mechanisms proposed or implemented to some extent in > Ethernet, ATM and IP for indicating drop precedence (as opposed to class). > These mechanisms are designed to solve exactly this problem. I'm not sure why > this capability has, by and large, not been widely deployed. I think, for > one, we network propeller-heads tend to overestimate the importance of QoS or > at least the ability of application designers and IT personnel to get their > heads around it well enough to be able to configure it so that it actually > improves things. > > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com > > > On Sun, Oct 13, 2013 at 2:01 AM, Michael Welzl <[email protected]> wrote: > > On 12. okt. 2013, at 23:00, Bernard Aboba <[email protected]> wrote: > >> [BA] A few points: >> >> a. No B-frames in interactive uses, as others have said. >> b. With SVC, you can apply FEC or RTX only to the base layer. So if there >> is loss in the base, you can recover. Loss in enhancement layers may be >> "lived with" by dropping down to base frame rate/resolution/quality. So not >> essential to apply FEC, RTX (or QoS) to enhancement layers, especially since >> if there is high loss in enhancement layers a logical response is to stop >> sending them (duh). > > I see. Well, should we perhaps really suggest a > "lower-priority-than-other-packets-in-the-same-5-tuple" DSCP then? > > Cheers, > Michael > > > >> >> >> >> Michael said: >> >> > I'll begin by apologizing for asking what I'm quite sure is a terribly >> > stupid question to many of you. >> > >> > The question is: >> > >> > It has long been known that media data can have different levels of >> > importance. Simply put, if packet #1 from a single source contains parts >> > of a video's I-Frame and packet #2 contains only parts of B-Frames, and >> > both end up in the same queue, controlled by an AQM (for instance), it >> > would be better for the video stream if packet #2 would be dropped rather >> > than packet #1. >> > >> > There is nothing new with this story; it's not hard to find research >> > papers that document various variations of this theme, showing benefits in >> > video quality. >> > >> > My question is, why is none of this happening? >> > >> > Is it because DSCP values are typically associated with sources, and >> > hence, marking packet #2 as "less" important would put the source at the >> > risk of having its packets less important than not only its own other >> > packets, but anybody else's? But there is equipment that does >> > per-connection stuff, and such things could probably better be done near >> > the edges, where the bottleneck typically is... so if that's the whole >> > issue, we could define DSCP values that mean relative importance *within >> > the same five-tuple only*. Surely that has been thought about and probably >> > proposed by folks before, so what happened? Why isn't it done? >> > >> > Or is it because per-five-tuple-functionality in the network is regarded >> > as being too costly, and not encouraged, and hence not standardized? >> > >> > I'm just trying to understand the reasons for this particular >> > long-standing difference between research an reality. >> > >> > Cheers, >> > Michael >> > > >
