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

Hi Christer,

On Thu, Sep 25, 2014 at 3:32 PM, Christer Holmberg <
christer.holmberg@ericsson.com> 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..

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:muthu.arul@gmail.com]
> *Sent:* 25 September 2014 12:22
> *To:* Christer Holmberg
> *Cc:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] Consent Freshness: Some suggestions for editorial
> clarifications
>
>
>
> On Thu, Sep 25, 2014 at 2:02 PM, Christer Holmberg <
> christer.holmberg@ericsson.com> 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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
>