Subject: [rtcweb] Consent Freshness: Some suggestions for editorial clarifications

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 Sep 2014 07:41:29 +0000

Hi,

Based on feedback I receive from implementers, there are a couple of clarifications I think would be useful in the consent freshness draft.

Q1:
-----

As STUN binding requests for consent are sent unreliably, and are not re-transmitted, I think it would be useful to have some explicit text saying that individual requests (and/or their associated responses) may get lost in the network, and that a sender must be prepared that a response to such requestmay never arrive.

It may be obvious to us, but maybe not as clear to the first-time reader of the draft.

Q2:
-----

Section 4.1 says:

"That is, if a valid STUN binding response corresponding to one of the STUN requests sent in the last 30 seconds
                has not been received from the remote peer's Transport Address, the endpoint MUST cease transmission on that 5-tuple."

First, I suggest the following clarification:

s/"to one of the STUN requests sent in the last 30 seconds"/"to one of the STUN requests (not necessarily the last one) sent in the last 30 seconds".

Second, there is no explicit text on for how long the client keeps the STUN transaction alive, i.e. for how long it waits for the response.

I assume that, after 30 seconds, the client does not need to maintain state and wait for the response anymore. I think it would be useful to explicitly indicate that, and also say that responses that are received after that time must be discarded.

Thanks!

Regards,

Christer

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 22 Sep 2014 04:33:42 +0000

Hi Christer,

Please see inline

>
>
>From:  Christer Holmberg <[email-masked]>
>Date:  Wednesday, 17 September 2014 1:11 pm
>To:  "[email-masked]" <[email-masked]>
>Subject:  [rtcweb] Consent Freshness: Some suggestions for
>editorial	clarifications
>
>
>Hi,
> 
>Based on feedback I receive from implementers, there are a couple of
>clarifications I think would be useful in the consent freshness draft.
> 
> 
> 
>Q1:
>-----
> 
>As STUN binding requests for consent are sent unreliably, and are not
>re-transmitted, I think it would be useful to have some explicit text
>saying that individual requests (and/or their associated responses) may
>get lost in the network,
> and that a sender must be prepared that a response to such requestmay
>never arrive.
> 

This depends on the underlying transport used. If its UDP as you said its
unreliable. For other transports it is not the case. So I don’t see a need
to add any text in this draft.
> 
> 
> 
> 
>Q2:
>-----
> 
>Section 4.1 says:
> 
>³That is, if a valid STUN binding response corresponding to one of the
>STUN requests sent in the last 30 seconds
>                has not been received from the remote peer's Transport
>Address, the endpoint MUST cease transmission on that 5-tuple.²
> 
>s/²to one of the STUN requests sent in the last 30 seconds²/²to one of the
>STUN requests (not necessarily the last one) sent in the last 30 seconds².

Will update this in the next revision.

> 
> 
>Second, there is no explicit text on for how long the client keeps the
>STUN transaction alive, i.e. for how long it waits for the response.
> 
>I assume that, after 30 seconds, the client does not need to maintain
>state and wait for the response anymore. I think it would be useful to
>explicitly indicate that, and also say that responses that are received
>after that time must be
> discarded.

Ok. Will mention that any responses received after 30 secs will be
discarded.

Regards,
Ram

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Sep 2014 04:41:55 +0000

Hi,

>>Q1:
>>-----
>> 
>>As STUN binding requests for consent are .sent unreliably, and are not 
>>get lost in the network,  and that a sender must be prepared that a 
>>response to such requestmay never arrive.
>> 
>This depends on the underlying transport used. If its UDP as you said its unreliable. For other >transports it is not the case. So I don't see a need to add any text in this draft.

I still think text would be useful (I have received questions about this). 

So, you could say: "If an unreliable transport is used,..."

>> ...
>>after that time must be  discarded.
>
> Ok. Will mention that any responses received after 30 secs will be discarded.

I think it needs to be more than a "mention" :) The STUN transaction state machine needs to be clear to implementers.

Regards,

Christer

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Thu, 25 Sep 2014 13:49:00 +0530

Hi Christer,

On Wed, Sep 17, 2014 at 1:11 PM, Christer Holmberg <
[email-masked]> wrote:

> saying that individual requests (and/or their associated responses) may get
> lost in the network, and that a sender must be prepared that a response to
> such requestmay never arrive.
>
>
>
> “That is, if a valid STUN binding response corresponding to one of the
> Address, the endpoint MUST cease transmission on that 5-tuple.”
>
>
>
> s/”to one of the STUN requests sent in the last 30 seconds”/”to one of the
> STUN requests (not necessarily the last one) sent in the last 30 seconds”.
>
>
>
>
>
> state and wait for the response anymore.
>

​My understanding is that the sender doesn't need remember the request for
30 sec, instead it needs to remember it only for RTT duration. If a
matching response is received within that duration you have a 'hit'. If
there is no 'hit' over the last 30 sec, consent expires.

I agree this isn't clear in the current version.

Muthu

I think it would be useful to explicitly indicate that, and also say that
> responses that are received after that time must be discarded.
>
>
>
> Thanks!
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Sep 2014 08:32:20 +0000

Hi,

Q1:
-----

Q2:
-----

Section 4.1 says:

“That is, if a valid STUN binding response corresponding to one of the STUN requests sent in the last 30 seconds
                has not been received from the remote peer's Transport Address, the endpoint MUST cease transmission on that 5-tuple.”

s/”to one of the STUN requests sent in the last 30 seconds”/”to one of the STUN requests (not necessarily the last one) sent in the last 30 seconds”.

I assume that, after 30 seconds, the client does not need to maintain state and wait for the response anymore.

​My understanding is that the sender doesn't need remember the request for 30 sec, instead it needs to remember it only for RTT duration. If a matching response is received within that duration you have a 'hit'. If there is no 'hit' over the last 30 sec, consent expires.

How do you calculate the RTT? Based on previous transactions? What if, for whatever reason, the roundtrip for a STUN binding request/response takes longer that previously? You would discard the response.

I think it is much more clear the specify a time. 30 seconds is a good value, because if it takes longer the response is “unvalid” anyway.

Regards,

Christer

I think it would be useful to explicitly indicate that, and also say that responses that are received after that time must be discarded.

Thanks!

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: Thu, 25 Sep 2014 14:52:17 +0530

On Thu, Sep 25, 2014 at 2:02 PM, Christer Holmberg <
[email-masked]> wrote:

> How do you calculate the RTT? Based on previous transactions?
>

​I should have said smoothed RTT. ​I believe that is what STUN and TCP
currently use.

> What if, for whatever reason, the roundtrip for a STUN binding
> request/response takes longer that previously? You would discard the
> response.
>

​Yes, but that shouldn't a problem for consent I think, because only if
there was no 'hit' over the last 30 sec would consent expire.

>
>
> I think it is much more clear the specify a time. 30 seconds is a good
> value, because if it takes longer the response is “unvalid” anyway.
>

​I am okay with a fixed duration instead of a smoothed RTT. However, 30 sec
looks too long to me to remember the request, holding unnecessary resources
(we just need one matching response over the last 30 sec).

The other question is, do we really need to specify the duration to achieve
interoperability here? I though Martin's opinion was that isn't needed to
achieve interoperability, but I could have misread one of those
discussions..

Muthu

>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
>  I think it would be useful to explicitly indicate that, and also say
> that responses that are received after that time must be discarded.
>
>
>
> Thanks!
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Sep 2014 10:02:28 +0000

Hi,

The reason for 30 seconds is the following:

As we know, the sender needs to receive at least one response to a request sent within the last 30 seconds, or the consent expires.

Assume you send a STUN request at time X, another one at time X+n etc.

Now, within the 30 seconds, assume the only response (all other requests/responses get lost in the network) you get is to the request you sent at time X, and you receive it 28 seconds after you sent the request.

Therefore, unless you wait for the response 30 seconds,  consent will expire – EVEN if you did receive a response within 30 seconds.

I do agree it very likely won’t happen in real life, but our state machines etc should be able to handle the “worst case” scenario.

Regards,

Christer

From: Muthu Arul Mozhi Perumal [mailto:[email-masked]]
Sent: 25 September 2014 12:22
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [rtcweb] Consent Freshness: Some suggestions for editorial clarifications

On Thu, Sep 25, 2014 at 2:02 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
Based on feedback I receive from implementers, there are a couple of clarifications I think would be useful in the consent freshness draft.

Q1:
-----

Q2:
-----

Section 4.1 says:

​I should have said smoothed RTT. ​I believe that is what STUN and TCP currently use.

What if, for whatever reason, the roundtrip for a STUN binding request/response takes longer that previously? You would discard the response.

​Yes, but that shouldn't a problem for consent I think, because only if there was no 'hit' over the last 30 sec would consent expire.

​I am okay with a fixed duration instead of a smoothed RTT. However, 30 sec looks too long to me to remember the request, holding unnecessary resources (we just need one matching response over the last 30 sec).

The other question is, do we really need to specify the duration to achieve interoperability here? I though Martin's opinion was that isn't needed to achieve interoperability, but I could have misread one of those discussions..

Muthu

Regards,

Christer

Thanks!

Regards,

Christer

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Thu, 25 Sep 2014 15:50:20 +0530

Hi Christer,

On Thu, Sep 25, 2014 at 3:32 PM, Christer Holmberg <
[email-masked]> wrote:

> As we know, the sender needs to receive at least one response to a request
> sent within the last 30 seconds, or the consent expires.
>
>
>
> Now, within the 30 seconds, assume the only response (all other
> requests/responses get lost in the network) you get is to the request you
> sent at time X, and you receive it 28 seconds after you sent the request.
>

​But it is unlikely that someone will buffer the response for 28 sec. If
the connectivity was lost for so long, the response to the first request
would have also got lost..

Muthu
​

>
>
> Therefore, unless you wait for the response 30 seconds,  consent will
> expire – EVEN if you did receive a response within 30 seconds.
>
>
>
> I do agree it very likely won’t happen in real life, but our state
> machines etc should be able to handle the “worst case” scenario.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
> *From:* Muthu Arul Mozhi Perumal [mailto:[email-masked]]
> *Sent:* 25 September 2014 12:22
> *To:* Christer Holmberg
> *Cc:* [email-masked]
> *Subject:* Re: [rtcweb] Consent Freshness: Some suggestions for editorial
> clarifications
>
>
>
> ​I am okay with a fixed duration instead of a smoothed RTT. However, 30
> sec looks too long to me to remember the request, holding unnecessary
> resources (we just need one matching response over the last 30 sec).
>
>
>
> The other question is, do we really need to specify the duration to
> achieve interoperability here? I though Martin's opinion was that isn't
> needed to achieve interoperability, but I could have misread one of those
> discussions..
>
>
>
> Muthu
>
>
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Sep 2014 10:25:17 +0000

Hi,

​But it is unlikely that someone will buffer the response for 28 sec. If the connectivity was lost for so long, the response to the first request would have also got lost..

Unlikely, yes. But, if it happens, and consent expires (because the sender did not wait for 30 seconds), who to blame?

The sender will say “you buffered the response too long”, and the receiver will say “you did get the response within 30 seconds”.

I am trying to avoid such situations, because both parties will say that they implement the draft correctly.

Of course, if you send a request at time X, and another one at time X+N, if you get a response to the X+N request you can terminate the state for the X request also.

So, in reality, I doubt there will be cases where the state lives for 30 seconds.

Regards,

Christer

Regards,

Christer

From: Muthu Arul Mozhi Perumal [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 25 September 2014 12:22
To: Christer Holmberg
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Consent Freshness: Some suggestions for editorial clarifications

Q1:
-----

Q2:
-----

Section 4.1 says:

Muthu

Regards,

Christer

Thanks!

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 26 Sep 2014 10:30:52 +0200

On 09/25/2014 12:25 PM, Christer Holmberg wrote:
>     As we know, the sender needs to receive at least one response to a
>     request sent within the last 30 seconds, or the consent expires.
>
>     requests/responses get lost in the network) you get is to the
>     request you sent at time X, and you receive it 28 seconds after
>     you sent the request.
>
> ​ But it is unlikely that someone will buffer the response for 28 sec. 
> If the connectivity was lost for so long, the response to the first 
> request would have also got lost..
>

I think people who have experimented with the "walk behind a tree" 
scenario in 3G networks have reported seeing packets delayed for 10 
seconds in real networks.

Of course, if you send requests at X, X+5, X+10, X+15 and so on, you're 
likely to get the one at X+15 as well as the one at X once connectivity 
resumes.

Experimentation would be good here....

> Unlikely, yes. But, if it happens, and consent expires (because the 
> sender did not wait for 30 seconds), who to blame?
>
> The sender will say “you buffered the response too long”, and the 
> receiver will say “you did get the response within 30 seconds”.
>
> Of course, if you send a request at time X, and another one at time 
> X+N, if you get a response to the X+N request you can terminate the 
> state for the X request also.
>
>     Therefore, unless you wait for the response 30 seconds,  consent
>     will expire – EVEN if you did receive a response within 30 seconds.
>
>     *From:*Muthu Arul Mozhi Perumal [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [rtcweb] Consent Freshness: Some suggestions for
>     editorial clarifications
>
>     On Thu, Sep 25, 2014 at 2:02 PM, Christer Holmberg
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Hi,
>
>             Based on feedback I receive from implementers, there are a
>             couple of clarifications I think would be useful in the
>             consent freshness draft.
>
>             Q1:
>
>             -----
>
>             As STUN binding requests for consent are sent unreliably,
>             and are not re-transmitted, I think it would be useful to
>             have some explicit text saying that individual requests
>             (and/or their associated responses) may get lost in the
>             network, and that a sender must be prepared that a
>             “That is, if a valid STUN binding response corresponding
>             to one of the STUN requests sent in the last 30 seconds
>
>                          has not been received from the remote peer's
>             Transport Address, the endpoint MUST cease transmission on
>             that 5-tuple.”
>
>             s/”to one of the STUN requests sent in the last 30
>             seconds”/”to one of the STUN requests (not necessarily the
>             last one) sent in the last 30 seconds”.
>
>             Second, there is no explicit text on for how long the
>             client keeps the STUN transaction alive, i.e. for how long
>             it waits for the response.
>
>             I assume that, after 30 seconds, the client does not need
>             to maintain state and wait for the response anymore.
>
>         ​My understanding is that the sender doesn't need remember the
>         request for 30 sec, instead it needs to remember it only for
>         RTT duration. If a matching response is received within that
>         duration you have a 'hit'. If there is no 'hit' over the last
>         30 sec, consent expires.
>
>         request/response takes longer that previously? You would
>         discard the response.
>
>     ​Yes, but that shouldn't a problem for consent I think, because
>     only if there was no 'hit' over the last 30 sec would consent expire.
>
>         I think it is much more clear the specify a time. 30 seconds
>         is a good value, because if it takes longer the response is
>         “unvalid” anyway.
>
>     ​I am okay with a fixed duration instead of a smoothed RTT.
>     However, 30 sec looks too long to me to remember the request,
>     holding unnecessary resources (we just need one matching response
>     over the last 30 sec).
>
>     The other question is, do we really need to specify the duration
>     to achieve interoperability here? I though Martin's opinion was
>     that isn't needed to achieve interoperability, but I could have
>     misread one of those discussions..
>
>     Muthu
>
>         Regards,
>
>         Christer
>
>             I think it would be useful to explicitly indicate that,
>             and also say that responses that are received after that
>             time must be discarded.
>
>             Thanks!
>
>             Regards,
>
>             Christer
>
>
>             [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Sep 2014 09:11:36 +0000

Hi,

​ But it is unlikely that someone will buffer the response for 28 sec. If the connectivity was lost for so long, the response to the first request would have also got lost..

I think people who have experimented with the "walk behind a tree" scenario in 3G networks have reported seeing packets delayed for 10 seconds in real networks.

Of course, if you send requests at X, X+5, X+10, X+15 and so on, you're likely to get the one at X+15 as well as the one at X once connectivity resumes.

Correct, that may happen (depending on what caused the delay).

But, again, once you get the X+15, you don’t need to wait for the previous ones (X, X+5 etc) any more. You can throw away the state, and simply discard them when/if they arrive.

Regards,

Christer

Regards,

Christer

Regards,

Christer

Q1:
-----

Q2:
-----

Section 4.1 says:

Muthu

Regards,

Christer

Thanks!

Regards,

Christer

rtcweb mailing list

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Fri, 26 Sep 2014 12:34:27 +0000

I think people who have experimented with the "walk behind a tree" scenario in 3G networks have reported seeing packets delayed for 10 seconds in real networks.
[Raju] Right. Huge delays can “naturally” happen without trees/obstruction being involved; in some cases, when a user moves between cells it could produce such huge delays. We noticed that it can even happen with 4G.

BR
Raju