On 15. okt. 2013, at 02:58, Steven Blake wrote: > On Sat, 2013-10-12 at 08:11 +0200, Michael Welzl wrote: > >> Hi, >> >> 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. > > The Assured Forwarding (AF) PHB group (RFC2597) was defined precisely to > enable this drop-precedence-without-reordering-packets-within-a-flow > behavior. In Diffserv jargon (RFC3260), an instance of an AF behavior > aggregate (BA), e.g., AF11/AF12/AF13, would be an ordered aggregate > (OA). Packets in a flow DSCP-encoded with either AF11/AF12/AF13 (for > example) are guaranteed to be transmitted in the order received, but > will have different drop precedences (AF11 highest; AF13 lowest). This > is usually achieved by serving all packets on a port with the AF1* DSCP > via the same FIFO queue.
No, this is not what I mean. From RFC2597: In a DS node, the level of forwarding assurance of an IP packet thus depends on (1) how much forwarding resources has been allocated to the AF class that the packet belongs to, (2) what is the current load of the AF class, and, in case of congestion within the class, (3) what is the drop precedence of the packet. So while AF PHB groups are indeed meant to address such per-flow drop precedence, we still have a per-aggregate function, meaning that it's risky business for an application to decide that some of its packets have a higher drop precedence (it might put the application at a disadvantage in comparison with other *users*). If you just look at page 4 of http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-02 (Flow A vs. Flow B) you'll see an example that explains exactly the problem I'm talking about. Indeed I think that this draft suggests a nice solution, but as long as an application doesn't know that the mechanism in this draft is in place everywhere, the incentive for an application to assign a higher drop precedence to some packets still isn't there. For how I think this could be solved, see my previous email to Toerless. Cheers, Michael
