Subject: [MMUSIC] Confirming consensus on way forward with Bundle

From: Ari Keränen <[email-masked]>
Date: Mon, 15 Apr 2013 16:56:43 +0300

At the Orlando meeting we had a call for consensus (see the minutes of 
the meeting at [1]) on using the current SDP bundle WG document [2] as 
the baseline of the bundle work. That is, using the offer/answer 
exchange as outlined in the draft (subject to clarifying comments made 
during the meeting) and using the port numbers as described in the draft.

The other option would be to not use this as the baseline but to 
continue discussing the alternative methods.

The show-of-hands at the meeting was around 30 for (going forward with 
the method described in the WG bundle doc) and 4 against. The MMUSIC 
chairs would like to confirm the consensus on this.

Those who were not present at the meeting to comment on this, please do 
so now.

Cheers,
Ari

[1] http://www.ietf.org/proceedings/86/minutes/minutes-86-mmusic
[2] http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-03

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 16 Apr 2013 13:28:49 +0000

Hi,

I stated during the discussion in Orlando that I believe the WG needs to do a deeper dive in to some of the more complex scenarios involving multiple ICE candidates (E.g. Dual Stack, relay candidates etc.).

After the meeting I thought about this some more and submitted http://tools.ietf.org/html/draft-hutton-mmusic-bundled-ice-candidates-00 which makes a small start on this. I will spend some time over the next couple of weeks thinking this out a bit more and will probably update the draft but any comments from the working group as to whether this is valuable or not would be appreciated.

My thinking is that this might be an extension to the current approach rather than an alternative.

Regards
Andy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ari Keränen
> Sent: 15 April 2013 14:57
> To: mmusic
> Subject: [MMUSIC] Confirming consensus on way forward with Bundle
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Justin Uberti <[email-masked]>
Date: Tue, 16 Apr 2013 23:12:24 -0700

I support using the current BUNDLE document as the basis of future
multiplexing work.

However, I agree there are a number of outstanding details that need to be
resolved before this specification is implementable.

On Tue, Apr 16, 2013 at 6:28 AM, Hutton, Andrew <
[email-masked]> wrote:

> Hi,
>
> I stated during the discussion in Orlando that I believe the WG needs to
> do a deeper dive in to some of the more complex scenarios involving
> multiple ICE candidates (E.g. Dual Stack, relay candidates etc.).
>
> After the meeting I thought about this some more and submitted
> http://tools.ietf.org/html/draft-hutton-mmusic-bundled-ice-candidates-00which makes a small start on this. I will spend some time over the next
> couple of weeks thinking this out a bit more and will probably update the
> draft but any comments from the working group as to whether this is
> valuable or not would be appreciated.
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 Apr 2013 06:37:53 +0000

Hi,

For obvious reasons I also support using the current BUNDLE document as basis.

There for sure are issues that need to be resolved. But, once we agree on the basis, we will be able to put all focus on those issues :)

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: 17. huhtikuuta 2013 9:12
To: Hutton, Andrew
Cc: Ari Keränen; mmusic
Subject: Re: [MMUSIC] Confirming consensus on way forward with Bundle

I support using the current BUNDLE document as the basis of future multiplexing work.

However, I agree there are a number of outstanding details that need to be resolved before this specification is implementable.

On Tue, Apr 16, 2013 at 6:28 AM, Hutton, Andrew <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards
Andy

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> Behalf Of Ari Keränen
> [email-masked]<mailto:[email-masked]>
_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 17 Apr 2013 17:06:58 -0400 (EDT)

> From: Ari KerC$nen <[email-masked]>
> 

I am not convinced that draft-ietf-mmusic-sdp-bundle-negotiation-03 is
the best approach.  In particular, I think the approach in the MMT
proposal would be an improvement, where there is a separate m= line to
describe the bundle as a whole, as opposed to just specifying that
certain flows are to share a port.

Unfortunately, I've not seen some of the earlier parts of the
discussion, and there may have been a discussion why having a bundle
m= line is undesirable.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 17 Apr 2013 17:07:15 -0400 (EDT)

It seems to me that the essence of
draft-hutton-mmusic-bundled-ice-candidates-00 is to extend ICE
candidates to effectively specify two address/ports that is available
for the remote UA to contact this UA.  One address/port is the
standard ICE address/port and the other is the "bundleport", and
indicates an address/port that the remote UA can contact using
bundled/multiplexed media.

If the candidates for two different m= lines specify the same
bundleport, it would be useful to define the ICE procedures to ensure
that connectivity to that address/port is tested only once for any
remote address/port.  If the remote UA is not bundling/multiplexing,
this does not change anything, as connectivity has to be tested
separately for each transport association (5-tuple).  But if both ends
are using bundling, we could have 3 m= lines for each UA, but only
effectively one set of candidate address/ports at each end.  We
wouldn't want to repeat the connectivity checks 3 times over.

Also, what is the order of testing of ICE candidates if bundleport is
present?  My understanding is that ICE was carefully designed so that
both UAs test each candidate pair simultaneously.  What is the
timing/sequencing rules when bundleport is present to ensure that (1)
both UAs test each pair simultaneously, (2) the bundleport
address/ports are tested first if both ends support bundling, and (3)
the timing of "baseline" candidate testing is unchanged if either UA
does not support bundling?  It seems like we need a careful
specification of the changes to the candidate testing algorithm.

Dale

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 18 Apr 2013 16:57:12 +0000

Hi Dale,

Thanks for the comments see some responses below.

Andy

> Behalf Of Dale R. Worley
> Sent: 17 April 2013 22:07
> To: [email-masked]
> Subject: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-00
> 

[AndyH] - Yes. I am thinking that there are advantages to explicitly state the bundle address rather than relying on rules to determine which port to use. 

> wouldn't want to repeat the connectivity checks 3 times over.

[AndyH] This is covered in the existing bundle draft which states that connectivity checks are performed on the bundle group rather than each m= line. 

> present?  

[AndyH] I don't think there is any change to existing procedures here.

> My understanding is that ICE was carefully designed so that

---

From: <[email-masked]>
Date: Thu, 18 Apr 2013 17:11:58 +0000

Hi,

I also reviewed the draft and was trying to understand what problems it is trying to solve. It is easier to find a solution if we agree on the requirements. From the draft I gathered that it tries to address at least these two limitations in [1]:

1.)

   A problem with the existing bundling proposals is that it does not
   appear possible to create a single initial offer that will allow
   bundle to be negotiated but maintain interworking with bundle unaware
   implementations and therefore it is necessary to perform an initial
   offer/answer exchange which does not fully describe or at least only
   implicitly describes what the offerer really wants to offer.  The
   existing bundle proposals also don't take account of the fact that
   when both parties support ICE [RFC5245] the port in the m-line of the
   initial offer may not be used at all, for example due to a dual stack
   offer endpoint offering IPv4 and IPv6 addresses in parallel.

Markus: This is a relevant point if indeed call setup time or even the number of messages can somehow be reduced in some of the situations. But is that the case here? I think that if both peers support bundle (as in [1]), they can start bundle-related connectivity checks immediately, and do not need to do any other connectivity checks. Is there a substantial difference in this regard?

2.)

   Also the existing bundle proposals have not considered some of the
   more complex ICE scenarios involving multiple candidates.  For
   example when an SDP m-line contains multiple ICE host candidates
   during dual stack negotiation, the candidates cannot be considered
   equivalent with regard to bundling with candidates on in another
   m-line and therefore some way of indicating which candidates can be
   bundled seems to be desirable.  This could be achieved by including
   the complete bundle transport address (IP and Port) in the candidate
   or by providing some kind of bundle linkage within the ICE candidate
   lines.

Markus: This seems to support exotic situations like that the offerer would be willing to bundle over IPv6, but not over IPv4. Personally I'm not sure if there are good real use cases for this type of capability. Any concrete ideas where this would be useful?

[1] http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/

Regards,
	Markus

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Dale R. Worley
Sent: 18 April, 2013 00:07
To: [email-masked]
Subject: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-00

It seems to me that the essence of
draft-hutton-mmusic-bundled-ice-candidates-00 is to extend ICE candidates to effectively specify two address/ports that is available for the remote UA to contact this UA.  One address/port is the standard ICE address/port and the other is the "bundleport", and indicates an address/port that the remote UA can contact using bundled/multiplexed media.

If the candidates for two different m= lines specify the same bundleport, it would be useful to define the ICE procedures to ensure that connectivity to that address/port is tested only once for any remote address/port.  If the remote UA is not bundling/multiplexing, this does not change anything, as connectivity has to be tested separately for each transport association (5-tuple).  But if both ends are using bundling, we could have 3 m= lines for each UA, but only effectively one set of candidate address/ports at each end.  We wouldn't want to repeat the connectivity checks 3 times over.

Also, what is the order of testing of ICE candidates if bundleport is present?  My understanding is that ICE was carefully designed so that both UAs test each candidate pair simultaneously.  What is the timing/sequencing rules when bundleport is present to ensure that (1) both UAs test each pair simultaneously, (2) the bundleport address/ports are tested first if both ends support bundling, and (3) the timing of "baseline" candidate testing is unchanged if either UA does not support bundling?  It seems like we need a careful specification of the changes to the candidate testing algorithm.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 18 Apr 2013 14:33:17 -0400 (EDT)

> From: "Hutton, Andrew" <[email-masked]>
> 
> [AndyH] This is covered in the existing bundle draft which states
> that connectivity checks are performed on the bundle group rather
> than each m= line. 

What I see in draft-ietf-mmusic-sdp-bundle-negotiation-03 is

   8.3.  Candidates

   Once it is known that both endpoints support, and accept to use, the
   "BUNDLE" grouping extension, ICE connectivity checks and keep-alives
   only needs to be performed for the whole "BUNDLE" group, instead of
   for each individual "m=" line associated with the group.

which is more a sketch than a description of the algorithm.

I suppose what is bothering me is that
draft-hutton-mmusic-bundled-ice-candidates modifies the procedures of
draft-ietf-mmusic-sdp-bundle-negotiation, and
draft-ietf-mmusic-sdp-bundle-negotiation modifies the procedures RFC
5245.  Neither modification is large, but stacking two
weakly-specified modifications together makes me worry that nobody has
a clear understanding of what the combined procedure really is, and it
is hard to examine the combined procedure for unintended consequences.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Apr 2013 09:13:09 +0000

Hi,

> I also reviewed the draft and was trying to understand what problems it is trying to solve. It is easier to find a solution if we 
> agree on the requirements. From the draft I gathered that it tries to address at least these two limitations in [1]:
>
>1.)
>

The fact that you may end up not using the port in the m- line is normal ICE procedures. But, I do agree that we should add some text about that.

> Markus: This is a relevant point if indeed call setup time or even the number of messages can somehow be reduced in some of the 
> situations. But is that the case here? I think that if both peers support bundle (as in [1]), they can start bundle-related connectivity checks 
> immediately, and do not need to do any other connectivity checks. Is there a substantial difference in this regard?
>
> 2.)
>
> Markus: This seems to support exotic situations like that the offerer would be willing to bundle over 
> IPv6, but not over IPv4. Personally I'm not sure if there are good real use cases for this type of capability. 
> Any concrete ideas where this would be useful?

I don't really think we need to consider this. If an endpoint wants to change its candidates, e.g. based on whether bundle will be used or not, it can send a new offer, with new candidates.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Dale R. Worley
Sent: 18 April, 2013 00:07
To: [email-masked]
Subject: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-00

Dale

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 20 Apr 2013 09:14:08 -0700

Agreed.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 22 Apr 2013 21:22:04 +0000

> is hard to examine the combined procedure for unintended consequences.

[AndyH] I agree which is why I thought that if we decided draft-hutton-mmusic-bundled-ice-candidates was useful it would be incorporated in to the bundle draft.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 22 Apr 2013 21:46:08 +0000

Comments below.

> Behalf Of Christer Holmberg
> Sent: 19 April 2013 10:13
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [MMUSIC] draft-hutton-mmusic-bundled-ice-candidates-00
> 
> Hi,
> 
> > I also reviewed the draft and was trying to understand what problems
> it is trying to solve. It is easier to find a solution if we
> > agree on the requirements. From the draft I gathered that it tries to
> address at least these two limitations in [1]:
> >
> >1.)
> >
> The fact that you may end up not using the port in the m- line is
> normal ICE procedures. But, I do agree that we should add some text
> about that.

[AndyH] - I agree.

> 
> > Markus: This is a relevant point if indeed call setup time or even
> the number of messages can somehow be reduced in some of the
> > situations. But is that the case here? I think that if both peers
> support bundle (as in [1]), they can start bundle-related connectivity
> checks
> > immediately, and do not need to do any other connectivity checks. Is
> there a substantial difference in this regard?

[AndyH] - No. The difference is only that everything relating to the candidate is explicit within the candidate line which makes it more readable and less prone to errors.

> > IPv6, but not over IPv4. Personally I'm not sure if there are good
> real use cases for this type of capability.
> I don't really think we need to consider this. If an endpoint wants to
> change its candidates, e.g. based on whether bundle will be used or
> not, it can send a new offer, with new candidates.

[AndyH] I am not so convinced and not sure I understand the comment about changing the candidates with a new offer. If anybody wants to specify a bundle where it is only possible to bundle some candidates and not others then we would not have a way of doing this. The bundle over IPv6 but not IPv4 is one case but more likely it could be that say host candidates can be bundled but not relay candidates. 

> Behalf Of ext Dale R. Worley
> for the remote UA to contact this UA.  One address/port is the standard
> ICE address/port and the other is the "bundleport", and indicates an
> address/port that the remote UA can contact using bundled/multiplexed
> media.
>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 23 Apr 2013 10:26:27 -0400

Thank you all for the responses. Based on the e-mail thread, the 
consensus decision from the Orlando meeting still stands in accordance 
with the below.

Thanks

-- Ari & Flemming (MMUSIC chairs)

On 4/15/13 9:56 AM, Ari Keränen wrote:
> Those who were not present at the meeting to comment on this, please 
> do so now.
>
>
> Cheers,
> Ari
>
> [2] 
> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-03
> .
>