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

[Brandon Williams <[e-mail]>]

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

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