Subject: [tram] Ben Campbell's No Objection on draft-ietf-tram-turn-mobility-05: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Tue, 30 Aug 2016 19:53:03 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-tram-turn-mobility-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi, I have a few minor comments and (mostly) questions:

- General: I wonder if this should consider the potential for allocation
flapping, e.g. if a client is sitting on the border between two wireless
networks. Is this an issue, and is their any reasonable guidance that
could be offered?

- 3.1.2, 2nd paragraph:
I'm curious why the server disallows this mechanism would explicitly
reject a request with the MOBILITY-TICKET attribute rather than ignoring
it as if it didn't understand it? Is there an advantage in letting the
client know that the server undertands the extension but chooses not to
use it, verses simply not understanding it?

- 3.1.4: If the client receives "Mobility Forbidden", is it allowed (or
encouraged) to retry without mobility? 

- 3.2.2: 

I'm (also) curious why the server rejects a refresh request with the
original 5-tuple and the mobility ticket. 

Also, during the transition window (before it gets a Send Indication or
ChannelData message on the new allocation), am I correct to assume that
the server forwards inbound data _only_ to the old client address? That
is, not both? If so, I think that could use some reinforcement.

- 5.1: Does MICE here refer to the draft in it's current state, or an
earlier version? (assuming there is any material difference.)

Editorial:

-1, 2nd paragraph: "the TURN client has to request for a new
   allocation"
s/request for a new/request a new
-- "new relayed candidate address would have to be tricked"
s/tricked/trickled

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 31 Aug 2016 04:17:05 +0000

Hi Ben,

Thanks for the review, Please see inline.

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Wednesday, August 31, 2016 8:23 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Simon Perreault
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]
> Subject: Ben Campbell's No Objection on draft-ietf-tram-turn-mobility-05:
> (with COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> - General: I wonder if this should consider the potential for allocation flapping,
> e.g. if a client is sitting on the border between two wireless networks. Is this
> an issue, and is their any reasonable guidance that could be offered?

I am not sure on specific guidance, https://tools.ietf.org/html/rfc6419#section-3 discusses behavior of various Mobile OS and they seem to use different techniques to pick a interface.

> 
> - 3.1.2, 2nd paragraph:
> I'm curious why the server disallows this mechanism would explicitly reject a
> request with the MOBILITY-TICKET attribute rather than ignoring it as if it
> didn't understand it? Is there an advantage in letting the client know that the
> server undertands the extension but chooses not to use it, verses simply not
> understanding it?

Yes, if the client wants mobility then can give higher priority to TURN servers that support this extension.
 
> encouraged) to retry without mobility?

Yes, the client can immediately retry without mobility.

> 
> - 3.2.2:
> 
> I'm (also) curious why the server rejects a refresh request with the original 5-
> tuple and the mobility ticket.

The server rejects the request because the client is misbehaving (No need for the client to send refresh request with mobility ticket on the original 5-tuple). 

> ChannelData message on the new allocation), am I correct to assume that the
> server forwards inbound data _only_ to the old client address? 

Yes.

> That is, not
> both? If so, I think that could use some reinforcement.
> 
> - 5.1: Does MICE here refer to the draft in it's current state, or an earlier
> version? (assuming there is any material difference.)

Mobility with ICE (MICE) was initially proposed in MMUSIC WG, 
removed MICE from this section. 

> -- "new relayed candidate address would have to be tricked"

Fixed.

-Tiru

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 30 Aug 2016 23:32:54 -0500

Hi, thanks for the quick response. Also inline:

On 30 Aug 2016, at 23:17, Tirumaleswar Reddy (tireddy) wrote:

> I am not sure on specific guidance, 
> https://tools.ietf.org/html/rfc6419#section-3 discusses behavior of 
> various Mobile OS and they seem to use different techniques to pick a 
> interface.
>

I can accept there may not be anything useful to say here.

>> reject a
> Yes, if the client wants mobility then can give higher priority to 
> TURN servers that support this extension.

Higher priority to TURN servers that support the extension but won't let 
them use it? :-)

> Yes, the client can immediately retry without mobility.

I think some clarification would be useful here. While the text says 
they should not immediately retry an "identical" request, I think some 
readers might incorrectly interpret that as "identical other than the 
mobility ticket".

> The server rejects the request because the client is misbehaving (No 
> need for the client to send refresh request with mobility ticket on 
> the original 5-tuple).

I'll accept the working group knows more than I do about this, so no 
further response is necessary. But it seems to me that if the client was 
allowed to send the ticket anytime, it wouldn't have to care about 
whether any given refresh happened to use a new 5-tuple.

>> earlier

I understand the MICE history--I guess my question was more about 
whether the spec had drifted enough from the MICE proposal to matter.

[...]

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 31 Aug 2016 05:37:54 +0000

> Sent: Wednesday, August 31, 2016 10:03 AM
> To: Tirumaleswar Reddy (tireddy) <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; Simon
> Perreault <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: Ben Campbell's No Objection on draft-ietf-tram-turn-mobility-05:
> (with COMMENT)
> 
> >> - General: I wonder if this should consider the potential for
> >> allocation flapping, e.g. if a client is sitting on the border
> >> between two wireless networks. Is this an issue, and is their any
> >> reasonable guidance that could be offered?
> >

I meant there is a good chance they may enable the extension sometime in near future :)

> readers might incorrectly interpret that as "identical other than the

Fixed. Updated line to say the following instead:
The client SHOULD NOT retry to send Allocate request containing MOBILITY-TICKET with this server until it believes the problem has been fixed.

> whether the spec had drifted enough from the MICE proposal to matter.

Yes, there are lots of changes.

-Tiru

---

From: Ben Campbell <[email-masked]>
Date: Wed, 31 Aug 2016 00:51:37 -0500

> I meant there is a good chance they may enable the extension sometime in near future :)

That's reasonable.

> The client SHOULD NOT retry to send Allocate request containing MOBILITY-TICKET with this server until it believes the problem has been fixed.

Works for me.

>> whether any given refresh happened to use a new 5-tuple.

BTW I talked myself out of this one. It saves the client work by transferring it to the server, which is assumedly much busier. Never mind.