Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-03.txt

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 2 Jun 2014 09:45:49 +0000

Hi Charles,

Thanks for the review. Will fix these in the next revision. Please see
inline

-----Original Message-----
From: "Charles Eckel   (eckelcu)" <[email-masked]>
Date: Wednesday, 21 May 2014 12:03 am
To: Ram Mohan Ravindranath <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [rtcweb] I-D Action:
draft-ietf-rtcweb-stun-consent-freshness-03.txt

>The updated draft looks good. I have some minor comments and a suggestion
>for the question/note in section 6.
>
>Section 1 reads as follows,
>"This document describes a new STUN usage with a request and response
>   messages which verifies the remote peer's consent to receive traffic,
>   and can also detect loss of liveness.²
>
>Suggested text corrects typos and reflects that the request/response
>verify liveness. Loss of liveless is detected as by other means, such as
>the expiration of a timer while waiting to receive a expected message.
>
>"This document describes a new STUN usage with exchange of request and
>response messages to verify the remote peer's consent to receive traffic,
>and the absence of which for a period of time indicates a loss of
>liveness.²

Will update

>
>Several places state "consent to send traffic². I think this is confusing.
>The consent is to receive traffic. Consent is provided by the receiver,
>and this consent is verified by the sender. For example, section 4.1 reads
>as follows, "Explicit consent to send is indicated by². This should read
>"Explicit consent to receive is indicated by², or "Explicit permission to
>send is obtained by². I prefer the former. If you agree, this should be
>changed in several places.

Agree that consent is for receiving traffic from a receivers perspective.
In this draft, we always talk about a sender of traffic sending a Consent
to its peer to send traffic.
So I feel from the senders perspective  “consent to send traffic” is right.

How about saying “Explicit consent to send is obtained"

>
>
>Section 5
>s/applications MUST NOT be able to send heartbeats faster than 1 per
>second/applications MUST
>   NOT send heartbeats at an average rate of more than 1 per second

Will fix this

>
>Section 6
>s/ICE connectivity check described/ICE connectivity checks described

Will fix this 

>
>As for the DSCP to use when media on transport addresses use multiple
>DSCPs, I assume this because the media streams having different
>priorities. That being the case, using the same DSCP for the STUN messages
>as that used for the highest priority media stream(s) seems appropriate.

<charles said>
I should have also stated that this would apply only for cases in which
such use of multiple DSCPs was appropriate, as determined by DART.
</charles>

 We did discuss this earlier and there was some support to use highest
priority DSCP in case of BUNDLE. Here was the previous thread -
http://www.ietf.org/mail-archive/web/rtcweb/current/msg11777.html
I did not see any conclusion though on that topic.

I am ok to have STUN packets to have highest DSCP when multiple DSCP
values are used for a given 5-tuple (like in DART). The only issue I see
is when there is a congestion then your STUN consent check packets would
get preference over some of the other packets. I think this is ok as
dropping a consent message means the sender is likely to stop sending
media itself,  if it does not see a consent refresh response.

I will add the following text. Does this look ok ?

"It is possible that different Diffserv Codepoints are used by
   different media over the same transport address as described in
   [I-D.ietf-tsvwg-rtcweb-qos].  In such cases, it is recommended to use
the same DSCP for the STUN messages
as that used for the highest priority media stream(s)."

Regards,
Ram

>
>Cheers,
>Charles
>
>
>On 5/19/14, 6:24 AM, "Ram Mohan R (rmohanr)" <[email-masked]> wrote:
>
>>The revision has text on
>>
>>1) Explaining how consent expires and is revoked (sections 4.1 and 4.2).
>>2) Added an example (non normative) implementation procedure.
>>
>>Comments are welcome
>>-Authors
>>
>>
>>-----Original Message-----
>>From: "[email-masked]" <[email-masked]>
>>Date: Monday, 19 May 2014 2:08 pm
>>To: "[email-masked]" <[email-masked]>
>>Cc: "[email-masked]" <[email-masked]>
>>Subject: [rtcweb] I-D Action:
>>draft-ietf-rtcweb-stun-consent-freshness-03.txt
>>
>>>
>>>A New Internet-Draft is available from the on-line Internet-Drafts
>>>directories.
>>> This draft is a work item of the Real-Time Communication in
>>>WEB-browsers
>>>Working Group of the IETF.
>>>
>>>        Title           : STUN Usage for Consent Freshness
>>>        Authors         : Muthu Arul Mozhi Perumal
>>>                          Dan Wing
>>>                          Ram Mohan Ravindranath
>>>                          Tirumaleswar Reddy
>>>                          Martin Thomson
>>>	Filename        : draft-ietf-rtcweb-stun-consent-freshness-03.txt
>>>	Pages           : 9
>>>	Date            : 2014-05-19
>>>
>>>Abstract:
>>>   To prevent sending excessive traffic to an endpoint, periodic consent
>>>   needs to be obtained from that remote endpoint.
>>>
>>>   This document describes a consent mechanism using a new STUN usage.
>>>   This same mechanism can also determine connection loss ("liveness")
>>>   with a remote peer.
>>>
>>>
>>>The IETF datatracker status page for this draft is:
>>>https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshnes
>>>s
>>>/
>>>
>>>There's also a htmlized version available at:
>>>http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-03
>>>
>>>A diff from the previous version is available at:
>>>http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshnes
>>>s
>>>-
>>>03
>>>
>>>
>>>Please note that it may take a couple of minutes from the time of
>>>submission
>>>until the htmlized version and diff are available at tools.ietf.org.
>>>
>>>Internet-Drafts are also available by anonymous FTP at:
>>>ftp://ftp.ietf.org/internet-drafts/
>>>
>>>_______________________________________________
>>>rtcweb mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>_______________________________________________
>>rtcweb mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 2 Jun 2014 11:43:21 -0700

> as that used for the highest priority media stream(s)."

I know that I haven't raised this point before, and I apologize for
not paying enough attention, but I don't think that we should be
talking about DSCP in this draft.

Use of DSCP with STUN and the additional complications that BUNGLE
adds are best dealt with in those contexts.  This was a simple
document, we should keep the scope constrained as much as possible.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 03 Jun 2014 13:52:46 +0200

> document, we should keep the scope constrained as much as possible.

I think having BUNDLE depend on consent-freshness would be a Bad Thing.

Probably the chairs should draw a tree of the various drafts and decide 
which draft can usefully say something about the relationship between 
RTP multiplexing (an -rtp- matter), DSCP (a -tsvwg- matter) and use of 
STUN (a -consent-freshness matter).

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 3 Jun 2014 12:12:00 +0000

Please see inline

-----Original Message-----
From: Harald Alvestrand <[email-masked]>
Date: Tuesday, 3 June 2014 5:22 pm
To: "[email-masked]" <[email-masked]>
Subject: Re: [rtcweb] I-D Action:

>STUN (a -consent-freshness matter).

We added this text in this document initially as we did not have any other
place holder.  All other STUN usage drafts (like ICE RFC) do have text
about DiffServ treatment and so we felt this draft also should talk about
DiffServ treatment for STUN consent freshness.  Consent freshness when
BUNDLE is used has dependency on other documents( BUNDLE draft, DART
draft) which are a work in progress. I agree having the text on consent
freshness for BUNDLE would make the scope of this draft larger and perhaps
slow the progress of this document.  I am ok to move the text related to
BUNDLE out of this draft but then it has to be put some where and linked
with consent freshness.

I will leave it to the Chairs to decide which is the best way forward for
this. 

Ram

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Jun 2014 10:17:19 -0700

On 3 June 2014 05:12, Ram Mohan R (rmohanr) <[email-masked]> wrote:
> I agree having the text on consent
> slow the progress of this document.

The concern is not that there is consent freshness for BUNDLE, it's
that there is DiffServ marking for BUNDLE.  BUNDLE should determine
that (or maybe some other document).  Whatever this document does
should - at most - say that the marking is the same for consent
refresh as it is for initial connectivity checking.

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 3 Jun 2014 17:31:56 +0000

|-----Original Message-----
|From: rtcweb [mailto:[email-masked]] On Behalf Of Martin Thomson
|Sent: Tuesday, June 03, 2014 10:47 PM
|To: Ram Mohan R (rmohanr)
|Cc: [email-masked]
|Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-03.txt
|
|On 3 June 2014 05:12, Ram Mohan R (rmohanr) <[email-masked]> wrote:
|> I agree having the text on consent
|> freshness for BUNDLE would make the scope of this draft larger and perhaps
|> slow the progress of this document.
|
|
|The concern is not that there is consent freshness for BUNDLE, it's
|that there is DiffServ marking for BUNDLE.  BUNDLE should determine
|that (or maybe some other document).  Whatever this document does
|should - at most - say that the marking is the same for consent
|refresh as it is for initial connectivity checking.

That is close to what the draft currently says:

   It is RECOMMENDED that STUN consent checks use the same Diffserv
   Codepoint markings as the media packets sent on that transport
   address.  This follows the recommendation of ICE connectivity check
   described in section 7.1.2.4 of [RFC5245].

Of course, we can replace media packets with ICE connectivity check, if needed. In addition, we can add a node that the BUNDLE case is out of scope of this document.

Muthu

|
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 3 Jun 2014 17:32:27 +0000

-----Original Message-----
From: Martin Thomson <[email-masked]>
Date: Tuesday, 3 June 2014 10:47 pm
To: Ram Mohan Ravindranath <[email-masked]>
Cc: Harald Alvestrand <[email-masked]>, "[email-masked]"
<[email-masked]>

>refresh as it is for initial connectivity checking.

Agree. Instead of saying pick up highest DSCP value or lowest DSCP value
from the media stream(s) in the BUNDLE for STUN consent messages, we could
just say the DiffServ marking for STUN consent messages is same that is
for initial ICE checks. I believe DiffServ marking for initial ICE checks
when BUNDLE is used is itself a open item and not defined in any draft yet.

Ram