On 15. okt. 2013, at 12:19, Colin Perkins wrote: > 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.
See, I don't know enough about RTP. Sorry... > 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. All of that makes sense to me. Cheers, Michael
