Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: Brandon Williams [mailto:[e-mail]]
> Sent: Thursday, January 28, 2016 3:30 AM
> To: Tirumaleswar Reddy (tireddy); [e-mail]
> Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt
> 
> On 01/27/2016 10:01 AM, Tirumaleswar Reddy (tireddy) wrote:
> >> -----Original Message-----
> >> From: tram [mailto:[e-mail]] On Behalf Of Brandon
> >> Williams
> >> Sent: Friday, January 22, 2016 9:21 PM
> >> To: [e-mail]
> >> Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-mobility-00.txt
> >>
> >> I've got a couple of comments on the current version of the draft.
> >>
> >> s3.1.2
> >> The current text has some discussion of path MTU and STUN message
> >> size restrictions that relates to requirements that I think we have
> >> previously decided to relax. If my memory is correct, we decided in
> >> Dallas to allow request/response messages to assume reasonable path
> >> MTU values (rather than the IPv4 minimum), so we might want to avoid
> >> reiterating limiting guidance from RFC5389.
> >
> > https://tools.ietf.org/html/draft-ietf-tram-stunbis-02 continues to have the
> same limiting guidance from RFC5389. Even new protocols like COAP suggest
> implementations to have the same limitation
> https://tools.ietf.org/html/rfc7252#section-4.6.
> >
> 
> Sure, we apparently haven't settled on something yet (see separate thread).
> That said, even the COAP draft you cite uses SHOULD not MUST, and it uses
> more realistic guidance for the unknown MTU case (maybe we should adopt
> that language for STUN?). Let's make sure we settle on the broader question
> of MTU size requirements/recommendations for STUN.
> 
> >> I can't find reference to this decision in the meeting minutes from
> >> Dallas, though, so maybe I'm mistaken. Nevertheless, it's probably
> >> better to just mention that you can't assume MTUs are the same and
> >> point to RFC5389 for further guidance, rather than repeating
> >> requirements language.
> >
> > I don't see a harm repeating the point, it reminds implementers to design
> the ticket with a small size.
> >
> 
> I've seen multiple cases where a draft reiterated specific requirements
> language from an existing RFC and it went out-of-date due to the referenced
> draft being updated. Repeating requirements can be a maintenance burden
> and drive future incompatibility bugs.

Okay, updated draft.
 
> 
> >>
> >> s3.2.2
> >> A common use case for mobility will likely be what some have described
> as
> >> the "walk out the door" problem. Two interfaces are functional (e.g.
> >> both wifi and lte) and you want to seamlessly switch from one to the
> other.
> >> You probably want to be able to use both interfaces at the same time
> while
> >> you're figuring out whether/when to switch from one to the other (make
> >> before break).
> >
> > I don't see a problem. Applications can pick both interfaces, create multiple
> allocations, try connectivity checks on both interfaces, draft-ietf-tram-stun-
> path-data and MPRTP can be used to pick interface based on path
> characteristics. Keep the alternate candidates pair alive for switch-over and
> use ICE continuous nomination for seamless move.
> 
> So, basically, don't use turn-mobility for this purpose? I'm not clear
> why you think the more complicated approach is preferable. Why would it
> be bad for turn-mobility to support make-before-break?

Extending TURN-mobility to support make-before-break makes the proposal more complex, it may end-up just like MPTCP.
Why not use ICE or MPRTP for make-before-break ?
make-before-break means client can use multiple interfaces to send traffic to the same allocation on the server, server must also load balance return traffic etc.

> 
> >
> >> I don't think the current text supports this, since it indicates
> >> that 1) the tuple for the allocation should be updated and 2) the old ticket
> >> can only be used for retransmission. If I'm misunderstanding the intent of
> >> the text, then it would be helpful to see some explicit discussion of this
> use
> >> case.
> >>
> >> Finally (same section), while I can see the value of maintaining the existing
> >> allocation when switching between interfaces/addresses, sticking to that
> >> relay server could be a bad idea if there are other/better options for the
> new
> >> address. To support make before break in this case, I think it would be
> useful
> >> for the relay server to be able to send an ALTERNATE-SERVER attribute in
> its
> >> Refresh response message.
> >> IOW, allow the client to continue using the new allocation, but also let it
> >> know that a different/better relay is available for that address.
> >
> > Yes, but TURN service provider should have capabilities discussed in draft-
> williams-peer-redirect to pick an alternate TURN server; if the WG sees
> interest in peer-redirect we can propose Refresh response message to
> optionally signal ALTERNATE-SERVER attribute.
> 
> I'm not describing peer redirect here. I'm describing redirect just for
> my allocation. If the original relay selection was based on your network
> geography (or just your ISP), turn-mobility could just be a way for you
> to stick to a relay that won't work well for you and that you never
> would have been mapped to in the first place, regardless of who you're
> connecting to.

How will the TURN server identify an optimal alternate server just because 
the client switched from one interface to another ?

-Tiru

> 
> I'm not trying to push the idea that the mobility draft must cover this.
> I'm just suggesting that it's a possible short-coming of the mechanism
> that could make it less useful without some sort of solution. I'm happy
> to leave this for a separate discussion as Pål-Erik suggested.
> 
> --Brandon
> 
> 
> >
> > -Tiru
> >
> >> There would likely be some ICE work associated with supporting such an
> >> option, so maybe it belongs in a separate more-general doc since turn-
> >> mobility is useful without it, but it seemed worth bringing up in this
> context.
> >>
> >> --Brandon
> >>
> >> On 11/07/2015 11:36 PM, [e-mail] wrote:
> >>>
> >>> A New Internet-Draft is available from the on-line Internet-Drafts
> >> directories.
> >>>    This draft is a work item of the TURN Revised and Modernized Working
> >> Group of the IETF.
> >>>
> >>>           Title           : Mobility with TURN
> >>>           Authors         : Dan Wing
> >>>                             Prashanth Patil
> >>>                             Tirumaleswar Reddy
> >>>                             Paal-Erik Martinsen
> >>> 	Filename        : draft-ietf-tram-turn-mobility-00.txt
> >>> 	Pages           : 11
> >>> 	Date            : 2015-11-07
> >>>
> >>> Abstract:
> >>>      It is desirable to minimize traffic disruption caused by changing IP
> >>>      address during a mobility event.  One mechanism to minimize
> >>>      disruption is to expose a shorter network path to the mobility event
> >>>      so only the local network elements are aware of the changed IP
> >>>      address but the remote peer is unaware of the changed IP address.
> >>>
> >>>      This draft provides such an IP address mobility solution using
> >>>      Traversal Using Relays around NAT (TURN).  This is achieved by
> >>>      allowing a client to retain an allocation on the TURN server when the
> >>>      IP address of the client changes.
> >>>
> >>>
> >>> The IETF datatracker status page for this draft is:
> >>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/
> >>>
> >>> There's also a htmlized version available at:
> >>> https://tools.ietf.org/html/draft-ietf-tram-turn-mobility-00
> >>>
> >>>
> >>> 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/
> >>>
> >>> _______________________________________________
> >>> tram mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/tram
> >>>
> >>
> >> _______________________________________________
> >> tram mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tram
> 
> --
> Brandon Williams; Chief Architect
> Cloud Networking; Akamai Technologies Inc.