Subject: RE: [seamoby] Micromobility Problem Statement

From: Pat Calhoun <[email-masked]>
Date: Wed, 3 Jan 2001 06:54:56 -0800 (PST)

> 
>    Why not? You're not under the mistaken notion that RSVP topology
>    changes need to touch every router in the path (as James seems
>    to be below) are you? RSVP works just fine with routing changes.
>    If it isn't RSVP that's going to deal with mobility, it's going
>    to be something that substantially reinvents it.
> 
I will be the first to admit that I haven't been following all of the recent
RSVP activities, but in the past it DID require that all routers in the path
to the destination process the RSVP message, and maintain state. I presume
that some of this is no longer required, somehow, in order to make use of RSVP
signaling in a diffserv core.

However, your comment on the fact that RSVP deals with mobility needs
clarification. Are you stating that RSVP is the method to request some QoS, or
it is in itself a mobility protocol?

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 3 Jan 2001 07:15:09 -0800 (PST)

<chair hat>
As I wade through the countless e-mails in my never ending inbox, I find
myself easily led into QOS discussions, and what should be the signaling
method to get micromobility. However, I think that we should all focus our
efforts on getting the actual problem statement (hey, look at the subject of
this e-mail). I think that Dana's goal was to get the problem statement work
started, and instead this thread has degrated into the solution space.

Could we continue with the task of defining what the problem is that we are
trying to solve? </chair hat>

PatC

---

From: Michael Thomas <[email-masked]>
Date: Wed, 3 Jan 2001 09:12:33 -0800 (PST)

I'm not sure what you're asking us to do here.
From my standpoint, if QoS cannot be reestablished
in a timely fashion for real time traffic, then
you cannot have seamless mobility for the most
important case and we might as well pick up our
marbles and go home. Others don't think that QoS
is important at all. Still others aren't up to
speed as to where the actual gaps are with current
IETF protocols.

So, like, what now? This doesn't seem like an
argument over the solution space so much as an
argument over relevance.

	       Mike

---

From: David Frascone <[email-masked]>
Date: Wed, 3 Jan 2001 14:42:34 -0600

It sounds to me like QoS needs to go into the Problem Statement.  Then we can
be sure that Seamoby will addresses the issues.

But, maybe I'm confused as to what you're asking :)

-Dave

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 3 Jan 2001 13:14:58 -0800 (PST)

ok, let me try one more time. 

How about we collaborate together to come up with a problem statement. One
that describes what problem we have today, and what micro-mobility is
attempting to achieve.

Talking about whether diffserv or intserv, what signaling protocols should be
used, physical wireless interface characterics seem to be stepping in the
solutions space.

We need to provide to the IESG what exactly we are trying to solve. As
tempting as it is to reference protocols at this point, let's step back and
simply define the actual problem space.

Perhaps one such way is to provide your diffs against Dana's proposed problem
statement, or propose a new one altogether.

PatC

---

From: "Dave Martin" <[email-masked]>
Date: Wed, 3 Jan 2001 20:48:00 -0500

<snipping stuff about problem statement needed>

Here's a crack at one problem I would like to see solved.

Mobile IP does a decent job of tracking mobility, but it needs some
improvements to support certain types of applications.  When a mobile node
crosses from on FA cloud to another, the network will likely lose several
packets while the network is updated with the mobiles new location.
Furthermore this period of "unreachability" while in the transitioning phase
generally lasts too long for time sensitive applications (e.g., duplex
voice, etc).  A mechanism is needed that will allow mobile nodes
unrestrained mobility while minimizing (eliminating?) packet loss and
latency.

It probably needs some word-smithing.

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 4 Jan 2001 07:04:39 -0800 (PST)

> It probably needs some word-smithing.
Dave,

Maybe it does, but it certainly is a good start. The question I have here,
though, is whether the fast handoff work in Mobile IP actually solves this
problem. I believe that it does. What do others think?

PatC

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Thu, 04 Jan 2001 10:34:48 -0500

Dave/Pat,

Some comments below.

Michael

>problem. I believe that it does. What do others think?

Partially. Within a trusted network boundary (a Trust Domain, in our
parlance) ... the fast handoff work in Mobile IP may be sufficient.
Especially if your network is over-engineered (no special QoS context
transfer needed) and you do not require re-authentication on the
network (because the next access router trusts anything that is
requested of it - like forwarding requests - from the previous router).

But ... I am hoping that seamoby addresses the larger, perhaps
cross-service provider problem. In which case one must also address
whether access routers in either service provider domain trust each
other when requests are made of it to do such-and-such (i.e., the
AAA/security issues). Then add to that the QoS "context" issue.
Then you have seamoby?

>PatC

BTW - Dana has been quiet on the list ... but what ever happened
to the Problem Statement in our draft as a start .... which was:

1.1 Problem Description

Mobility solutions require that packets be redirected to the current
location of a mobile device.  The Mobile IPv6 Binding Update [MIPv6] is
sufficient to accomplish this for best effort traffic.  However,
realtime applications require coordination of admission control,
security associations, and Quality of Service guarantees to minimize
packet loss and jitter to satisfy the expectations of realtime
applications.

Considered independently, admission control, Security Associations,
Quality of Service signaling, and Binding Updates could significantly
delay the transition from one access link to another, thus degrading the
performance of realtime applications.

[... Then a statement of what seamoby wants to accomplish here ... ].

Dave - Is this kind of where you were going?

Michael

Michael A. Ramalho, Ph.D.
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.732.449.5762
Cell: +1.732.809.0188
Pager: +1.800.365.4578

---

From: Michael Thomas <[email-masked]>
Date: Fri, 5 Jan 2001 13:42:03 -0800 (PST)

I don't want to pick on Dave in particular here,
but it seems to me that it would be good if we
could all try to converge on the same
nomenclature. I see that Dave is using "FA" here
which conjures up mipv4 FA's in my mind at least
which he may or may not be intending.

In draft-blair-rt-mobileip-seamoby-00, we tried to
gather up what we thought were the current
as-consensus-as-we-could-figure-out terms for the
various functional pieces out of MIPv6
discussions. In this particular case, the term
would be AR (= access router) instead of FA which
seems more v6/v4 neutral.

I'd encourage everybody here to look over the
nomenclature in the draft and either we decide to
use it as a basis going forward, a refinement, or
something else altogether, but I think it would
generally help move discussions forward if we
could come to some agreement on what we mean by
various pieces of functionality.

	       thx, Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 5 Jan 2001 14:16:55 -0800 (PST)

> used, physical wireless interface characterics seem to be stepping in the

Pat,

I guess this comes down to how fine-grained we
want to make the problem statement. I've been
refraining from getting into the nitty-gritty of
mechanism nuts and bolts, but I'm having a problem
if the problem statement can't even refer to
diffserv and intserv as those are standard IETF
mechanisms for delivering QoS enhanced traffic.

Is there something wrong with:

Seamoby must provide seamless mobility for traffic
from a mobile host which utilizes enhanced (> best
effort) quality of service, and must interoperate
well with the standard IETF diffserv, intserv and
combined diffserv/intserv methods of providing
enhanced quality of service. Seamoby should
endeavor to use standard quality of service
mechanisms where possible and should deliver a
problem statement to the appropriate working
groups if existing quality of service mechanisms
are found to be inadequate to support seamless
mobility.

?

		Mike

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 5 Jan 2001 14:28:00 -0800 (PST)

> are found to be inadequate to support seamless

Just to be clear, I am not discounting the fact that QoS is
important. However, let's assume for the moment that I am in
fact a village idiot. The above text doesn't, in any way, shape,
or form, tell me what micro-mobility really is. If it means
packets get routed to the mobile, then how is this different 
from today's Mobile IP.

The reason why I sent some "example scenarios" yesterday with
multiple FAs on a subnet with one AP was to see if I did in
fact understand the problem. Still not sure that I am.

Is Micro-Mobility Mobile IP with some QoS enhancements? I felt
it was more than that.

:(

PatC