Subject: Re: [payload] RFC 6190 Single Session Transport (multiple-SSRCs vs. single SSRC)

From: Bernard Aboba <[email-masked]>
Date: Thu, 22 Aug 2013 14:37:33 -0700

Roni said: 
 
Maybe if you want to use FEC only on the base layer and not on all layers.
 
[BA] Yes, that is one advantage (though by no means the biggest one). 
 
Mo said: 

"Selective forwarding of layers at a switch is simpler with MST versus SST, since SST requires rewriting timestamps and sequence numbers to drop layers. RTCP reporting per
 layer is another benefit of MST. These advantages stem from using multiple SSRCs independent of whether they use the same or separate transport flows." [BA]  Yes, this is perhaps the biggest advantage, particularly when encryption is used, although completely avoiding decryption typically either requires SDP extensions (to expose SSRC dependency groups) and/or RTP extensions (to expose information that would normally only be obtained by decrypting the PACSI NAL unit).  
 
"I think the entire nomenclature of SST/MST should evolve to Single/Multiple SSRC (not Session) Transport, since that is really what matters." [BA]  For much of RFC 6190 it is the distinction between multiple and single SSRC transmission that matters,  and the term "MST" can be interpreted as "multi-SSRC transmission", whether or not it occurs within a single RTP session.   However, this isn't true everywhere in the document.  For example, Section 1.2.2 says:  "MST should be used in a multicast session when different receivers
   may request different layers of the scalable bitstream." In this case MST really does mean "multi-session transport".    So the single/multi-session distinction will probably need to remain in a few places.  "So  updating the nomenclature would align with both current deployments and future standards like BUNDLE/UP." [BA] While it probably wouldn't help clarify things to do a global replace of "multi-session" with "multi-SSRC" I do agree that it's important for to be more thoughtful about this going forward.  In particular, while it might be too late to fix the interop issues causes by RFC 6190, we probably do have the ability to make sure that the same problems don't crop up in future PAYLOAD documents.   "Note that MST is already widely deployed this way, which is non-standard." [BA]  I agree that multi-SSRC single-session transmission is widely deployed.  However, I couldn't find anywhere in RFC 6190 where it is stated that MST implementations MUST use multiple sessions (or even anything about what uses of SSRCs are encouraged/discouraged), and in fact, the design accommodates multi-SSRC single-session transmission quite well.  So I don't agree that multi-SSRC single-session transmission is "non-standard".  

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Jonathan Lennox

Sent: 19 July, 2013 5:54 PM

To: Bernard Aboba

Cc: [email-masked]

Subject: Re: [MMUSIC] RFC 6190 Single Session Transport

On Jul 18, 2013, at 10:02 PM, Bernard Aboba <[email-masked]> wrote:

Jonathan said: 

"I don't understand how single-session multi-source transmission will work without either a) signaling "a=ssrc-group DDP" decoding dependencies, or b) making various implementation-specific
 assumptions about the structure of the SVC streams."

[BA] In terms of SDP choices for expressing layering within a single m line, you can either go the a=ssrc-group:DDP route, or use distinct payload types for each layer and RFC 5583 a=group:DDP (this is what "Unified Plan" Section 4.7 appears to advocate).  

I'm not sure how "MST within a single session" could be expressed in SDP without BUNDLE.  Was the idea to use multiple m lines and group them together but use the same port? 

I think the authors of RFC 6190 didn't see a use case for MST within a single RTP session -- all of the interesting MST use cases they saw involved separate transport flows for the separate layers, and if you're sending all the layers on
 a single transport flow, SST is significantly simpler.

What requirement are you trying to achieve that's met by MST in a single session, but not by SST?

--

Jonathan Lennox

[email-masked]