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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 28 Sep 2015 16:16:45 +0000

> -----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.
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