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

["Pal Martinsen (palmarti)" <[e-mail]>]

Thanks for review and comments
> On 22 Jan 2016, at 16:50, Brandon Williams <[e-mail]> wrote:
> 
> 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.
> 

+1. Should be fixed up in the document.

> 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.
> 
Hmm. I think you are right. Will try to write up something.

> 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.
> 
Yes, the intention was to have a MICE draft (Mobility for ICE) that covers some of those use-cases. But we are waiting for all the trickle and nomination discussions to finalise to see if there is actually a need for a mobility extension. 

.-.
Pål-Erik

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