Subject: [MMUSIC] Signaling trickle support

From: Martin Thomson <[email-masked]>
Date: Wed, 7 Nov 2012 08:59:41 -0500

Matthew, Justin and I were discussing the problem of signaling trickle
ICE support and the following proposal was made:

The 24th bit in SDP is currently set to zero.  This bit is
specifically reserved for forward compatibility purposes.  We can use
this bit.  Set this bit to one to indicate support for trickle ICE.

This meets the "works if supported, fails if it doesn't criteria".

This solution may also be appropriate for bundle/mmt/whatever.

---

From: Emil Ivov <[email-masked]>
Date: Wed, 07 Nov 2012 10:18:47 -0500

Hey Martin,

> this bit.  Set this bit to one to indicate support for trickle ICE.

bit 24? So, you mean setting the version to 1? Is that it?

Could you please point us to the spec you have in mind?

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Wed, 07 Nov 2012 12:00:55 -0500

> bit 24? So, you mean setting the version to 1? Is that it?

OK, it appears (from our offline chat) that this is indeed what you meant.

So, I couldn't find anything in 4566 or 3264 that says an offer MUST be
rejected in the case where the version number is different from 0, but I
might be missing some text (could you please point me to the right place
if you have it?)

That said I think it's a great idea and we should even take it further!
For example we could give v=2 a meaning of bundle support. v=3 would
then mean cundle. v=4 would of course be MMT.

Then, v=5 would be trickle+bundle, v=6: trickle+cundle, v=7:
trickle+mmt, v=8: bundle+mmt, v=9: cundle+mmt, v=10:trickle+bundle+mmt.

And of course if we get a rejection for v=10, we would then be able to
reissue three separate offers for v=1, v=2, and v=4 and this way we'll
know exactly why the offer failed.

Now all that's left is to put this into text and go for WGLC because it
is crystal clear no one will have a problem with it ;)

Emil

-- 
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Nov 2012 14:27:35 -0500

> This solution may also be appropriate for bundle/mmt/whatever.

After some side discussion, I guess you are talking about bits in the 
value of the v= field ???

If so, I still have no idea what you are talking about. The syntax for 
the value of v= is 1*DIGIT. You can choose to represent that in binary 
and then choose bit 24 if you want, but that has no significance in 4566.

Assigning a new SDP version to signal Trickle ICE support seems like an 
incredibly bad idea.

	Thanks,
	Paul

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 8 Nov 2012 08:30:15 +0100

As an individual...

I concur with Paul, changing the v= version in the SDP is a very bad idea.

Let met quote RFC 4566:

    The "v=" field gives the version of the Session Description Protocol.
    This memo defines version 0.  There is no minor version number.

This means that if you define another version different than zero, then, 
as a side effect, you are creating a different version of SDP than the 
one specified in RFC 4566. So, you will need to create an RFC specifying 
how such version of SDP works.

/Miguel

On 07/11/2012 20:27, Paul Kyzivat wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Nov 2012 14:23:19 +0000

+1

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miguel A. Garcia
Sent: 8. marraskuuta 2012 9:30
To: Paul Kyzivat; Martin Thomson; Emil Ivov
Cc: [email-masked]
Subject: Re: [MMUSIC] Signaling trickle support

As an individual...

Let met quote RFC 4566:

This means that if you define another version different than zero, then, as a side effect, you are creating a different version of SDP than the one specified in RFC 4566. So, you will need to create an RFC specifying how such version of SDP works.

/Miguel

On 07/11/2012 20:27, Paul Kyzivat wrote:
>> Matthew, Justin and I were discussing the problem of signaling 
>> trickle ICE support and the following proposal was made:
>>
> Assigning a new SDP version to signal Trickle ICE support seems like 
> an incredibly bad idea.
>
>      Thanks,
>      Paul
>

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 08 Nov 2012 10:01:27 -0500

This is very different from the way we normally handle extensions in SDP 
both from a pure signaling and negotiation point of view. I share the 
sentiment of others that this does not look like a good idea but would 
like to understand if there were other considerations for suggesting 
this radically different approach.

Thanks

-- Flemming

On 11/8/12 9:23 AM, Christer Holmberg wrote:
> .

---

From: Emil Ivov <[email-masked]>
Date: Thu, 08 Nov 2012 10:12:59 -0500

I actually think this was supposed to be a joke. At least that's how I
got it.

Emil

-- 
https://jitsi.org

---

From: Martin Thomson <[email-masked]>
Date: Thu, 8 Nov 2012 10:46:49 -0500

Trolled.

Though to be honest, I don't see a way around this particular problem.
 The idea of using a Require: trickle header is fraught with problems;
the idea that you might use an a= line doesn't give you the
characteristics you desire.  I just don't know how to cause the
failure that is needed when this isn't supported.

Besides, the failure modes all lead to an expenditure of time that is
worse than the simple candidate gathering scenarios (reflexive,
relay), though not "other" gathering methods (UPnP, etc...).

half-trickle is a reasonable solution.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 08 Nov 2012 10:53:07 -0500

> failure that is needed when this isn't supported.
Can we capture the desired characteristics and failure mode for starters ?

> relay), though not "other" gathering methods (UPnP, etc...).
Is there a requirement here that needs to be written down ?

> half-trickle is a reasonable solution.
Sorry - what's half-trickle ?

-- Flemming

---

From: Emil Ivov <[email-masked]>
Date: Thu, 08 Nov 2012 11:29:53 -0500

Hey Flemming,

> Can we capture the desired characteristics and failure mode for starters ?

The "really" desired characteristic is knowing in advance whether or not
the remote party can do trickle so that you know whether you can afford
to send an empty offer without causing it to freak out.

Since protocols like SIP don't really have things like XMPP disco and
Cap Neg that would have allowed it, we were considering other options.
One such option would be to send a trickle offer and format it in a way
that would cause a non-trickle answerer to reject it in a _predictable_
way. This would allow the offerer to retry with a regular ICE offer.

> Is there a requirement here that needs to be written down ?

The point that Martin is making is that sending an offer and then
waiting for the failure may potentially take longer than just gathering
your candidates. This is true especially in cases where the offerer is
only planning on using a single port, on a single interface, with a
single STUN/TURN server and no other candidate gathering mechanisms.

But then, if this really is the case, the offerer knows it and can
choose not to do the probing.

> Sorry - what's half-trickle ?

We had that in the slides on Tuesday but it's not yet in the draft. The
idea is that if you can't confirm support for trickle in the answerer,
you just send a vanilla ICE offer and you also indicate you do support
trickle. A trickle ICE answerer can then trickle candidates and in
general you get half the optimizations of Trickle ICE. You even get more
than that in case the offerer is able to predictively gather candidates
before the call is initiated.

We'll describe this in the next version.

Cheers,
Emil

-- 
https://jitsi.org

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 08 Nov 2012 14:07:30 -0500

> to send an empty offer without causing it to freak out.
Why would you send an empty offer ?

> way. This would allow the offerer to retry with a regular ICE offer.
I thought the point with trickle-ICE was to reduce call setup latency 
and hence you would want to make sure that things complete in as few 
round-trips as possible. This doesn't seem to line up with that (?).

> single STUN/TURN server and no other candidate gathering mechanisms.
I would agree with that.
> choose not to do the probing.
Agreed.
> idea is that if you can't confirm support for trickle in the answerer,
Do you mean: if you don't know if the answerer supports it before 
sending an offer to him [since confirming support in the answer should 
be easy]  ?
> before the call is initiated.
Agreed.
> We'll describe this in the next version.
Ok - thanks for the explanation.

-- Flemming

---

From: Emil Ivov <[email-masked]>
Date: Thu, 08 Nov 2012 14:25:24 -0500

Hey Flemming,

> Why would you send an empty offer ?

Normally the offer should contain only candidates that are readily
available (such as host candidates). However if the offerer does not
wish to disclose those for privacy reasons, then it would just send an
offer with no candidates. This is for example how Chrome currently behaves.

It also places 0.0.0.0:1 in the c= and m= lines.

That's currently explain in section 4 of the draft:

http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle-00#section-4

> I thought the point with trickle-ICE was to reduce call setup latency

It is.

> round-trips as possible. This doesn't seem to line up with that (?).

The thing is that in cases where trickle ICE support cannot be
pre-confirmed you have to fall back to half trickle. The probing
requests would hence allow for an optimisation compared to that.

With half-trickle the offerer has to gather all candidates anyway so,
while doing so, they might as well try and check if they really need to
complete it before sending their first offer.

> sending an offer to him 

Yes. That's what I meant. The offerer needs to know that in advance in
order to decide how to form their offer.

Cheers,
Emil

> [since confirming support in the answer should 
> be easy]  ?

-- 
https://jitsi.org

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Nov 2012 19:34:33 +0000

> http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle-00#section-4

For SIP, why not just send an offerless INVITE? (it might even work sometimes ;)

Likewise for RTCWeb, send a request for a session without SDP whatsoever, and make the other side send an offer first (and write your JS to support that case).

-hadriel

---

From: Emil Ivov <[email-masked]>
Date: Thu, 08 Nov 2012 14:48:18 -0500

Hey Hadriel,

> Likewise for RTCWeb, send a request for a session without SDP whatsoever, and make the other side send an offer first (and write your JS to support that case).

I was thinking along those lines at one point too:

http://www.ietf.org/mail-archive/web/mmusic/current/msg09681.html

Christer made a comment that this would work badly with legacy:

http://www.ietf.org/mail-archive/web/mmusic/current/msg09698.html

And besides, that would also prevent you from letting the offerer (and
the calling user) choose what kind of call/content they'd like to have
(i.e. audio or video or a conference or a slide show, etc).

Cheers,
Emil

-- 
https://jitsi.org

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 08 Nov 2012 17:21:26 -0500

> http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle-00#section-4
Ok (that's not an empty offer though).

> requests would hence allow for an optimisation compared to that.
Somewhat unclear to me as it builds upon an assumption that it is 
somehow "more efficient"to probe than to collect candidates. Clarifying 
the criteria for something being "more efficient" would also be helpful 
here (what is it truly that we are after; setup delay reduction, fewer 
NAT bindings, ...)

> complete it before sending their first offer.
Unclear to me since you can collect candidates before you know who to 
send the offer to.

Thanks

-- Flemming

---

From: Emil Ivov <[email-masked]>
Date: Thu, 08 Nov 2012 18:24:35 -0500

Hey Flemming,

On 08.11.12, 17:21, Flemming Andreasen wrote:
> somehow "more efficient"to probe than to collect candidates.

Indeed, this would not always be the case and it would basically come
down to comparing one signalling RTT to the duration of candidate
gathering.

As you agreed in one of your previous mails, the relation may vary:

Executing a single STUN transaction is likely to be less time consuming
than a signalling RTT. Candidate gathering however may also last a lot
longer than a single offer/answer exchange.

However, an agent that has several interfaces and uses them to gather
candidates for three streams that don't have bundle nor RTCP muxing is
going to need quite some time to complete a harvest. Add to this UPnP
allocations and a second STUN server and you could easily find the
signalling RTT tens of times shorter than the candidate gathering.

In all cases the UA would have a fairly good idea of what to expect so
it could easily determine whether or not a probe would make sense.

> Clarifying 

I believe we can agree that in the context of trickle the only thing
that matters is call setup duration.

> Unclear to me since you can collect candidates before you know who to 

You could ... but not always. A hard phone can easily do this when
someone picks it up. A softphone however doesn't have a clear early cue
about a pending call initiation so the only way would be to always
maintain a set of active candidates and to keep them alive. Not
necessarily the most desirable option, especially for large deployments.

A web page could be even worse, especially in cases where the calling
functionality is only a side feature (e.g. a support or a customer
service call option).

Cheers,
Emil

-- 
https://jitsi.org

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Fri, 9 Nov 2012 12:45:27 +0000

On Nov 9, 2012, at 24:24 AM, Emil Ivov <[email-masked]> wrote:

> going to need quite some time to complete a harvest.

>From our experience single allocation takes aprox 30ms. This includes one redirect due to alternate server and one extra roundtrip because of authentication. The time the TURN server is using to process the request is neglicable and so  it is RTT that is important. If the RTT is to large media would be troublesome anyway due to excessive jitter and delay.

Number of media lines and interfaces does not matter as this is done in parallel (or pretty close to). Our implementation have 5 media lines (Audio, 2x Video, BFCP, FECC), resulting in 9 TURN allocations. 

What we have been struggling with is delay in the signaling path. We have seen delays in the range of 3-5 seconds for the 200OK to traverse the signaling path. That caused some failing ICE calls due to to large skew and we did not complete the transactions in what we have set as a reasonable time. 

> Add to this UPnP
My understanding is that UPnP or PCP can be used to open pinholes without the need for keepalives.
So in theory this can be done when the endpoints registers. At least if we are not overly concerned about the extra port allocations on the NAT.

But I agree with the point. Additional steps to gather "better" candidates can take time.

> that matters is call setup duration.
Personally I see great benefit in having the ability to add candidates (and remove them) without doing a update or re-invite. This would make mobility scenarios easier, and developing a smarter and more optimized media experience can be a lot easier.  

.-.
Pål-Erik

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 09 Nov 2012 09:24:00 -0500

> As you agreed in one of your previous mails, the relation may vary:
I still agree with that :-)
> signalling RTT tens of times shorter than the candidate gathering.
Because of the min. 20 ms Ta timer constraints, which apply cross-media 
stream ? Can somebody refresh my mind as to why that is (e.g. are 
residential NATs at this point generally not capable of creating NAT 
bindings faster than at 20 ms intervals) ?

> that matters is call setup duration.
Ok - so reducing the number of NAT binding allocations is explicitly not 
a concern (only the time it takes to create those bindings, if that time 
is in the critical path for the actual call setup).

> necessarily the most desirable option, especially for large deployments.
I'm not sure I see much difference between hard and soft-phones here. 
For each, there is some sort of interaction before the call is initiated 
giving you a bit of a head-start to gather candidates. If we are trying 
to optimize out several seconds that may not help much, however if we 
are in the 100's ms range, then it will.
> functionality is only a side feature (e.g. a support or a customer
Why would a web page be worse ?

Thanks

-- Flemming

---

From: Emil Ivov <[email-masked]>
Date: Fri, 09 Nov 2012 09:43:47 -0500

On 09.11.12, 09:24, Flemming Andreasen wrote:
> stream ?

Yes, although not only. In the case of UPnP you may also have to spend
some time in discovery.

Other gathering mechanisms may involve different delays.

> Can somebody refresh my mind as to why that is (e.g. are 

I believe the idea was to maintain a bitrate that would be similar to
the one you will be using during the call. Otherwise you may end up with
packet bursts and packet drops that could delay conn checks.

> is in the critical path for the actual call setup).

In the context of Trickle ICE - yes.

> are in the 100's ms range, then it will.

Well, in our case for instance (Jitsi) the user is constantly
interacting with the application and the majority of these interactions
do not end with a call. IMs for example are a lot more frequent, and
then you also have other use cases such checking presence for others,
setting a presence status for the user, checking contact details,
viewing call history, etc.

All in all, you only know for sure that a call is being made, once the
call button is pressed.

> Why would a web page be worse ?

Because it could offer even more non-call use cases than a dedicated
application such as a softphone/messenger. Calls could be a relatively
corner use case for many web pages. Imagine for example a product page
on Amazon with a "Call the vendor" button. Calls would be relatively
rare and there would be no way to predict them until the button is pressed.

Emil

-- 
https://jitsi.org

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 09 Nov 2012 09:58:38 -0500

> packet bursts and packet drops that could delay conn checks.

That only explains why it applies within a media stream (which I can 
understand), not why it applies cross-media stream.

-- Flemming

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 09 Nov 2012 17:09:17 +0100

> this bit.  Set this bit to one to indicate support for trickle ICE.
hm... the 24th bit in SDP is zero, but setting it would make it SDQ.... 
why not set the 22nd bit and make it SDT (SDP with Trickle)?
> This meets the "works if supported, fails if it doesn't criteria".
I don't think it meets the "reverts to old behaviour if it doesn't work" 
criterion that previous attempts to extend SDP have jumped through 
Möbius hoops to maintain. But it's tempting.

---

From: Emil Ivov <[email-masked]>
Date: Fri, 09 Nov 2012 15:16:01 -0500

> understand), not why it applies cross-media stream.

True. I wasn't around at the time though so I have no idea how it ended
up being the cross-stream minimum.

Emil

-- 
https://jitsi.org

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 13 Nov 2012 10:03:33 +0100

On 11/09/2012 03:24 PM, Flemming Andreasen wrote:
> Because of the min. 20 ms Ta timer constraints, which apply 
> cross-media stream ? Can somebody refresh my mind as to why that is 
> (e.g. are residential NATs at this point generally not capable of 
> creating NAT bindings faster than at 20 ms intervals) ?
I have been told that in BEHAVE testing, NATs were found that would 
behave incoherently at short binding creation intervals, but none were 
found that couldn't handle one new binding every 20 ms, so this was set 
at the minimum interval for potentially binding-creation actions.

             Harald

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 13 Nov 2012 08:38:57 -0800

> On 11/09/2012 03:24 PM, Flemming Andreasen wrote:
...
> at the minimum interval for potentially binding-creation actions.

The behavior was noticed during deployment, not BEHAVE testing -- 
otherwise I would have a nice BEHAVE test report to cite.

And that NAT behavior, combined with ephemeral source ports for DNS
queries, is probably what is tripping up both Microsoft and Chromium, 
causing them to limit themselves to 6 (or so) DNS queries at a time, 
http://code.google.com/p/chromium/issues/detail?id=122566.  I am
told Windows 8 also restricts its number of simultaneous DNS queries.
If that NAT behavior is really what is tripping up Windows and
Chromium, it would be spiffy if -- instead of limiting the number
of outstanding queries -- the software would pace the queries, or
use different behavior when querying the local caching nameserver
which shouldn't suffer that problem.

-d

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 13 Nov 2012 12:57:06 -0500

> otherwise I would have a nice BEHAVE test report to cite.
Does the concern remain today or can we start being more aggressive in 
some of these ?

I've been told (second hand) that Google Maps routinely opens 50 TCP 
connections at a time, but don't have any details as to the speed with 
which they are opened. Anybody have any further insights or similar 
examples (that seem to work in practice) ?

> which shouldn't suffer that problem.
Interesting - thanks for the data point(er).

-- Flemming