Subject: [rtcweb] H.264 SVC and BUNDLE

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Aug 2012 20:50:05 +0200

Hi,

At the telco yesterday one of the Microsoft guys claimed that H.264 SVC does not work with BUNDLE, but he didn't have the details.

Could someone please explain the reason why he/she doesn't think H.264 SVC work with BUNDLE?

(Note, that if using the same port for the different codec layers is a problem, then it's not a BUNDLE problem - it's a generic multiplexing problem.)

Thanks!

Regards,

Christer

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 29 Aug 2012 15:32:54 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Christer Holmberg
> Sent: Wednesday, August 29, 2012 11:50 AM
> To: [email-masked]; [email-masked]
> Subject: [rtcweb] H.264 SVC and BUNDLE
> 
> Hi,
> 
> At the telco yesterday one of the Microsoft guys claimed that H.264 SVC
> does not work with BUNDLE, but he didn't have the details.
> 
> (Note, that if using the same port for the different codec layers is a
> problem, then it's not a BUNDLE problem - it's a generic multiplexing
> problem.)

The general multiplexing of layers onto the same 5-tuple is a problem, 
*if* we want the layers to have different DSCP values.  This is because
we cannot successfully and reliably set different DSCP values for packets 
belonging to a 5-tuple over the Internet -- too many things rewrite 
the DSCP field (to a different value) or simply clear the DSCP field.  
This makes it impossible to restore the per-packet DSCP values later 
(e.g., using RSVP, or using any other better/stronger/faster signaling 
method).  If, however, each 5-tuple has its own DSCP value then that
DSCP value could be restored.

-d

> Thanks!
> 
> Regards,
> 
> Christer
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Aug 2012 09:50:35 +0200

Hi Dan,

Thanks for the information!

The issue you raise is of course not related to BUNDLE, but to multiplexing in general.

Regards,

Christer
________________________________________
From: Dan Wing [[email-masked]]
Sent: Thursday, August 30, 2012 1:32 AM
To: Christer Holmberg; [email-masked]; [email-masked]
Subject: RE: [rtcweb] H.264 SVC and BUNDLE

-d

---

From: "Roni Even" <[email-masked]>
Date: Thu, 30 Aug 2012 11:55:02 +0200

Christer,
This is about the multiple session support in MST, look at the example in
section 7.3.3 of RFC6190, using the DDP grouping attribute from RFC5583.
I assume that you can solve it using RFC5576 ssrc-group but you will need to
define the DDP to be used also for ssrc-group

Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christer Holmberg
Sent: 30 August, 2012 9:51 AM
To: Dan Wing; [email-masked]; [email-masked]
Subject: Re: [rtcweb] H.264 SVC and BUNDLE

Hi Dan,

The issue you raise is of course not related to BUNDLE, but to multiplexing
in general.

Regards,

Christer

> At the telco yesterday one of the Microsoft guys claimed that H.264 
> SVC does not work with BUNDLE, but he didn't have the details.
>

The general multiplexing of layers onto the same 5-tuple is a problem,
*if* we want the layers to have different DSCP values.  This is because we
cannot successfully and reliably set different DSCP values for packets
belonging to a 5-tuple over the Internet -- too many things rewrite the DSCP
field (to a different value) or simply clear the DSCP field.
This makes it impossible to restore the per-packet DSCP values later (e.g.,
using RSVP, or using any other better/stronger/faster signaling method).
If, however, each 5-tuple has its own DSCP value then that DSCP value could
be restored.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 30 Aug 2012 08:28:57 -0700

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Thursday, August 30, 2012 12:51 AM

Yes, of course.  That's why I answered in-line, after your question
about general multiplexing.

-d

> SVC
> > Could someone please explain the reason why he/she doesn't think
> H.264
> > SVC work with BUNDLE?
> >

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 30 Aug 2012 20:07:40 +0000

> DSCP value could be restored.

Dan,
You make a claim that is not necessarily true.  If packets within a 5-tuple have different DSCP values that are then erased by the network, why would it be "impossible" to restore those values later?  Within the context of multiplexing of RTP streams, each RTP stream within a 5-tuple would of necessity need to still use a single DSCP value.  If signaling can be used to inform a node of some means of identifying each RTP stream then the original DSCP markings could be restored.

While I agree that it would be easier to assign the same DSCP value to all packets in a 5-tuple, it would still be "possible" to filter on, for example, the SSRC value used for each stream (in addition to the 5-tuple) to reassign the original DSCP value (or a mapped value with appropriate meaning in the target network) for each stream.

Richard

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 30 Aug 2012 22:18:41 +0200

My assumption has always been that if you were operating on a network 
that could only apply diffserv to separate 5-tuples, you would allocate 
the SSRCs comprising a multilayer encoding to different 5-tuples.

If you were operating on a network that preserved DSCP values, or on one 
that did stateful resource reservation based on SSRC values, you would 
be able to use the same 5-tuple, if desirable.

This choice seems to be a choice that the application writer should take 
before deciding whether or not to use BUNDLE, so it's a little hard to 
see what the relationship to BUNDLE is.

One size does not fit all. Sometimes bundling is not what people want to do.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 30 Aug 2012 14:19:21 -0700

> the SSRCs comprising a multilayer encoding to different 5-tuples.

[BA] RFC 6190 Section 1 says:

   This memo defines two basic modes for transmission of SVC data,
   single-session transmission (SST) and multi-session transmission
   (MST).  In SST, a single RTP session is used for the transmission of
   all scalability layers comprising an SVC bitstream; in MST, the
   scalability layers are transported on different RTP sessions.  
[BA] So it is possible either to use multiple 5-tuples (MST) or a single 5-tuple (SST).  However, my understanding 
is that the SST approach is more popular than MST. 

> see what the relationship to BUNDLE is.

[BA] The open question has been how to indicate the desire for both layered coding and BUNDLE in SDP, 
given the backward compatibility issues we have talked about.  For example, if it is desired to do SST and
BUNDLE, do you signal MST and BUNDLE on different ports in the offer and then if SST and BUNDLE are
supported by the answer, have the answer respond with BUNDLE as well as dependency groups using 
the same port?  That would seem to imply an assumption that every MST implementation can also do SST.  
Or do do you signal SST and BUNDLE on the same port, and then if the response indicates that the SDP
was rejected, formulate an alternative offer (MST with BUNDLE?  H.264/AVC with BUNDLE? 
SST without BUNDLE??)  

> One size does not fit all. Sometimes bundling is not what people want to do.

[BA] Or sometimes it is, but implementations might not be clear how to negotiate it :)

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 30 Aug 2012 23:31:13 +0200

On 08/30/2012 11:19 PM, Bernard Aboba wrote:
> [BA] So it is possible either to use multiple 5-tuples (MST) or a 
> single 5-tuple (SST).  However, my understanding
I lack the background to think about this... in existing equipment, if 
you want to do SST, but would be willing to do MST if the other end did 
not support SST, how would your offer look (without BUNDLE)?

My head hurts a little when trying to guess, but from your question it 
sounds like you've done it, so it's better if you just paste an example.

(BTW, this is really an MMUSIC discussion)