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

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sat, 3 Oct 2015 05:49:59 +0000

Inline

-----Original Message-----
From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Monday, 28 September 2015 9:46 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

>> -----Original Message-----
>> From: Ram Mohan R (rmohanr)
>> Sent: Monday, September 28, 2015 10:08 AM
>> To: Tirumaleswar Reddy (tireddy); Simon Perreault; [email-masked]
>> Subject: Re: [tram] WGLC draft-ietf-tram-stun-path-data-01
>> 
>> 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
>> 
>> >Hi Ram,
>> >
>> >Thanks for the comments, Please see inline
>> >
>> >> -----Original Message-----
>> >> 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,
>> >>
>> >> 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-freshn
>> >>ess
>> >>/?
>> >> include_text=1
>> >
>> >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 ?
>> 
>> 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.
>
>MPRTCP provides path characteristics per sub-flow.

Sure. MPRTCP is sufficient. Including PATH-CHARACTERISTICS in Consent
(which is also sent periodically between 4 - 6 secs) also can be used
as a indicator to learn the RTT and can be used by MPRTP. That said I will
leave it to you to whether you want to add a note in draft.

I am fine either ways.

Regards,
Ram

>I am not sure why PATH-CHARATERISTICS is useful 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.
>> 
>> Correct. It may be useful mentioning that point - that remote peer can
>>be full
>> or ICE-lite some where in the document (perhaps introduction).
>
>Both full and lite modes don't need any special mention in this doc,
>remote peer supporting lite or full ICE will respond to STUN binding
>request with PATH-CHARACTERISTC attribute.
>
>> 
>> >
>> >I am not sure why ICE-lite needs to be discussed in this doc ?
>> >
>> >>
>> >> 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
>> >
>> >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
>> 
>> >
>> >>
>> >> 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
>> >
>> >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.
>> 
>> Looks good. You can split the sentence in to two sentences as it looks
>>bit
>> long.
>
>Updated.
>
>-Tiru
>
>> 
>> Regards,
>> Ram
>> 
>> >
>> >-Tiru
>> >
>> >>
>> >>
>> >> 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
>> >>
>> >> >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
>> >> >
>> >> >_______________________________________________
>> >> >tram mailing list
>> >> >[email-masked]
>> >> >https://www.ietf.org/mailman/listinfo/tram
>> >>
>> >> _______________________________________________
>> >> tram mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/tram
>