On 14 Oct 2013, at 12:15, Michael Welzl <[email protected]> wrote: > On 14. okt. 2013, at 08:39, Toerless Eckert wrote: ... >> - How do you signal packet priority. DSCP is really ugly (TM). Besides, its >> really ugly to set from application (TM). An RTP header extension field >> would be IMHO much nicer. > > I agree that DSCP is ugly; I was thinking that one would have to even reserve > bits in DSCP because, despite different priorities *within* a connection, one > might still apply e.g. DiffServ to differentiate between 5-tuples. Indeed, > given that this is functionality that's only meant for devices that identify > 5-tuples, something above IP would make sense. So I think I agree that an RTP > header extension would be a good choice.
I strongly disagree. An RTP extension header is easy to add from the application, but difficult to distinguish in the forwarding plane. The semantics of the RTP header extension can only be inferred by looking at the signalling channel (e.g., SIP, XMPP, WebRTC, etc.). I don't think we want to tie the media path to the signalling path, nor should we require routers to interact with the signalling protocol. I also don't believe deep-packet inspection can usefully be used to find the RTP header extension. Ignoring the layering violation, recall that identifying RTP packets is difficult without keeping per-flow state, that the header extension is at a variable offset into the RTP packet, that multiple header extensions can be included in each RTP packet in an arbitrary order, and that header extensions have a dynamically chosen identifier mapped via the signalling channel with very little fixed text to identify them. Plus, the RTP header extension may well be encrypted if SRTP is used. Note also that RTCP, DTLS, or STUN packets are commonly multiplexed onto the same 5-tuple, and don't have a corresponding header extension but can use the DSCP field. I would assume we would want to be able to assign a priority to those packets relative to the media. If something in the UDP payload were considered appropriate to assign per-packet priority, then I'd suggest that a shim-layer to identify flows and priorities would be a better approach. That could add a couple of bytes shim to each packet, to identify both flow priority and flow type. This would also simplify some of the magic around demultiplexing RTP, RTCP, STUN, DTLS, etc., that all get multiplexed onto the same port in many applications. We proposed a shim to address the de-multiplexing part of this in draft-westerlund-avtcore-transport-multiplexing-06, and although it doesn't address the per-packet priority, it would be straight forward to add if it were desirable, and (unlike an RTP header extension) could place the priority field at a fixed location in the packet, with a well-known header to help identify the flows. -- Colin Perkins http://csperkins.org/
