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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 27 Jan 2016 15:01:38 +0000

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Friday, January 22, 2016 9:21 PM
> To: [email-masked]
> 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, [email-masked] 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tram
> >
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Brandon Williams <[email-masked]>
Date: Wed, 27 Jan 2016 17:00:09 -0500

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

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

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

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?

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

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

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 28 Jan 2016 11:05:01 +0000

> From: Brandon Williams [mailto:[email-masked]]
> Sent: Thursday, January 28, 2016 3:30 AM
> To: Tirumaleswar Reddy (tireddy); [email-masked]
> >> 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.
> >
> 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.
 
> > 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.
> 

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.

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

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

-Tiru

---

From: Brandon Williams <[email-masked]>
Date: Fri, 29 Jan 2016 10:01:40 -0500

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

Without make-before-break capability, I think the mechanism might be 
limited enough in utility that it won't be widely used. This is mostly 
because I think it requires the application to be able to sustain 
potentially significant bursts of packet loss, which could be 
unacceptable for realtime communication use cases, and maybe for live 
video streams as well.

If the app keeps both addresses active and sends data on the old address 
while waiting for the refresh response, then as soon as the refresh 
request is received by the relay, all in-flight data is now effectively 
lost because it will be dropped by the relay. If the refresh response is 
lost, the client will continue sending from the previous address; 
resumption of data flow will require retransmit of the refresh request 
with an even longer period of message drops.

If on the other hand the app optimistically starts sending messages from 
the new address as soon as it sends the refresh request, then it's 
susceptible to message drops if the refresh request is lost or otherwise 
fails validation. If it keeps the previous allocation active for 
receiving packets, at least it won't drop a lot of inbound messages.

If the old address simply goes away when the new address comes up, 
there's no way to avoid this anyway. However, when it's possible to have 
both addresses active during the transition, make-before-break support 
would allow seamless transition from one to the other.

I'm not suggesting we need something as complicated as MPRTP; just that 
meeting the minimal requirements for seamless transition from one 
address to another could make the mechanism a lot more useful.

--Brandon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 30 Jan 2016 07:38:19 +0000

> Sent: Friday, January 29, 2016 8:32 PM
> >>>> A common use case for mobility will likely be what some have
> >>>> described
> >> as
> >>>> 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).
> >>>
> >> 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.
> > 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.
> >
> 
> limited enough in utility that it won't be widely used. This is mostly because I
> think it requires the application to be able to sustain potentially significant
> bursts of packet loss, which could be unacceptable for realtime
> communication use cases, and maybe for live video streams as well.

Siri on Apple uses MPTCP but does not send traffic on sub-flows on both interfaces. It only sends data on the primary interface and when the primary interface is down, data is sent on the secondary sub-flow (backup interface). The time to detect signal is weak/unavailable for switch-over should not be high otherwise user would notice communication break. 

> while waiting for the refresh response, then as soon as the refresh request is
> received by the relay, all in-flight data is now effectively lost because it will be
> dropped by the relay. If the refresh response is lost, the client will continue
> sending from the previous address; resumption of data flow will require
> retransmit of the refresh request with an even longer period of message
> drops.

Yes, loss of refresh request/response will delay the switch-over. We should discuss if refresh messages with MOBILITY-TICKET can be sent by the client and server multiple times in quick succession to handle packet loss. 

> If on the other hand the app optimistically starts sending messages from the
> new address as soon as it sends the refresh request, then it's susceptible to
> message drops if the refresh request is lost or otherwise fails validation. If it
> keeps the previous allocation active for receiving packets, at least it won't
> drop a lot of inbound messages.
> 
> If the old address simply goes away when the new address comes up, there's
> no way to avoid this anyway. However, when it's possible to have both
> addresses active during the transition, make-before-break support would
> allow seamless transition from one to the other.
> 
> meeting the minimal requirements for seamless transition from one address
> to another could make the mechanism a lot more useful.

Works for me. One possible approach could be TURN server will continue to process traffic from the old 5-tuple ) i.e. receive and return traffic on the old 5-tuple) until it sees traffic (either channelData message or a Send indication) on the new 5-tuple. In Make-before-make scenario, TURN client continues to send traffic on the old 5-tuple to the server until it sees Refresh response with MOBILITY-TICKET. 

-Tiru