Subject: Re: [rmcat] About the importance of packets in a single data stream

From: Michael Welzl <[email-masked]>
Date: Mon, 14 Oct 2013 13:15:31 +0200

Hi,

That was a very interesting answer, thanks!  Comments in line:

On 14. okt. 2013, at 08:39, Toerless Eckert wrote:

> 
> High level answer: I think it has not been done so far because it is not that
> easy, and it requires both good thinking of how to do it from the video encoding
> expert and the network QoS experts. 
> 
> I think it would be great if video flows would give per-packet priority
> indications. I think most of the reasons brought up so far in this thread are no good
> reasons not to do it:

I agree!

> - Even without B frames, different packets can have different prioties. I/LTR
>  frames vs. P frames for example. Equally in SVC.
> - FEC is not free but costs quite a bit of overhead. And its not particularily
>  well protecting against burst loss happening during burst collisions when
>  new competing flows cause queue overrun.
> - Playout buffers in receiver apps can be quite large. STBs supposedly have
>  100 msec or more. So reordering of different priority packets should not
>  be an issue. Even with low-delay video, the reordering that could happen
>  in the network just means that some packets of the flow arrive earlier than
>  expected under the contention conditions. Besides, you can also have different
>  drop priorities without packet reordering within the same queue. In fact
>  AF4x for example is defined to have that property (no packet reordering).
> 
> IMHO, the issues why nothing has been done so far are rather:
> 
> - There may not be enough well understood value analysis, eg: How well could
>  network with differentiated drop policies effectively protect higher
>  priority packets over lower priority packets. Yes, this is widely known at
>  the class level, but not necessarily for packet distributions of different
>  packets in the same flow. We've done some simulations on this that we
>  could show that IMHO looked pretty good.

At least to some degree, this must be a function of the queue length, I think. The shorter your queue, the less likely it is that you see more than one packet from the same source... if important packet #1 from source X and unimportant packet #2 from source X are not in the same queue together, you probably can't reasonably protect #1 from the impact of #2.

> - Why drop if you could do ECN plus rate-adaptive downspeeding. The answer is 
>  IMHO a bit more complex.

I agree.

>  In summary, i think priority dropping is good to

>  deal with short term burst collisions and i think they can become quite likely
>  for RMCAT. For dealing with ongoing congestion you obviously want downspeeding,
>  and ongoing may be as short as maybe >= 2..10 seconds.  If you do have
>  priority based drop support in the network, i think that could fare better
>  than ECN because it does resolve the burst collision as good as possibe
>  in addition to a congestion notification. PCN of course would be best to have,
>  in which case the window of applicability for priority dropping shrinks to
>  less likely burst collisions.
> 
> - How do you maximize the value of priority dropping in the video codec.
>  Ideally you build your codec to have real discardable frames that are not
>  predictor for other frames. But that as PSNR impacts. So this gets into
>  the secret sauce of codecs.

There, I think the answer can easily be found in multimedia literature. There are many papers out there that evaluate such effects, e.g.:
Michael Schier, Michael Welzl: "Selective Packet Discard in Mobile Video Delivery based on Macroblock-Level Distortion Estimation", IEEE Infocom MoVID 2009 workshop, 24 April 2009, Rio De Janeiro, Brazil.
as only one example.

> - 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.

> - How do you motivate codecs to indicate packet priorities if they have to
>  fear that video flows with some packets marked "low priority" would
>  ultimately see more packets dropped than flows without any "low priority"
>  indications. For that we've got draft-lai-tsvwg-normalizer-02.txt

Well, but here we're talking about a marking that only means "relative priority, within the same connection". So there shouldn't be any risk in setting low priority, really.

Cheers,
Michael

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 14 Oct 2013 07:37:23 -0700

> At least to some degree, this must be a function of the queue length, I think. The shorter your queue, the less likely it is that you see more than one packet from the same source... if important p…

Indeed. IN other words you need some number of multiplexed flows to
effectively do intelligent dropping. I think this may be as low as
3..4 flows on a home-gateway, but the more, the better.

> Michael Schier, Michael Welzl: "Selective Packet Discard in Mobile Video Delivery based on Macroblock-Level Distortion Estimation", IEEE Infocom MoVID 2009 workshop, 24 April 2009, Rio De Janeiro,…

Thanks for the pointer.

> Well, but here we're talking about a marking that only means "relative priority, within the same connection". So there shouldn't be any risk in setting low priority, really.

But you need an intelligent dropping mechanism, and unless you would
do a per-flow subqueue, you could not do relative dropping relative within
the flow). And per-flow queuing is expensive. So our draft tries to explain a scheme
that replaces per-floq queuing with per-flow priority remarking to allow
dropping in a common queue.

Cheers
    toerless

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!

---

From: Michael Welzl <[email-masked]>
Date: Tue, 15 Oct 2013 10:06:32 +0200

> dropping in a common queue.

So now I finally read http://tools.ietf.org/html/draft-lai-tsvwg-normalizer and I must say I like it a lot! It is indeed exactly what we need - but one issue with it is compatibility. Actually this could become a show-stopper, as this is all about getting the incentives right:  why would my application ever set a higher drop precedence for some packets when I don't know if this normalizer is in place or not? And this decision would have to be taken by the application...

I could imagine a scenario where an application inserts the RTP extension header that you mentioned, and then a flow-aware edge device which knows that this traffic is going to traverse a path where your normalization marker is in place marks packets into an AFx PHB group based on the RTP extension header. Then we have an architecture that is incentive-compatible AND scales.

Cheers,
Michael

---

From: Colin Perkins <[email-masked]>
Date: Tue, 15 Oct 2013 11:19:34 +0100

> 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 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/

---

From: Michael Welzl <[email-masked]>
Date: Tue, 15 Oct 2013 12:48:52 +0200

> 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…

See, I don't know enough about RTP. Sorry...

> 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…

All of that makes sense to me.

Cheers,
Michael

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 15 Oct 2013 09:34:05 -0700

> So now I finally read http://tools.ietf.org/html/draft-lai-tsvwg-normalizer and I must say I like it a lot! It is indeed exactly what we need - but one issue with it is compatibility. Actually this…

if we wouldn't try to stadardize this behavior with DSCP marking but only with
RTP markings then that definition could also include the clear requirement
that network devices MUST NOT interpret these markings in a way that
would penalize a flow against other flows with no or differnt markings. Aka:
clear state that these are intra-flow priority markings and must be interpreted
by the network as such.

> I could imagine a scenario where an application inserts the RTP extension header that you mentioned, and then a flow-aware edge device which knows that this traffic is going to traverse a path wher…

Right.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 15 Oct 2013 10:33:41 -0700

> 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 inferre…

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.

> 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 t…

[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