Subject: [tram] WGLC draft-ietf-tram-stun-path-data-01

From: Simon Perreault <[email-masked]>
Date: Tue, 22 Sep 2015 08:23:41 -0400

TRAMsters,

This email initiates a two-week working-group last call on this draft:

http://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/

Please read it now. Substantial comments should be addressed to the
group. Nits should be sent directly to the authors.

Thanks,
Simon & Gonzalo

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 24 Sep 2015 17:18:17 +0000

Hello Authors,

I read the draft and it looks good. A few comments below. I have few nits
that will send to authors directly.

1)The Introduction talks about how the PATH-CHARACTERISTICS attribute
defined by this draft can be used by ICE regular nomination and continuous
nomination.
Would it make sense to look at how this would work with Consent Freshness
?  Especially the implications this new attribute will have on the Section
5.1 procedures of Consent
Freshness in 
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/?
include_text=1

2) All the procedures described in this draft should work if the peer is
ICE-lite as well. The ICE-lite endpoint should still respond to the Bind
Req and 
 should echo the ReTransCnt and increment RespTransCnt(if its state-full).
Perhaps you can add a note some where in the introduction that this
will work even if the peer is ICE-lite.

3)Section 3
"If a client wishes to determine the path characteristics, it inserts
   the PATH-CHARACTERISTIC attribute in a STUN request²

Perhaps you can explicitly say that the new STUN attribute will be before
the MESSAGE-INTEGRITY attribute

4)Would it be worth to give an example on what would happen for the case
where the request from a STUN client arrives out of order ? For e.g; the
STUN client sends a request
with ReTransCnt 1 and after some time re-transmits with ReTransCnt 2. Now
the Server first receives the message with ReTransCnt 2 and then it
receives the message with ReTransCnt 1

Thanks,
Ram

-----Original Message-----
From: tram <[email-masked]> on behalf of Simon Perreault
<[email-masked]>
Date: Tuesday, 22 September 2015 5:53 pm
To: "[email-masked]" <[email-masked]>
Subject: [tram] WGLC draft-ietf-tram-stun-path-data-01

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 26 Sep 2015 16:38:52 +0000

Hi Ram,

Thanks for the comments, Please see inline

> From: tram [mailto:[email-masked]] On Behalf Of Ram Mohan R
> (rmohanr)
> Sent: Thursday, September 24, 2015 10:48 PM
> To: Simon Perreault; [email-masked]
> Subject: Re: [tram] WGLC draft-ietf-tram-stun-path-data-01
> 
> Hello Authors,
> 

Consent checks are initiated after the candidates for media streams are selected by the ICE algorithm. 
What is the benefit of using PATH-CHARACTERISTICS attribute with consent checks ?

> 
> 2) All the procedures described in this draft should work if the peer is ICE-lite
> as well. The ICE-lite endpoint should still respond to the Bind Req and  should
> echo the ReTransCnt and increment RespTransCnt(if its state-full).
> Perhaps you can add a note some where in the introduction that this will
> work even if the peer is ICE-lite.

Remote peer could support full or lite ICE, ICE lite endpoint will respond to STUN requests with or without PATH-CHARACTERISTC attribute. 
I am not sure why ICE-lite needs to be discussed in this doc ?

> Perhaps you can explicitly say that the new STUN attribute will be before the
> MESSAGE-INTEGRITY attribute

As per RFC5389, any attribute (other than fingerprint) after MI will be ignored by the receiver. I don't see a need to explicitly mention that this new attribute has to be placed before MI.

> where the request from a STUN client arrives out of order ? For e.g; the STUN
> client sends a request with ReTransCnt 1 and after some time re-transmits
> with ReTransCnt 2. Now the Server first receives the message with
> ReTransCnt 2 and then it receives the message with ReTransCnt 1

Adding the following lines to Section 3.3:
Another example could be the client sends two requests but the second request arrives at the server before the first request because of out of order delivery then the stateful server populates value 1 for the RespTransCnt field in PATH-CHARACTERISTIC attribute sent in response to the second request and value 2 for the RespTransCnt field in PATH-CHARACTERISTIC attribute sent in response to the first request.

-Tiru

---

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

Hi Tiru,

Please see inline

-----Original Message-----
From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Saturday, 26 September 2015 10:08 pm
To: Cisco Employee <[email-masked]>, Simon Perreault
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [tram] WGLC draft-ietf-tram-stun-path-data-01

>What is the benefit of using PATH-CHARACTERISTICS attribute with consent

I don’t see any harm in sending PATH-CHARACTERISTCIS in Binding Request
messages even after initial ICE is concluded. These include Consent
messages which are sent periodically after ICE concludes.
For e.g; Endpoints can use PATH-CHARATERISTICS in Binding Requests sent
for Consent to also learn RTT changes(if any) in the selected path. This
in turn can be used by applications like MPRTP to select
alternate paths.

>Remote peer could support full or lite ICE, ICE lite endpoint will
>respond to STUN requests with or without PATH-CHARACTERISTC attribute.

Correct. It may be useful mentioning that point - that remote peer can be
full or ICE-lite some where in the document (perhaps introduction).

>As per RFC5389, any attribute (other than fingerprint) after MI will be
>ignored by the receiver. I don't see a need to explicitly mention that
>this new attribute has to be placed before MI.

Ok Fine

>Another example could be the client sends two requests but the second
>request arrives at the server before the first request because of out of
>order delivery then the stateful server populates value 1 for the
>RespTransCnt field in PATH-CHARACTERISTIC attribute sent in response to
>the second request and value 2 for the RespTransCnt field in
>PATH-CHARACTERISTIC attribute sent in response to the first request.

Looks good. You can split the sentence in to two sentences as it looks bit
long.

Regards,
Ram