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

[Harald Alvestrand <[e-mail]>]

On 09/25/2014 12:25 PM, Christer Holmberg wrote:
>
> 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.
>
> ​ 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”.
>
> 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
>
>     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:[e-mail]
>     <mailto:[e-mail]>]
>     *Sent:* 25 September 2014 12:22
>     *To:* Christer Holmberg
>     *Cc:* [e-mail] <mailto:[e-mail]>
>     *Subject:* Re: [rtcweb] Consent Freshness: Some suggestions for
>     editorial clarifications
>
>     On Thu, Sep 25, 2014 at 2:02 PM, Christer Holmberg
>     <[e-mail]
>     <mailto:[e-mail]>> 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
>             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.
>
>         ​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.
>
>         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
>
>
>             _______________________________________________
>             rtcweb mailing list
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb