On Tue, Oct 15, 2013 at 11:19:34AM +0100, Colin Perkins wrote:
> 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.
Define RTP header extension with well-defined intra-flow priority field.
Lets call it "Network-Signaling" RTP header extension. Might have other
fields in it too beside priority (heck: even DSCP for poor apps that can't
set it via their network stack ;-).
Introduce new attribute to the STUN signaled metadata:
draft-martinsen-mmusic-malice-00.txt. This attribute is signalled
if the RTP packets on the 5-tuple have the network signaling RTP header
extension, and its value is the ID of that RTP header extension.
> 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.
[Deleted rant about why we could not even design IPv6 so that useful new
onpath header extensions could be placed in there ]
I would hope the above proposed design answers those concerns of yours.
-> Once the sender of the 5-tuple flow clear indicates to the network
via STUN that the network-signaling header is present and what it's ID
is, the routre/switches should have all they need.
-> Obviously, the sender would not encrypt this paticular header as it
specifically intends to signal its content to the network.
-> Multiplexing should work fine because DPI in the network would use the
sme simple rules to identify RTP vs. non-RTP packets in the flow,
and then just find the RTP_header extension with the appropriate ID.
> 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.
Sure.
> 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.
I like shim layer, but in the end the design that will succeeed is the one
that apps most likely will adopt. How likely would RTCweb use shim-layer ?
Cheers
Toerless
