Subject: Re: [AVTCORE] Fwd: New Version Notification for draft-westerlund-avtcore-transport-multiplexing-04.txt

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sat, 3 Nov 2012 17:41:53 +0000

I think this is a useful document; However, I do have a few comments and concerns regarding its focus and relationship with other drafts.

1) Section 3, Motivations. It currently reads as follows:

   This section looks at the motivations why an additional solution is
   needed assuming that you can do both the classical method of having
   one RTP session per transport flow as defined by the RTP
   specification [RFC3550] and when you have multiple media types within
   one RTP session [I-D.ietf-avtcore-multi-media-rtp-session].

How about the following instead:

   This section looks at the motivations for standardizing two mechanisms 
   for multiplexing multiple media types within a single transport flow:
  1) having one RTP session per transport flow, as defined by the RTP
   specification [RFC3550], and multiplexing multiple RTP session per transport
   flow, as defined in this document ( or elsewhere if preferred to split it out).
  2) having  multiple media types within one RTP session, as defined in
  [I-D.ietf-avtcore-multi-media-rtp-session].

2) Sections 3.1 and 3.2 are motivations for (2) and are duplicated in  [I-D.ietf-avtcore-multi-media-rtp-session] , whereas sections 3.3 and 3.4 are motivations for (1). Perhaps it is best to remove sections 3.1 and 3.2 and let this draft focus on the reasons why (1) is needed, as that is real focus of this draft.

3) Section 3.5 is more a statement of the requirement for a way to negotiate (1) vs (2), rather than a motivation for either.

4) Section 6.2, Signaling, contains the following:

   The 'session-mux-id' attribute is included for a media description,
   in order to indicate the Session ID for that particular media
   description.  Every media description that shares a common attribute
   value is assumed to be part of a single RTP session.  

Is that true? I think you meant to say these may exist in one or more RTP sessions, with the RTP sessions being multiplexed on a single transport flow.
And the later it reads as follows:

   An SDP Offerer
   MUST include the 'session-mux-id' attribute for every media
   description associated with a 'SHIM' group.  If the SDP Answer does
   not contain the SHIM group, the SDP Offerer MUST NOT use SHIM based
   layering.  However, if that is separate RTP sessions or BUNDLE is
   determined on what was present in the offer and answer.  This will
   depend on what the offering party likes to happen. 

You lost me here. Hopefully some  rewording would help.

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Magnus Westerlund
> Sent: Monday, October 22, 2012 11:31 AM
> To: IETF AVTCore WG
> Subject: [AVTCORE] Fwd: New Version Notification for draft-westerlund-
> avtcore-transport-multiplexing-04.txt
> 
> WG,
> (As individual)
> 
> We have now submitted an update to the multiplexing of multiple RTP
> sessions over a single transport (SHIM). The changes in this version are:
> 
> - Making the SHIM 2 bytes, pre-fixed and it include a fixed pattern for
> STUN and DTLS separation.
> - Propose that we do some key-derivation for different RTP sessions so
> that a single key-management sequence can key all the session when doing
> DTLS-SRTP.
> 
> The signaling solution in this draft has not been improved yet, we are
> awaiting resolution of the BUNDLE discussion in MMUSIC to better
> understand what path is selected and how to interact with that solution
> and take the raised concerns into account.
> 
> We have now discussed this proposal for some time and it appears clear
> that it targets a useful combination of trade-offs. We authors would
> like to request WG adoption of this proposal.
> 
> Cheers
> 
> Magnus

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 14 Nov 2012 16:27:05 +0100

Hi,

Thanks for the comments.

On 2012-11-03 18:41, Charles Eckel (eckelcu) wrote:
> I think this is a useful document; However, I do have a few comments
> and concerns regarding its focus and relationship with other drafts.
> 

Yes, that is clearer.

> 2) Sections 3.1 and 3.2 are motivations for (2) and are duplicated
> in
[I-D.ietf-avtcore-multi-media-rtp-session] , whereas sections 3.3 and
3.4 are motivations for (1). Perhaps it is best to remove sections 3.1
and 3.2 and let this draft focus on the reasons why (1) is needed, as
that is real focus of this draft.

I will need to think about this. It might be that some restructuring are
needed in general to consider both when a single transport is motivated
and what the motivation is for having multiple RTP sessions over one
transport flow. Thus maybe further tweaking of the introduction section
and the structure.

> 3) Section 3.5 is more a statement of the requirement for a way to
negotiate (1) vs (2), rather than a motivation for either.

Then I don't think the message comes across that this session tries to
describe. To deploy a mix of legacy multiple RTP sessions clients and
single RTP session with multiple media types clients are not possible in
a joint multi-party conference unless one have a full RTP level
translation capable middlebox.

> 
> 4) Section 6.2, Signaling, contains the following:>
> Is that true? I think you meant to say these may exist in one or
> more RTP sessions, with the RTP sessions being multiplexed on a single
> transport flow.
>

I wonder if what you are getting confused over is the statement that
multiple m= lines where each m= lines contains the same SID would form a
joint RTP session. That was a notion that is included, but based on the
BUNDLE discussions I think should be avoided as the majority of the
difficult issues with BUNDLE is due to having multiple m= lines be part
of describing one RTP session.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 15 Nov 2012 22:19:41 +0000

Hi Magnus,

Please see inline.

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Wednesday, November 14, 2012 7:27 AM
> To: Charles Eckel (eckelcu)
> Cc: IETF AVTCore WG
> Subject: Re: [AVTCORE] Fwd: New Version Notification for draft-
> westerlund-avtcore-transport-multiplexing-04.txt
> 
> Hi,
> 
> Thanks for the comments.
> 

I see now. I was not coming to that understanding with the existing wording in the draft. Incorporating the text you provided above would help. 
 
> of describing one RTP session.

Actually, I think it is okay and useful to describe the way 'session-mux-id' works in the presence of both BUNDLE and SHIM, as an offer may well include both methods. Alternatively, you could make the two mutually exclusive. That removes some complexity, but I think it is a complexity we need to address if both approaches continue to progress. 
My remaining comment is that the following sentence does not parse:

   However, if that is separate RTP sessions or BUNDLE is
   determined on what was present in the offer and answer.

Reworking that would be helpful, as this contributed to my initial confusion.

Cheers,
Charles