Re: [Irtf-mobility-charter] IP Mobility Optimizations (MobOpts) RG charter

[Rajeev Koodli <[e-mail]>]

Hi Michael,

thank you for your comments.

The focus here is not on creating a new transport abstraction
to handle IP mobility. Indeed, the implicit assumption is that
providing mobility support at IP layer helps all transports, and
not just TCP. For instance, improving handover latency could
benefit an application like VoIP.

The comments in-line below are perhaps dicsussion about transport
versus IP mobility, rather than the charter itself.



"Michael A. Ramalho" wrote:

> Although not explicitly stated, I think the underlying assumption
> of the entire group is that TCP is assumed. That is, to maintain
> a particular session during mobility (e.g., handoffs between wireless
> links in different subnets) that the "IP address of the mobile node
> endpoint" must remain the same for the duration of the session.
> MIP or routing technology is fundamentally assumed here so that the
> mobile node IP address remains the same as far as the other end host is
> concerned. This is obvious from the "new route establishment" example
> provided in the proposed charter.
>

Well, there are tasks assuming MIP. However, no specific assumption
regarding what transport protocol is used is made. You are right that we
are not looking into transport protocol based solutions; the focus is on
IP Mobility that should serve all transports, not just TCP.


>
> If a MN were allowed to change/add/delete a new IP address without
> breaking the session - the "new route establishment" in the charter
> wording wouldn't need to occur! [Indeed, even neither MIP tunnels nor
> routing updates would be required!] Thus another obvious "solution"
> is to create another transport layer that doesn't have the rigid "one
> IP address forever" constraint built in (as TCP does). Note that if one
> had such a transport that a "new [Internet] architecture" would also
> not be required (only normal IP forwarding is required). "Handovers"
> across disparate wireless networks would also be less of an issue
> (you only need to concern yourself with link layer and network layer
> re-establishment).
>

Another way to look at above is that MIP already provides the ability to
add a
new IP address (and hence delete the previous one) without breaking
the session for all transports!

Fast handovers on the other hand, looks into movement detection (into a
new subnet), IP address configuration and location update latencies.
Granted that each transport protocol can do its own location update,
once the need is detected, but the problem space is likely going to have
to address similar key issues (movement detection, new IP address
configuration,..). Furthermore, why/how should the remote
end-point believe the update from the MN that it has a new IP address ?
The MIP group, as you are aware, spent considerable time working
out a solution (Return Routability). Finally, how would you support
applications that do not use this new transport protocol ? If every
application
needs to use it, that would be a good candidate functionality at the
IP layer!

>
> If this group is indeed a "research group", I think other transports
> without this constraint could be investigated. Or the group could
> explicitly exclude such work.
>

Put another way, the group would like to focus on IP as opposed to
transport mobility.

>
> I'm not against the charter work as described if the group only wants
> to consider TCP for legacy reasons. However, this important TCP
> constraint should be explicitly stated.
>

Improving handover latency, avoiding the
need for re-authentication during handovers, candidate router
selection are more general problems and should help all transport
protocols. So, I don't believe it is accurate to limit the focus to TCP.


>
> Regards,
>
> Michael Ramalho
>
> Michael A. Ramalho
> Office email: [e-mail]
> Personal email: [e-mail]
> Office: +1.941.708.4650
> Cell: +1.941.544.2844


_______________________________________________
Irtf-mobility-charter mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/irtf-mobility-charter