Subject: [rtcweb] Comment on consent-freshness-14

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Jun 2015 18:12:05 +0000

Hi,

I had a look at the latest version (-14) of the consent-freshness draft.

The keep-alive issue we discussed earlier seems to be solved now.

However, I thought we were also going to add text saying that consent is only needed while media is sent on a given candidate pair, and allow the sender to stop sending consent requests when no data is sent on a candidate pair. Then, if the sender later wants to start sending media on the candidate pair again, it simply start sending consent requests again.

However, the way I read the draft now is that it would require an ICE restart, and I don't think we want that?

I think that ICE restart should only be required if the sender DOES send consent requests, but do not receive any response within 30 seconds.

Or, have I missed something?

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Thu, 18 Jun 2015 11:23:24 -0700

On 18 June 2015 at 11:12, Christer Holmberg
<[email-masked]> wrote:
> Then, if the sender later wants to start sending media on the candidate pair
> again, it simply start sending consent requests again.

>From a security perspective, this would be OK.  Functionally however,
do you really expect that to work?  NATs and relays tend to garbage
collect pretty aggressively.

> However, the way I read the draft now is that it would require an ICE
> restart, and I don’t think we want that?

Why the question?  You are the one who has to decide if you want that.

Seriously, given the above, I would rather say that if you don't use
it, you lose it.  Are you concerned about the cost of an ICE restart,
or the cost of maintaining consent?

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Jun 2015 18:44:05 +0000

Hi,

>> Then, if the sender later wants to start sending media on the 
>> candidate pair again, it simply start sending consent requests again.
>
> From a security perspective, this would be OK.  Functionally however, do you really expect that to work?  
> NATs and relays tend to garbage collect pretty aggressively.

You would still send keep-alives, in order to keep the NAT bindings open.

> Seriously, given the above, I would rather say that if you don't use it, you lose it.  
> Are you concerned about the cost of an ICE restart, or the cost of maintaining consent?

Both, actually :)

Regarding ICE restart, it requires an offer/answer transaction. So, every time you switch from a candidate pair to another, if consent has expired on the candidate pair you switch to, you have to do an offer/answer. 

(In addition, can you do ICE restart on a single candidate pair?)

Regarding maintaining consent, if we have multiple candidate pairs, I am worried about the cost of having to maintain consent on all of them - even if we are only using one for sending data at any given time.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Thu, 18 Jun 2015 11:48:31 -0700

> You would still send keep-alives, in order to keep the NAT bindings open.
[...]
>> Are you concerned about the cost of an ICE restart, or the cost of maintaining consent?

Of course.  If you want to put someone on hold, maintaining consent,
as opposed to sending keep-alives is not that much of an additional
burden.

And if you are willing to let the pair go idle and rot, why not
require another O/A to restore it.

But I don't know your use case.  This seems (at least to me) a fairly
narrow window, and providing special allowances for it will only
increase complexity of implementations.  Can you justify making
everyone else's life that much worse?

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 18 Jun 2015 15:14:14 -0400

Comments below.

> On Jun 18, 2015, at 2:23 PM, Martin Thomson <[email-masked]> wrote:
> 

It might not work if no keepalives are sent. But Christer's point is that consent is not required since no media is being sent. 

> Why the question?  You are the one who has to decide if you want that.

I think Christer's point is that this should not be considered a loss of consent. The draft already says that consent is not needed on a pair if no media is being sent. So one might interpret the existing draft as not imposing an ICE restart requirement in that case (how can consent expire if consent is not required??)

> or the cost of maintaining consent?

[BA] Personally, I think that the existing draft is close to saying what Christer wants (if not already there). I would rather not add text on topics orthogonal to consent, such as ICE keepalive requirements.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 18 Jun 2015 15:17:08 -0400

> require another O/A to restore it.

[BA] Because the candidate pair might still be viable even if consent were not maintained on it while media was suspended (but other RFC 5245 requirements were met).

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Jun 2015 19:21:00 +0000

Hi,

> Of course.  If you want to put someone on hold, maintaining consent, as opposed to sending keep-alives is not that much of an additional burden.

I am not talking about putting someone on hold, in which case you wouldn't send media on any candidate pair. I am talking about not sending media on candidate pairs X, Y and Z because you are sending media on candidate pair W.

> And if you are willing to let the pair go idle and rot, why not require another O/A to restore it.

It depends on how often you switch between candidates, but I think we should avoid O/A transactions if we can. Also, as this can happen at both endpoints, you can end up with O/A race conditions, and all kind of messy stuff.

Also, according to the RFC 5245, while the ICE restart takes place, you are still supposed to be able to use the old candidate pairs. But, in this case this would not be allowed, since content has expired on the old candidate pairs. Doesn't that mean there is a risk of clipping etc?

>But I don't know your use case.  This seems (at least to me) a fairly narrow window, and providing special allowances for it will only increase >complexity of implementations.  Can you justify making everyone else's life that much worse?

Why do you think start re-using a candidate pair, without having to do ICE restart, makes lives hard? From experience I can tell you that having to deal with O/A race conditions etc DOES make life hard :)

Anyway, I think Justin and Bernard were previously involved in these discussions, so I'd like to hear what they think. 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Jun 2015 21:28:20 +0000

Hi,

> It might not work if no keepalives are sent. But Christer's point is that consent is not required since no media is being sent. 

Correct.

> I think Christer's point is that this should not be considered a loss of consent.

Correct. 

Loss of consent is defined as not receiving a response to a sent consent request - but in this case there is not consent request sent to begin with :)

> The draft already says that consent is not needed on a pair if no media is being sent. So one might 
> interpret the existing draft as not imposing an ICE restart requirement in that case (how can consent expire if consent is not required??)

Correct. 

I think all that is needed is a clarification statement saying that stop sending to consent requests shall not be considered loss of consent, and that a sender can later request consent on the same candidate pair again - without having to do an ICE restart.

ICE restart is only required when a sender has requested consent, but has not got it (i.e. there was no response to the consent freshness request).

Regards,

Christer

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Fri, 19 Jun 2015 06:37:35 +0530

On Fri, Jun 19, 2015 at 2:58 AM, Christer Holmberg <
[email-masked]> wrote:

> > It might not work if no keepalives are sent. But Christer's point is
> that consent is not required since no media is being sent.
>
> Correct.
>
>
> Loss of consent is defined as not receiving a response to a sent consent
> request - but in this case there is not consent request sent to begin with
> :)
>
> > interpret the existing draft as not imposing an ICE restart requirement
> in that case (how can consent expire if consent is not required??)
>
> Correct.
>
> I think all that is needed is a clarification statement saying that stop
> sending to consent requests shall not be considered loss of consent, and
> that a sender can later request consent on the same candidate pair again -
> without having to do an ICE restart.
>

​Existing test:
   An endpoint that is not sending any application data does not need to
   maintain consent.  However, not sending any traffic could cause NAT
   or firewall mappings to expire.  Furthermore, having one peer unable
   to send is detrimental to many protocols.  Absent better information
   about the network, if an endpoint needs to ensure its NAT or firewall
   mappings do not expire, it can be done using keepalive or other
   techniques (see Section 10 of [RFC5245] and see [RFC6263]).

New test:
   An endpoint that is not sending any application data after obtaining
   consent does not need to maintain consent. As soon as the endpoint
   starts sending application again, consent is maintained following the
   procedure described in this document.

   However, not sending any traffic could cause NAT or firewall mappings
   to expire. Furthermore, having one peer unable to send is detrimental
   to many protocols.  Absent better information about the network, if an
   endpoint needs to ensure its NAT or firewall mappings do not expire,
   it can be done using keepalive or other techniques (see Section 10 of
   [RFC5245] and see [RFC6263]).

Does it work?

thanks,
Muthu

>
> ICE restart is only required when a sender has requested consent, but has
> not got it (i.e. there was no response to the consent freshness request).
>
> Regards,
>
> Christer
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Fri, 19 Jun 2015 06:38:51 +0530

s/test/text..

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 18 Jun 2015 23:14:05 -0400

s/sending application/sending application data/

Otherwise, WFM.

> On Jun 18, 2015, at 9:08 PM, Muthu Arul Mozhi Perumal <[email-masked]> wrote:
> 
> s/test/text..
> 
>> On Fri, Jun 19, 2015 at 6:37 AM, Muthu Arul Mozhi Perumal <[email-masked]> wrote:
>>> On Fri, Jun 19, 2015 at 2:58 AM, Christer Holmberg <[email-masked]> wrote:
>> 
>>> Hi,
>>>

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Fri, 19 Jun 2015 08:48:56 +0530

Thanks. It was missed in a haste :)

Muthu

On Fri, Jun 19, 2015 at 8:44 AM, Bernard Aboba <[email-masked]>
wrote:

>>> > interpret the existing draft as not imposing an ICE restart
>>> requirement in that case (how can consent expire if consent is not
>>> required??)
>>>
>>> Correct.
>>>
>>> ICE restart is only required when a sender has requested consent, but
>>> has not got it (i.e. there was no response to the consent freshness
>>> request).
>>>
>>> Regards,
>>>
>>> Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Jun 2015 05:35:05 +0000

Hi,

The text otherwise looks good, but I suggest adding the following after the "As soon as..." statement: "In this case the endpoint does not need to perform ICE restart."

Thanks!

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Muthu Arul Mozhi Perumal<mailto:[email-masked]>
Sent: ‎19/‎06/‎2015 06:18
To: Bernard Aboba<mailto:[email-masked]>
Cc: Christer Holmberg<mailto:[email-masked]>; Martin Thomson<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Comment on consent-freshness-14

Muthu

On Fri, Jun 19, 2015 at 8:44 AM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:
s/sending application/sending application data/

Otherwise, WFM.

On Jun 18, 2015, at 9:08 PM, Muthu Arul Mozhi Perumal <[email-masked]<mailto:[email-masked]>> wrote:

s/test/text..

On Fri, Jun 19, 2015 at 6:37 AM, Muthu Arul Mozhi Perumal <[email-masked]<mailto:[email-masked]>> wrote:
On Fri, Jun 19, 2015 at 2:58 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Correct.

Correct.

Correct.

​Existing test:

New test:

Does it work?

thanks,
Muthu

Regards,

Christer
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Fri, 19 Jun 2015 11:31:58 +0530

I think an ICE-restart can still be performed for a bunch of other reasons.
Here is my take:

New text:
   An endpoint that is not sending any application data after obtaining
   consent does not need to maintain consent. The endpoint can resume
sending
   application data using the consent obtained earlier. As soon as the
endpoint
   resumes sending application data, consent is maintained following the
   procedure described in this document.

Would that work?

thanks,
Muthu

On Fri, Jun 19, 2015 at 11:05 AM, Christer Holmberg <
[email-masked]> wrote:

>  Hi,
>
> The text otherwise looks good, but I suggest adding the following after
> the "As soon as..." statement: "In this case the endpoint does not need to
> perform ICE restart."
>
> Thanks!
>
> Regards,
>
> Christer
>
>  ------------------------------
> From: Muthu Arul Mozhi Perumal <[email-masked]>
> To: Bernard Aboba <[email-masked]>
> Cc: Christer Holmberg <[email-masked]>; Martin Thomson
> <[email-masked]>; [email-masked]
>>>> Loss of consent is defined as not receiving a response to a sent
>>>> consent request - but in this case there is not consent request sent to
>>>> begin with :)
>>>>
>>>> I think all that is needed is a clarification statement saying that
>>>> stop sending to consent requests shall not be considered loss of consent,
>>>> and that a sender can later request consent on the same candidate pair
>>>> again - without having to do an ICE restart.
>>>>
>>>
>>>
>>>   ​Existing test:

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Jun 2015 08:55:29 +0000

Hi,

Sure, there may be a need to perform ICE restart for some other reasons, and my suggested text does not forbid it. But, I request a statement saying that an ICE restart is not required simply because you want to start sending data again.

Perhaps:

"In this case an ICE restart is not required, as is the case when the sender fails to get consent."

From experience I am pretty sure that, if we don't have explicit text, we will soon have do-I-need-to-do-ICE-restart mails on the list :)

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Muthu Arul Mozhi Perumal<mailto:[email-masked]>
Sent: ‎19/‎06/‎2015 09:01
To: Christer Holmberg<mailto:[email-masked]>
Cc: Bernard Aboba<mailto:[email-masked]>; Martin Thomson<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Comment on consent-freshness-14

I think an ICE-restart can still be performed for a bunch of other reasons. Here is my take:

New text:
   An endpoint that is not sending any application data after obtaining
   consent does not need to maintain consent. The endpoint can resume sending
   application data using the consent obtained earlier. As soon as the endpoint
   resumes sending application data, consent is maintained following the
   procedure described in this document.

Would that work?

thanks,
Muthu

On Fri, Jun 19, 2015 at 11:05 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thanks!

Regards,

Christer

Muthu

Otherwise, WFM.

s/test/text..

Correct.

Correct.

Correct.

​Existing test:

New test:

Does it work?

thanks,
Muthu

Regards,

Christer

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Fri, 19 Jun 2015 15:23:57 +0530

How about the following text?

   An endpoint that is not sending any application data after obtaining
   consent does not need to maintain consent. The endpoint can resume
sending
   application data using the consent obtained earlier (hence, does not need
   to perform ICE restart). As soon as the endpoint resumes sending
application
   data, consent is maintained following the procedure described in this
   document.

thanks,
Muthu

On Fri, Jun 19, 2015 at 2:25 PM, Christer Holmberg <
[email-masked]> wrote:

>  Hi,
>
> Sure, there may be a need to perform ICE restart for some other reasons,
> and my suggested text does not forbid it. But, I request a statement saying
> that an ICE restart is not required simply because you want to start
> sending data again.
>
> Perhaps:
>
> From experience I am pretty sure that, if we don't have explicit text, we
> will soon have do-I-need-to-do-ICE-restart mails on the list :)
>
> Regards,
>
> Christer
>
> To: Christer Holmberg <[email-masked]>
> Cc: Bernard Aboba <[email-masked]>; Martin Thomson
>  ​​

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Jun 2015 10:46:08 +0000

Looks ok. Thanks!

Regards,

Christer

Sent: ‎19/‎06/‎2015 12:53

   to perform ICE restart). As soon as the endpoint resumes sending application

thanks,
Muthu

On Fri, Jun 19, 2015 at 2:25 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Perhaps:

Regards,

Christer

New text:
​​

Would that work?

thanks,
Muthu

Thanks!

Regards,

Christer

Muthu

Otherwise, WFM.

s/test/text..

Correct.

Correct.

Correct.

​Existing test:

New test:

Does it work?

thanks,
Muthu

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 19 Jun 2015 15:53:03 +0200

> I am not talking about putting someone on hold, in which case you wouldn't send media on any candidate pair. I am talking about not sending media on candidate pairs X, Y and Z because you are sendi…

Correct me if I'm wrong, but once a final/definitive ICE path is
chosen and proven (so USE-CANCIDATE is used) there is no need at all
to keep all the other bindings open. In fact it is useless since once
a chosen path exists there is no way (according to current ICE spec)
to move to another one even if such a chosen path suddenly fails (that
requires indeed ICE restart, at least according to the current ICE
RFC).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Jun 2015 15:13:13 +0000

Hi,

>> I am not talking about putting someone on hold, in which case you wouldn't send media on any 
>> candidate pair. I am talking about not sending media on candidate pairs X, Y and Z because you are sending media on candidate pair W.
>
> Correct me if I'm wrong, but once a final/definitive ICE path is chosen and proven (so USE-CANCIDATE is used) there is no need at all to keep all 
> the other bindings open. In fact it is useless since once a chosen path exists there is no way (according to current ICE spec) to move to another one > even if such a chosen path suddenly fails (that requires indeed ICE restart, at least according to the current ICE RFC).

In recent moons people have been talking about never finalizing ICE, instead you will keep collecting candidates throughout the session, and switch between them if one is "better" than that other. You may drop some candidates, and you may maintain others (eventhough you are currently not sending any data on them).

That brings up a question, though: if you never finalize ICE, will you ever be able to do an ICE restart?

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 19 Jun 2015 12:00:09 -0400

On Jun 19, 2015, at 11:13 AM, Christer Holmberg <[email-masked]> wrote:
> 
> In recent moons people have been talking about never finalizing ICE, instead you will keep collecting candidates throughout the session, and switch between them if one is "better" than that other. You may drop some candidates, and you may maintain others (even though you are currently not sending any data on them)

[BA] A specific proposal is here:
https://tools.ietf.org/html/draft-uberti-mmusic-nombis

> That brings up a question, though: if you never finalize ICE, will you ever be able to do an ICE restart?

ICE can always be restarted, whether media is currently flowing or not.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Jun 2015 09:26:02 -0700

>    procedure described in this document.

This isn't right.  Consent has to be *reacquired* before sending.
This implies that you can use consent from earlier, even expired
consent.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Jun 2015 17:20:35 +0000

Hi,

>>   sending application data using the consent obtained earlier. As soon as the 
>>  endpoint resumes sending application data, consent is maintained following the
> This implies that you can use consent from earlier, even expired consent.

Good point.

I guess the text should say:

"When the endpoint wants to start sending data again, it first needs to re-obtain
consent, so it starts the sending of consent requests according to the procedures in this document
(the endpoint does not need to perform ICE restart in this case)."

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Jun 2015 10:25:00 -0700

> (the endpoint does not need to perform ICE restart in this case)."

Packet loss is going to be devastating to performance if you just
start checking again.  Should we also recommend (or allow) the use of
a STUN transaction to regain consent?

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Jun 2015 17:36:08 +0000

Hi,

You re-obtain consent using STUN.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Martin Thomson<mailto:[email-masked]>
Sent: ‎19/‎06/‎2015 20:25
To: Christer Holmberg<mailto:[email-masked]>
Cc: Muthu Arul Mozhi Perumal<mailto:[email-masked]>; Bernard Aboba<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Comment on consent-freshness-14

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Fri, 19 Jun 2015 23:49:51 +0530

But there would still be loss of application data for at least one RTT
before consent can be regained. Would that be devastating for video if the
initial packets sent after resumption contained the I-frame (for e.g, the
user turns off the camera and turns it on after a minute)?

Muthu

On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg <
[email-masked]> wrote:

> From: Martin Thomson <[email-masked]>
> Cc: Muthu Arul Mozhi Perumal <[email-masked]>; Bernard Aboba
> <[email-masked]>; [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 19 Jun 2015 18:47:36 +0000

Hi,

In order to avoid loss of data, you shall not start sending data until you have regained consent, similar to when the session was established.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Muthu Arul Mozhi Perumal<mailto:[email-masked]>
Sent: ‎19/‎06/‎2015 21:19
To: Christer Holmberg<mailto:[email-masked]>
Cc: Martin Thomson<mailto:[email-masked]>; Bernard Aboba<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Comment on consent-freshness-14

But there would still be loss of application data for at least one RTT before consent can be regained. Would that be devastating for video if the initial packets sent after resumption contained the I-frame (for e.g, the user turns off the camera and turns it on after a minute)?

Muthu

On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Sat, 20 Jun 2015 07:41:02 +0530

But unless the application starts sending data, consent will not be
regained, so it is a chicken-and-egg problem -:)

Some of the possible solutions:
- ICE restart -- too much of overhead and possible O/A race conditions,
don't like.
- Endpoint buffers the application data till consent is regained -- kluge,
don't like.
- Allow the endpoint to resume sending application data using the consent
it had when it stopped sending -- could open a backdoor, still don't like.
- Keep maintaining consent irrespective of whether application data is sent
or not -- simple, serves as a heartbeat in the absence of application data,
helps to keep NAT bindings alive and helps to refine RTT. The trade off is
some network bandwidth, but I think it is insignificant (some keepalives
would be sent anyway), so like it.

Muthu

On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg <
[email-masked]> wrote:

>  Hi,
>
> In order to avoid loss of data, you shall not start sending data until you
> have regained consent, similar to when the session was established.
>
> Regards,
>
> Christer
>
> Cc: Martin Thomson <[email-masked]>; Bernard Aboba

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 20 Jun 2015 00:58:33 -0400

Personally, I'm fine with requiring that consent be regained before sending.  This need not exact a performance penalty.

In make before break scenarios, consent can be regained first in the background before data is switched over to the revived candidate pair, so no buffering is needed. If there is a desire to have a "hot standby" so as to avoid buffering in break before make, then consent can be continued even when no data is being sent (what Justin's nombis draft proposes).  

However I do not see the need to mandate consent for pairs over which no data is sent in this document. Let us leave that decision to future documents in MMUSIC WG. 

> On Jun 19, 2015, at 10:11 PM, Muthu Arul Mozhi Perumal <[email-masked]> wrote:
> 
> But unless the application starts sending data, consent will not be regained, so it is a chicken-and-egg problem -:)
> 
> - ICE restart -- too much of overhead and possible O/A race conditions, don't like.
> - Endpoint buffers the application data till consent is regained -- kluge, don't like.
> - Allow the endpoint to resume sending application data using the consent it had when it stopped sending -- could open a backdoor, still don't like.
> - Keep maintaining consent irrespective of whether application data is sent or not -- simple, serves as a heartbeat in the absence of application data, helps to keep NAT bindings alive and helps to refine RTT. The trade off is some network bandwidth, but I think it is insignificant (some keepalives would be sent anyway), so like it.
> 
> Muthu
> 
>> On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg <[email-masked]> wrote:
>> Hi,
>> 
>> From: Muthu Arul Mozhi Perumal
>> To: Christer Holmberg
>> Cc: Martin Thomson; Bernard Aboba; [email-masked]
>>> On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg <[email-masked]> wrote:
>>> Hi,
>>> 
>>> From: Martin Thomson
>>> To: Christer Holmberg
>>> Cc: Muthu Arul Mozhi Perumal; Bernard Aboba; [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 20 Jun 2015 09:09:38 +0000

+1 to everything Bernard said.

It is perfectly ok to maintain consent, even if no application data is sent, e.g. if you want to have a “hot standby”.

Regards,

Christer

From: Bernard Aboba [mailto:[email-masked]]
Sent: 20 June 2015 07:59
To: Muthu Arul Mozhi Perumal
Cc: Christer Holmberg; Martin Thomson; <[email-masked]>
Subject: Re: [rtcweb] Comment on consent-freshness-14

On Jun 19, 2015, at 10:11 PM, Muthu Arul Mozhi Perumal <[email-masked]<mailto:[email-masked]>> wrote:
But unless the application starts sending data, consent will not be regained, so it is a chicken-and-egg problem -:)

Muthu

On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

Muthu

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 20 Jun 2015 09:13:22 +0000

Hi,

>But unless the application starts sending data, consent will not be regained, so it is a chicken-and-egg problem -:)

I don’t understand. You always have to (re)gain consent, using STUN, before you send application data. That’s the whole idea of the mechanism, and nothing that has been suggested here changes that.

And, as Bernard said, it is ok to maintain a “hot standby”. Or, if you know that you are going to start sending application data on a new candidate pair, you can regain consent while still sending application data on the previous candidate.

Regards,

Christer

Muthu

Regards,

Christer

Muthu

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 20 Jun 2015 12:53:48 +0200

On 06/20/2015 06:58 AM, Bernard Aboba wrote:
> Personally, I'm fine with requiring that consent be regained before 
> sending.  This need not exact a performance penalty.
>
> In make before break scenarios, consent can be regained first in the 
> background before data is switched over to the revived candidate pair, 
> so no buffering is needed. If there is a desire to have a "hot 
> standby" so as to avoid buffering in break before make, then consent 
> can be continued even when no data is being sent (what Justin's nombis 
> draft proposes).
>
> However I do not see the need to mandate consent for pairs over which 
> no data is sent in this document. Let us leave that decision to future 
> documents in MMUSIC WG.

+1.

It's currently technically unclear whether the advantages of running 
consent over "hot standby" candidate pairs (NATs stay up, consent is 
immediately and obviously available, continuous measurement of candiate 
pair performance) outweigh the disadvantages (overhead of running 
checks, need for picking sensible candidate pairs, risk of running 
useless hot standbys).

The document should not attempt to legislate that one or the other way 
is right, it should permit experimentation. Engineering will show which 
one gets deployed; once it's clear that all the developers have picked 
one way to do it, we can standardize on that.

>
>
> On Jun 19, 2015, at 10:11 PM, Muthu Arul Mozhi Perumal 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>> - Allow the endpoint to resume sending application data using the 
>> consent it had when it stopped sending -- could open a backdoor, 
>> still don't like.
>> - Keep maintaining consent irrespective of whether application data 
>> is sent or not -- simple, serves as a heartbeat in the absence of 
>> application data, helps to keep NAT bindings alive and helps to 
>> refine RTT. The trade off is some network bandwidth, but I think it 
>> is insignificant (some keepalives would be sent anyway), so like it.
>>
>> Muthu
>>
>> On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     Hi,
>>
>>     In order to avoid loss of data, you shall not start sending data
>>     until you have regained consent, similar to when the session was
>>     established.
>>
>>     Regards,
>>
>>     Christer
>>
>>     ------------------------------------------------------------------------
>>     From: Muthu Arul Mozhi Perumal <mailto:[email-masked]>
>>     To: Christer Holmberg <mailto:[email-masked]>
>>     Cc: Martin Thomson <mailto:[email-masked]>; Bernard
>>     Aboba <mailto:[email-masked]>; [email-masked]
>>     <mailto:[email-masked]>
>>     But there would still be loss of application data for at least
>>     one RTT before consent can be regained. Would that be devastating
>>     for video if the initial packets sent after resumption contained
>>     the I-frame (for e.g, the user turns off the camera and turns it
>>     on after a minute)?
>>
>>     Muthu
>>
>>     On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg
>>     <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>         Hi,
>>
>>         ------------------------------------------------------------------------
>>         From: Martin Thomson <mailto:[email-masked]>
>>         To: Christer Holmberg <mailto:[email-masked]>
>>         Cc: Muthu Arul Mozhi Perumal <mailto:[email-masked]>;
>>         Bernard Aboba <mailto:[email-masked]>;
>>         [email-masked] <mailto:[email-masked]>
>>         <[email-masked]
>>         <mailto:[email-masked]>> wrote:
>>         > consent, so it starts the sending of consent requests
>>         according to the procedures in this document

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Sun, 21 Jun 2015 00:25:59 +0530

On Sat, Jun 20, 2015 at 2:43 PM, Christer Holmberg <
[email-masked]> wrote:

> I don’t understand. You always have to (re)gain consent, using STUN,
> before you send application data. That’s the whole idea of the mechanism,
> and nothing that has been suggested here changes that.
>

​
The question is, how would the browser know that the application is about
to send data so that it can regain consent before the application data
arrives? Isn't the trigger for the browser to regain consent application
data itself?

I am however okay to keep it outside the scope of this document and figured
out elsewhere. It looks we don't to need change any text in the document
then. Perhaps, we could make it explicit that consent needs to be regained.

Current text:
   maintain consent.

New text:
   An endpoint that is not sending any application data after obtaining
   consent does not need to maintain consent, but the endpoint MUST regain
   consent before it resumes sending application data.

 Muthu
​

>
>
> And, as Bernard said, it is ok to maintain a “hot standby”. Or, if you
> know that you are going to start sending application data on a new
> candidate pair, you can regain consent while still sending application data
> on the previous candidate.
>

> - Keep maintaining consent irrespective of whether application data is
> sent or not -- simple, serves as a heartbeat in the absence of application
> data, helps to keep NAT bindings alive and helps to refine RTT. The trade
> off is some network bandwidth, but I think it is insignificant (some
> keepalives would be sent anyway), so like it.
>
>
>
> Muthu
>
>
>
> *From: *Muthu Arul Mozhi Perumal <[email-masked]>
> *Sent: *‎19/‎06/‎2015 21:19
> *To: *Christer Holmberg <[email-masked]>
> *Cc: *Martin Thomson <[email-masked]>; Bernard Aboba
> *Subject: *Re: [rtcweb] Comment on consent-freshness-14
>
> *From: *Martin Thomson <[email-masked]>
> *Sent: *‎19/‎06/‎2015 20:25
> *To: *Christer Holmberg <[email-masked]>
> *Cc: *Muthu Arul Mozhi Perumal <[email-masked]>; Bernard Aboba
> *Subject: *Re: [rtcweb] Comment on consent-freshness-14
>

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Sun, 21 Jun 2015 00:40:25 +0530

The -14 version seems to require hot standby already:

   A full ICE implementation obtains consent to send using ICE.  After a
   successful ICE connectivity check on a particular transport address
   (i.e., a candidate pair has been marked as Succeeded), consent MUST
   be maintained following the procedure described in this document.

Do we want to change that to?

   A full ICE implementation obtains consent to send using ICE.  After ICE

   concludes on a particular candidate pair consent MUST be maintained

   following the procedure described in this document.

Muthu

On Sat, Jun 20, 2015 at 4:23 PM, Harald Alvestrand <[email-masked]>
wrote:

> background before data is switched over to the revived candidate pair, so
> no buffering is needed. If there is a desire to have a "hot standby" so as
> to avoid buffering in break before make, then consent can be continued
> even when no data is being sent (what Justin's nombis draft proposes).
>
>  However I do not see the need to mandate consent for pairs over which no
> data is sent in this document. Let us leave that decision to future
> documents in MMUSIC WG.
>
>
> +1.
>
> pair performance) outweigh the disadvantages (overhead of running checks,
> need for picking sensible candidate pairs, risk of running useless hot
> standbys).
>
> The document should not attempt to legislate that one or the other way is
> right, it should permit experimentation. Engineering will show which one
> gets deployed; once it's clear that all the developers have picked one way
> to do it, we can standardize on that.
>
>
>
>> In order to avoid loss of data, you shall not start sending data until
>> you have regained consent, similar to when the session was established.
>>
>> Regards,
>>
>> Christer
>>
>>    But there would still be loss of application data for at least one
>> RTT before consent can be regained. Would that be devastating for video if
>> the initial packets sent after resumption contained the I-frame (for e.g,
>> the user turns off the camera and turns it on after a minute)?
>>
>>  Muthu
>>
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 20 Jun 2015 15:26:06 -0400

The trigger is the browser ICE implementation deciding which pair(s) to send data on.  So the browser doesn't have to anticipate app behavior for this issue to be relevant.

> On Jun 20, 2015, at 2:55 PM, Muthu Arul Mozhi Perumal <[email-masked]> wrote:
> 
>> On Sat, Jun 20, 2015 at 2:43 PM, Christer Holmberg <[email-masked]> wrote:
> 
>> Hi,
>> 
>>  
>> 
> ​The question is, how would the browser know that the application is about to send data so that it can regain consent before the application data arrives? Isn't the trigger for the browser to regain consent application data itself?
> 
> I am however okay to keep it outside the scope of this document and figured out elsewhere. It looks we don't to need change any text in the document then. Perhaps, we could make it explicit that consent needs to be regained.
> 
> Current text:

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 20 Jun 2015 15:27:26 -0400

You could add "until the browser decides to stop sending data on that pair."

> On Jun 20, 2015, at 3:10 PM, Muthu Arul Mozhi Perumal <[email-masked]> wrote:
> 
>> On Sat, Jun 20, 2015 at 4:23 PM, Harald Alvestrand <[email-masked]> wrote:
>> It's currently technically unclear whether the advantages of running     consent over "hot standby" candidate pairs (NATs stay up, consent is immediately and obviously available, continuous measurement of candiate pair performance) outweigh the disadvantages (overhead of running checks, need for picking sensible candidate pairs, risk of running useless hot standbys).
>> 
>> The document should not attempt to legislate that one or the other way is right, it should permit experimentation. Engineering will show which one gets deployed; once it's clear that all the developers have picked one way to do it, we can standardize on that.
>> 
>>> 
>>>

---

From: Martin Thomson <[email-masked]>
Date: Sat, 20 Jun 2015 12:42:50 -0700

> You could add "until the browser decides to stop sending data on that pair."

Though this is primarily for browsers, I'd prefer to avoid mentioning
them directly like that.  Though the addition is fine.

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 20 Jun 2015 16:02:20 -0400

Right. Using the term "ICE agent" might be better, for example.

> On Jun 20, 2015, at 3:42 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 20 Jun 2015 21:55:20 +0000

Perhaps "whenever the ICE agent sends data on that pair".

"Stop" may sound like the ICE agent will never again send data on that pair (which in some cases may be true, but not always).

Regards,

Christer

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Sun, 21 Jun 2015 11:14:17 +0530

That's true at the beginning of the session, but if the user mutes the
source during the session and the browser decides not to maintain consent
because no application data is being sent, it may have to rely on the
arrival of application data to regain consent, which can lead to packet
loss for at least one RTT..

Muthu

On Sun, Jun 21, 2015 at 12:56 AM, Bernard Aboba <[email-masked]>
wrote:

> The trigger is the browser ICE implementation deciding which pair(s) to
> send data on.  So the browser doesn't have to anticipate app behavior for
> this issue to be relevant.
>
>
>
> I am however okay to keep it outside the scope of this document and
> figured out elsewhere. It looks we don't to need change any text in the
> document then. Perhaps, we could make it explicit that consent needs to be
> regained.
>
> Current text:

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 21 Jun 2015 07:10:46 +0000

Hi,

I think a good implementation will always maintain consent on some pair(s), even if no application data I sent. Again, the suggestion is not to forbid that...

Regards,

Christer

Sent: ‎21/‎06/‎2015 08:44

That's true at the beginning of the session, but if the user mutes the source during the session and the browser decides not to maintain consent because no application data is being sent, it may have to rely on the arrival of application data to regain consent, which can lead to packet loss for at least one RTT..

Muthu

On Sun, Jun 21, 2015 at 12:56 AM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:
The trigger is the browser ICE implementation deciding which pair(s) to send data on.  So the browser doesn't have to anticipate app behavior for this issue to be relevant.

On Jun 20, 2015, at 2:55 PM, Muthu Arul Mozhi Perumal <[email-masked]<mailto:[email-masked]>> wrote:

On Sat, Jun 20, 2015 at 2:43 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

​
The question is, how would the browser know that the application is about to send data so that it can regain consent before the application data arrives? Isn't the trigger for the browser to regain consent application data itself?

Current text:

New text:

 Muthu
​

Regards,

Christer

Muthu

Regards,

Christer

Muthu

Regards,

Christer

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Sun, 21 Jun 2015 14:20:12 +0530

Agree, most of the implementations would do that. Perhaps, some
experimental/constrained implementation would do otherwise...

Muthu

On Sun, Jun 21, 2015 at 12:40 PM, Christer Holmberg <
[email-masked]> wrote:

>  Hi,
>
> I think a good implementation will always maintain consent on some
> pair(s), even if no application data I sent. Again, the suggestion is not
> to forbid that...
>
> Regards,
>
> Christer
>
>>> consent it had when it stopped sending -- could open a backdoor, still
>>> don't like.
>>>