Subject: [MMUSIC] FW: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Mon, 18 Feb 2013 22:08:40 +0000

Please note that I have also submitted a draft on how to fix BUNDLE.  This doc is based on the modified BUNDLE proposal with different port information for each m line and compares several different additional modifications to BUNDLE.  The doc ends up recommending the use of the unspecified address for subsequent m lines in a bundle group in the SDP answer (not offer).  Please see the doc for details.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 18, 2013 3:57 PM
To: Ejzak, Richard P (Richard)
Subject: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt

A new version of I-D, draft-ejzak-mmusic-bundle-alternatives-00.txt
has been successfully submitted by Richard Ejzak and posted to the IETF repository.

Filename:	 draft-ejzak-mmusic-bundle-alternatives
Revision:	 00
Title:		 Alternatives to BUNDLE
Creation date:	 2013-02-18
Group:		 Individual Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-bundle-alternatives-00.txt
Status:          http://datatracker.ietf.org/doc/draft-ejzak-mmusic-bundle-alternatives
Htmlized:        http://tools.ietf.org/html/draft-ejzak-mmusic-bundle-alternatives-00

Abstract:
   This paper discusses some potential modifications to the BUNDLE
   proposal for multiplexing of multiple media types within a single
   5-tuple to address limitations of the current proposal and
   alternatives already considered by MMUSIC.

The IETF Secretariat

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Feb 2013 12:27:54 +0000

Hi Richard,

It would have been good with some example messages/flows, but I'll give my comments based on my understanding of the text. Also, I'll focus on the "Unspecified address for subsequent m lines in SDP answer" alternative, as it is the one you recommend, but I believe my comments also apply to some of the other alternatives.

In general, you only focus on one single issue, but leave a number of questions unanswered.

First, as you will now have a single non-zero m- line, you still assume that entities (including intermediaries) will take information (media types, payload type mappings etc etc etc - even protocol, if we decide to also allow the data channel in the bundle) from all m- lines. Or, do you intend to put all that information into a single m- line? If so, in my opinion MMT is a much better approach.

Second, what if a user wants the disable, or reject, a specific stream, using port zero? How is it done in case the stream is already represented by a zero m- line? How is it done in case the stream is represented by the non-zero m- line which contains the port number value used for the whole bundle?

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 18, 2013 3:57 PM
To: Ejzak, Richard P (Richard)
Subject: New Version Notification for draft-ejzak-mmusic-bundle-alternatives-00.txt

Abstract:

The IETF Secretariat

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Wed, 20 Feb 2013 15:24:35 +0000

Hi Christer,

Thanks for your comments!  See below.

Richard

> From: Christer Holmberg [mailto:[email-masked]]
> 
> First, as you will now have a single non-zero m- line, you still assume
> that entities (including intermediaries) will take information (media
> types, payload type mappings etc etc etc - even protocol, if we decide
> to also allow the data channel in the bundle) from all m- lines. Or, do
> you intend to put all that information into a single m- line? If so, in
> my opinion MMT is a much better approach.

The intent is to reuse all of the existing information in the subsequent m lines except the connection, candidate and non-zero port information.  That excludes the crypto info as well.

> 
> Second, what if a user wants the disable, or reject, a specific stream,
> using port zero? How is it done in case the stream is already
> represented by a zero m- line? How is it done in case the stream is
> represented by the non-zero m- line which contains the port number
> value used for the whole bundle?

A zero port value would retain its original semantic of disabling/rejecting an individual m line.  In my proposal all subsequent m lines in the SDP answer that are accepted would have valid and unique non-zero port values that are different from the port value in the first m line of the bundle group. 

I admit that I did not think through how to disable the first m line in the group, but let me propose the following:

Let's specify that we get the connection and port information for the bundle from the first valid (non-zero port) m line in the bundle group of the SDP answer (not offer).  If the answerer wants to disable the first valid m line(s) of the bundle group in the first SDP offer, both ends use the connection and port information from the next valid m line in the SDP answer (and its corresponding m line in the SDP offer).  The offerer had valid information for each m line in the SDP offer so it doesn't matter which set we use after the first offer/answer transaction.  But we don't want to change the 5-tuple or crypto info for the bundle with any subsequent offer/answer.

If the offerer wants to disable the first valid m line(s) of a bundle group in a subsequent offer, it places the connection and port information for the bundle group in the next valid m line of the bundle group in the SDP offer (it would actually move this information from the previous first valid m line to the new one to avoid restarting crypto or changing ports).  In response to the new offer disabling the initial valid m line(s), the answerer similarly places the connection and port information for the bundle group in the corresponding m line of the SDP answer.  The answerer is not allowed to disable the first valid m line of a bundle group in the SDP answer it sends in response to a subsequent offer.  If the answerer needs to disable the first valid m line(s), it must instead accept the m line(s) in response to the latest pending offer (if there is one) and immediately send a new SDP offer disabling the line by following the SDP offerer rule above.  

The only other rule to add is that the SDP offerer will never re-enable (set port to a non-zero value) a disabled m line before the first valid m line in a bundle group but will instead create a new m line and add it to the group.  This makes it unlikely that the answerer will reject the first valid m line of the bundle group in a subsequent SDP offer since it had previously accepted it and did not initiate the new transaction due to any changes in the configuration of local resources.

This isn't particularly elegant, but it applies the definition consistently and I think it works in all cases.

> Please note that I have also submitted a draft on how to fix BUNDLE.
> This doc is based on the modified BUNDLE proposal with different port
> information for each m line and compares several different additional
> modifications to BUNDLE.  The doc ends up recommending the use of the
> unspecified address for subsequent m lines in a bundle group in the SDP
> answer (not offer).  Please see the doc for details.
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Feb 2013 12:25:56 +0000

Hi,

> The intent is to reuse all of the existing information in the subsequent m lines except the connection, candidate and non-zero port information.  That excludes the crypto info as well.

And how do you expect intermediaries to understand that, when the ports are zero?

And, even if we don't consider intermediaries, I think it's BAD DESIGN to assume that we use a stream, and associated data, from m- lines with port zero. Port zero means that the stream associated with the m- line is DISABLED.

> A zero port value would retain its original semantic of disabling/rejecting an individual m line.  In my proposal all subsequent m lines in the SDP answer that are accepted 
>would have valid and unique non-zero port values that are different from the port value in the first m line of the bundle group.

>Let's specify that we get the connection and port information for the bundle from the first valid (non-zero port) m line 
>in the bundle group of the SDP answer (not offer).  If the answerer wants to disable the first valid m line(s) of the bundle 
>group in the first SDP offer, both ends use the connection and port information from the next valid m line in the SDP 
>answer (and its corresponding m line in the SDP offer).  The offerer had valid information for each m line in the SDP 
>offer so it doesn't matter which set we use after the first offer/answer transaction.  But we don't want to 
>change the 5-tuple or crypto info for the bundle with any subsequent offer/answer.
>
>If the offerer wants to disable the first valid m line(s) of a bundle group in a subsequent offer, it places the 
>connection and port information for the bundle group in the next valid m line of the bundle group in the SDP 
>offer (it would actually move this information from the previous first valid m line to the new one to avoid 
>restarting crypto or changing ports).
>In response to the new offer disabling the initial valid m line(s), the answerer similarly places the connection and 
>port information for the bundle group in the corresponding m line of the SDP answer.  

I think that's very hacky, moving information from one m- line to another...

>The answerer is not allowed to disable the first valid m line of a bundle group in the SDP answer it sends in response 
>to a subsequent offer. If the answerer needs to disable the first valid m line(s), it must instead accept the m line(s) in 
>response to the latest pending offer (if there is one) and immediately send a new SDP offer disabling the line by following 
>the SDP offerer rule above.

I don't think we should have a solution where the answerer is not allowed to reject an m- line.

>The only other rule to add is that the SDP offerer will never re-enable (set port to a non-zero value) a disabled m line 
>before the first valid m line in a bundle group but will instead create a new m line and add it to the group.  This makes 
>it unlikely that the answerer will reject the first valid m line of the bundle group in a subsequent SDP offer since it had 
>previously accepted it and did not initiate the new transaction due to any changes in the configuration of local resources.

What if you have a session where a stream is enabled/disabled many times. If, every time you re-enable, is going to add a new m- line, you may end up with a very large SDP...

>This isn't particularly elegant, but it applies the definition consistently and I think it works in all cases.

I think it's very hacky, and I don't see how you think that intermediaries (which your draft focues on) would be able to handle this...

Regards,

Christer

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 21 Feb 2013 14:05:12 +0000

Hi Christer,
My proposal never has a zero port on a valid m line, in either offer or answer.  I only use unspecified address (with valid port number) for subsequent m lines in answers.  I'm not sure how you got this from the description.  Let's discuss this on the call today.  I hope you are available.

Richard

> Sent: Thursday, February 21, 2013 6:26 AM
> To: Ejzak, Richard P (Richard); [email-masked]; [email-masked]
> Subject: RE: [MMUSIC] FW: New Version Notification for draft-ejzak-
> mmusic-bundle-alternatives-00.txt
> 
> 
> Hi,
> 
> >> First, as you will now have a single non-zero m- line, you still
> >> assume that entities (including intermediaries) will take
> information
> >> (media types, payload type mappings etc etc etc - even protocol, if
> >> we decide to also allow the data channel in the bundle) from all m-
> >> lines. Or, do you intend to put all that information into a single
> m-
> >> line? If so, in my opinion MMT is a much better approach.
> >
> > The intent is to reuse all of the existing information in the
> subsequent m lines except the connection, candidate and non-zero port
> information.  That excludes the crypto info as well.
> 
> And, even if we don't consider intermediaries, I think it's BAD DESIGN
> to assume that we use a stream, and associated data, from m- lines with
> port zero. Port zero means that the stream associated with the m- line
> is DISABLED.
> 
> >> Second, what if a user wants the disable, or reject, a specific
> >> stream, using port zero? How is it done in case the stream is
> already
> > A zero port value would retain its original semantic of
> >disabling/rejecting an individual m line.  In my proposal all
> subsequent m lines in the SDP answer that are accepted would have valid
> and unique non-zero port values that are different from the port value
> in the first m line of the bundle group.
> 
> >I admit that I did not think through how to disable the first m line
> in the group, but let me propose the following:
> >
> >Let's specify that we get the connection and port information for the
> >bundle from the first valid (non-zero port) m line in the bundle group
> >of the SDP answer (not offer).  If the answerer wants to disable the
> >first valid m line(s) of the bundle group in the first SDP offer, both
> >ends use the connection and port information from the next valid m
> line
> >in the SDP answer (and its corresponding m line in the SDP offer).
> The offerer had valid information for each m line in the SDP offer so
> it doesn't matter which set we use after the first offer/answer
> transaction.  But we don't want to change the 5-tuple or crypto info
> for the bundle with any subsequent offer/answer.
> >
> >If the offerer wants to disable the first valid m line(s) of a bundle
> >group in a subsequent offer, it places the connection and port
> >information for the bundle group in the next valid m line of the
> bundle
> >group in the SDP offer (it would actually move this information from
> the previous first valid m line to the new one to avoid restarting
> crypto or changing ports).
> >In response to the new offer disabling the initial valid m line(s),
> the
> >answerer similarly places the connection and port information for the
> bundle group in the corresponding m line of the SDP answer.
> 
> >The answerer is not allowed to disable the first valid m line of a
> >bundle group in the SDP answer it sends in response to a subsequent
> >offer. If the answerer needs to disable the first valid m line(s), it
> >must instead accept the m line(s) in response to the latest pending
> offer (if there is one) and immediately send a new SDP offer disabling
> the line by following the SDP offerer rule above.
> 
> >The only other rule to add is that the SDP offerer will never re-
> enable
> >(set port to a non-zero value) a disabled m line before the first
> valid
> >m line in a bundle group but will instead create a new m line and add
> >it to the group.  This makes it unlikely that the answerer will reject
> the first valid m line of the bundle group in a subsequent SDP offer
> since it had previously accepted it and did not initiate the new
> transaction due to any changes in the configuration of local resources.
> 
> What if you have a session where a stream is enabled/disabled many
> times. If, every time you re-enable, is going to add a new m- line, you
> may end up with a very large SDP...
> 
> >This isn't particularly elegant, but it applies the definition
> consistently and I think it works in all cases.
> 
> I think it's very hacky, and I don't see how you think that
> intermediaries (which your draft focues on) would be able to handle
> this...
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > Subject: [MMUSIC] FW: New Version Notification for draft-ejzak-
> mmusic-
> > bundle-alternatives-00.txt
> >
> > unspecified address for subsequent m lines in a bundle group in the
> > SDP answer (not offer).  Please see the doc for details.
> >
> > Htmlized:        http://tools.ietf.org/html/draft-ejzak-mmusic-
> bundle-
> > alternatives-00
> >
> >
> > Abstract:

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Feb 2013 14:13:22 +0000

Hi,

>My proposal never has a zero port on a valid m line, in either offer or answer.  I only use unspecified address (with valid port number) for subsequent m lines in answers.  I'm not sure how you got this from the description.  Let's discuss 
>this on the call today.  I hope you are available.

Sorry, I mixed up terminology.

But, still, if you want to disable/reject the m- line which contains the bundle ADDRESS, you will have to move the address to another m- line.

And, still, you expect intermediaries to retrieve media types, protocols, payload types etc from the m- lines, which addresses are unspecified - but at the same time you say that no resources will be reserved for the m- lines with unspecified addresses...

Regards,

Christer

> to assume that we use a stream, and associated data, from m- lines 
> with port zero. Port zero means that the stream associated with the m- 
> line is DISABLED.
> 
> subsequent m lines in the SDP answer that are accepted would have 
> valid and unique non-zero port values that are different from the port 
> value in the first m line of the bundle group.
> 
> >bundle from the first valid (non-zero port) m line in the bundle 
> >group of the SDP answer (not offer).  If the answerer wants to 
> >disable the first valid m line(s) of the bundle group in the first 
> >SDP offer, both ends use the connection and port information from the 
> >next valid m
> line
> times. If, every time you re-enable, is going to add a new m- line, 
> you may end up with a very large SDP...
> 
> > This doc is based on the modified BUNDLE proposal with different 
> > port information for each m line and compares several different 
> > additional modifications to BUNDLE.  The doc ends up recommending 
> > the use of the unspecified address for subsequent m lines in a 
> > bundle group in the SDP answer (not offer).  Please see the doc for details.
> >

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 21 Feb 2013 14:51:58 +0000

Hi Christer,
Please see below.

Richard

> >My proposal never has a zero port on a valid m line, in either offer
> or
> >answer.  I only use unspecified address (with valid port number) for
> subsequent m lines in answers.  I'm not sure how you got this from the
> description.  Let's discuss this on the call today.  I hope you are
> available.
> 
> But, still, if you want to disable/reject the m- line which contains
> the bundle ADDRESS, you will have to move the address to another m-
> line.

Yes.  As long as there is a simple rule for doing so I don't see a problem.

> 
> And, still, you expect intermediaries to retrieve media types,
> protocols, payload types etc from the m- lines, which addresses are
> unspecified - but at the same time you say that no resources will be
> reserved for the m- lines with unspecified addresses...

Intermediaries forwarding BUNDLE information have to understand SOMETHING about BUNDLE or they have no business forwarding it in the first place.  It's only in this case that the intermediary might need to use m lines with unspecified address to identity additional bandwidth requirements.  I meant that -port- resources could be released in this case.  I should have been more careful in describing this point.

Sending a subsequent offer with the same port in all bundled m lines has its own problems in 3pcc scenarios.  You should always send an offer that can pass through intermediaries that do not understand BUNDLE.  My proposal has that characteristic but I'm not sure that yours does.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 21 Feb 2013 15:59:45 +0100

On 02/21/2013 03:51 PM, Ejzak, Richard P (Richard) wrote:
> Sending a subsequent offer with the same port in all bundled m lines 
> has its own problems in 3pcc scenarios. You should always send an 
> offer that can pass through intermediaries that do not understand 
> BUNDLE. My proposal has that characteristic but I'm not sure that 
> yours does.
Designing around intermediaries that pass along information that they do 
not understand, and then expect to act independently based on the 
message that they partially understood, seems to me to be a quite 
limiting approach.

We discussed this at the interim (I think Cullen was pretty vocal that 
there's a limit to how much brokenness we can design around, and he 
thought intermediaries passing BUNDLE without understanding BUNDLE were 
clearly beyond that limit).

(Cullen, apologies if I misstate what you said).

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 21 Feb 2013 17:39:01 +0000

Hi Harald,
I did not mean that an intermediary should forward attributes it doesn't understand but that an intermediary should be able to deal with any SDP it receives.  If some intermediaries choke on having the same port in multiple m lines then we should avoid doing that, even during subsequent offers since there are multiple 3pcc scenarios where subsequent offers can flow through different intermediaries.

We had a lot of discussion of this and other aspects during the call today.  We have more work to do before Orlando.

Richard

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Harald Alvestrand
> Sent: Thursday, February 21, 2013 9:00 AM
> To: [email-masked]
> Subject: [MMUSIC] Requiring support for nonconformant intermediate
> systems (Re: FW: New Version Notification for draft-ejzak-mmusic-
> bundle-alternatives-00.txt)
> 
> Designing around intermediaries that pass along information that they
> do not understand, and then expect to act independently based on the

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 22 Feb 2013 11:49:00 +0000

Hi,

>I did not mean that an intermediary should forward attributes it doesn't understand but that an intermediary should be able to deal with any 
>SDP it receives.  If some intermediaries choke on having the same port in multiple m lines then we should avoid doing that, even during 
>subsequent offers since there are multiple 3pcc scenarios where subsequent offers can flow through different intermediaries.

The BUNDLE solution expects the intermediary to accept the same port number. 

Your solution expects the intermediary to understand that, eventhough the addresses for all-but-one m- lines are unspecified, media associated with those m- lines will still be sent - using the port of another m- line.

I still strongly think that sending media associated with m- lines, for which the address is unspecified, is a design error.

(It is true that we need to expect that, or somehow ensure that, an intermediary calculates the correct bandwidth for bundled media, but that applies to both solutions).

Regards,

Christer

> thought intermediaries passing BUNDLE without understanding BUNDLE 
> were clearly beyond that limit).
>

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Fri, 22 Feb 2013 14:41:05 +0000

Hi Christer,

> Your solution expects the intermediary to understand that, eventhough
> the addresses for all-but-one m- lines are unspecified, media
> associated with those m- lines will still be sent - using the port of
> another m- line.

But this requirement is only placed on intermediaries that have already indicated support for BUNDLE by forwarding the related attributes.  The unspecified address only needs to be included in the SDP answer, and not the offer, so it is returned within an established dialog, and there is no danger of sending it to an unknown intermediary.

> 
> I still strongly think that sending media associated with m- lines, for
> which the address is unspecified, is a design error.

I'm not sure how the term "design error" applies to a solution that behaves correctly and consistently under the given assumptions (there are other aspects to be fixed but bear with me for sake of argument).  It is true that I propose to clarify the meaning of unspecified address in the presence of BUNDLE, which is a new and as yet non-standardized concept.  There are many examples of such "clarifications" as we expand the capabilities that can be represented in SDP.  The key is backward compatibility.  If the concern is about intermediaries that forward BUNDLE attributes without understanding them, then there is little that can be done anyway.

Richard

> 
> (It is true that we need to expect that, or somehow ensure that, an
> intermediary calculates the correct bandwidth for bundled media, but
> that applies to both solutions).
> 
> Regards,
> 
> Christer

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 24 Feb 2013 20:39:01 -0500 (EST)

> From: Harald Alvestrand <[email-masked]>
> 

If we're going to succeed, we've got to be aware of the environment in
which the solution operates.  In principle, intermediate systems
should operate transparently, but they don't.

> clearly beyond that limit).

Maybe Cullen was vocal about that, but he also points out that C***o
NATs *have* to pay attention to the port numbers in media
descriptions, so they enforce the uniqueness of port assignments.

Because of problems like this, four of the "compatibility desiderata"
I included in my proposal document the behavior of middleboxes we have
to tolerate.
(http://tools.ietf.org/html/draft-worley-sdp-bundle-02#section-3.2)

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Feb 2013 09:09:57 +0000

Hi Richard,

> But this requirement is only placed on intermediaries that have already indicated support for BUNDLE by forwarding 
> the related attributes.  The unspecified address only needs to be included in the SDP answer, and not the offer, so it 
> is returned within an established dialog, and there is no danger of sending it to an unknown intermediary.
> 
>> I still strongly think that sending media associated with m- lines, 
>> for which the address is unspecified, is a design error.
>
> I'm not sure how the term "design error" applies to a solution that behaves correctly and consistently under the given 
> assumptions (there are other aspects to be fixed but bear with me for sake of argument).  It is true that I propose to 
> clarify the meaning of unspecified address in the presence of BUNDLE, which is a new and as yet non-standardized 
> concept.  There are many examples of such "clarifications" as we expand the capabilities that can be represented 
> in SDP.  The key is backward compatibility.  If the concern is about intermediaries that forward BUNDLE attributes 
> without understanding them, then there is little that can be done anyway.

There are intermediaries that do not modify SDP - they simply look at the address information in order to open gates etc.

But, my comment is not related to intermediaries: I think it's an general SDP design error.

Regards,

Christer