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

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

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

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

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

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

-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