Subject: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness-05

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Jul 2014 21:59:18 -0400

Some comments from reading the latest version:

Introduction:

    WebRTC endpoints are required to support full ICE as specified in
    section 3.4 of [I-D.ietf-rtcweb-transports].  However, when WebRTC
    endpoints interwork with other endpoints that support only ICE-lite
    (e.g. gateways) those endpoints will not generate consent checks, but
    just respond to consent checks they receive.

Having just read the overview document, I question the terminology 
above. The following would be more consistent with the overview:

    WebRTC browsers are required to support full ICE as specified in
    section 3.4 of [I-D.ietf-rtcweb-transports].  However, when WebRTC
    browsers interwork with other WebRTC devices that support only
    ICE-lite (e.g. gateways) those endpoints will not generate consent
    checks, but just respond to consent checks they receive.

or perhaps you mean:

    WebRTC devices are required to support full ICE as specified in
    section 3.4 of [I-D.ietf-rtcweb-transports].  However, when WebRTC
    devices interwork with other endpoints that support only ICE-lite
    (e.g. gateways) those endpoints will not generate consent checks, but
    just respond to consent checks they receive.

Section 4.1:

    ...  To prevent expiry of consent, a STUN binding
    request is sent every N milliseconds, where N SHOULD be 5000
    milliseconds and MUST be randomized at least 20% above and 20% below
    that value (to prevent prevent network synchronization).  Using the
    value 5000 milliseconds and that 20% randomization range, N would be
    a value between 4000 and 6000.  ...

The normative requirement is weird here. (I MUST do the randomization, 
but that forces me to violate the SHOULD.) Do you mean the central value 
SHOULD be 5000, but in the case that it is some other value then the 
range should be from 20% below to 20% above that value? Would that 20% 
be appropriate if I changed N to 500 or 50000? Also, is the 
randomization to be done once for the session, or repeated for each 
consent request that is sent?

I think the following gives the same rule in an easier to understand way:

    ...  To prevent expiry of consent, a STUN binding request MUST be
    every N milliseconds, where N is chosen randomly in the interval
    [.8N, 1.2N] (to prevent prevent network synchronization), where N
    SHOULD be 5000.  Using the value 5000 milliseconds and that 20%
    randomization range, N would be a value between 4000 and 6000.  ...

Note this is equivalent to [N, 1.5N] with the recommended value of N 
changed to 4000. That might be easier.

(And, if I remember my math, it would be more proper to write the 
interval as "[N, 1.5N)". But that may be disturbing to programmers. As a 
programmer I'd more likely write "[N, int(1.5N)-1]", but that is ugly in 
text.)

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Jul 2014 19:19:44 -0700

>    just respond to consent checks they receive.

Yes, this.

>    a value between 4000 and 6000.  ...

We've just discussed this particular point and concluded that the
randomization requirement isn't necessary, since there is no need for
any sort of lock step avoidance in a peer-to-peer system like this.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Jul 2014 23:17:13 -0400

>>     just respond to consent checks they receive.

OK.

> any sort of lock step avoidance in a peer-to-peer system like this.

Will these two be covered in -06?

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Jul 2014 20:27:48 -0700

> Will these two be covered in -06?

I should have said, this was a Mozilla discussion, not a co-author
discussion.  And fairly fresh.  I hope so.

---

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 23 Jul 2014 13:21:34 +0000

Hi Martin, Paul, Harald, Andy,

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of ext Paul
> Kyzivat
> Sent: Thursday, July 17, 2014 11:17 PM
> To: Martin Thomson
> Cc: [email-masked]
> Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-
> freshness-05
> 

This ("WebRTC devices MUST support full ICE") contradicts with another exchange on the mailing list:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg12554.html  
------------------
> Section 4 [of -overview, U.R.] now states "WebRTC devices MUST implement the transport protocols described in [I-D.ietf-rtcweb-transports]"
>
>  
> This might be a comment on -transports- more than -overview- but section 3.4 of transports states that "The implementation MUST be a full ICE implementation, not ICE-Lite". This is however not true for "WebRTC devices" only for "WebRTC browsers" since ICE-Lite is sufficient for "WebRTC devices".

Good point. -transports- was last updated before I invented "WebRTC devices", it uses "devices" and "browsers" interchangeably.

Will make them consistent next round, if WG signs off on the split.
------------------

This discussion hints at that we still have no clear understanding of what a WebRTC device is. Does this class include gateways or not?

In other discussions on this list, there was no opposition against the fact that gateways are OK with supporting ICE Lite only.

The question we have to answer is whether gateways are WebRTC devices. This would imply that there may be different flavours of WebRTC devices (such as at least native apps and gateways) and these flavours differ in some properties (such as ICE support). Alternatively, we could mention WebRTC gateways as a third category in -overview. 

Kind regards,
Uwe