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

[Brandon Williams <[e-mail]>]

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.

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

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

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.