Subject: Re: [Seamoby] Examples of CAR discovery

From: "James Kempf" <[email-masked]>
Date: Mon, 1 Apr 2002 08:16:02 -0800

Hi Charlie,

> Lastly, we have already some evidence that handing QoS from one
> access router to another access router is about the same as handing
> any other context between routers -- again, under the assumption that
> the basic authorization has already been negotiated at some time in
> the past.  There is no need to have two protocols where one is better,
> regardless of political divisions within the IETF.
>

This sounds like context transfer, not CAR discovery. QoS was one of the
intended applications of context transfer, so I believe it is in scope.

            jak

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "James Kempf" <[email-masked]>
Date: Mon, 1 Apr 2002 08:16:02 -0800

Hi Charlie,

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 1 Apr 2002 08:26:06 -0800

> This seems pretty strange to me too Jim.  I hate to say it, but the
IETF is
> showing some
> wireless ignorance here.  The MOST important thing SeaMoby could ever
do in
> the IETF is to facility seamless/smooth/soft/fluffy handoff.  This is
an
> ESSENTIAL
> part of QoS.  I have not followed the NSIS mailing list, but it sounds
> pretty misguided
> to me.  What is SeaMoby chopped liver???
>

Um, it is only chopped liver to the extent that the WG members don't
contribute to technical discussion but rather snipe at each other when
having technical discussions and at the WG chair when trying to figure
out the right thing to do. :-)

If you have some ideas about how to get around the nonlinear effects
caused by coupling two processes with time constants an order of
magnitude apart, to say nothing of how to incorporate additional
decision criteria besides power levels at the 10's of ms time constant
level, then by all means (broad and not so subtle hint) write a draft
about it and contribute on the mailing list to discussing it.

I think Allison could be convinced (and certainly I could) to have
Seamoby working on these topics if we see people willing to engage in
self-sustaining technical discussion that entertains all viewpoints and
is oriented toward coming up with a concensus solution. That does not
mean that people come on the list when the topic first comes up and
agitate that it be considered, then vanish when there is work to do on
writing and reading drafts, and refining the design. It means that
people are engaged in the process from start to finish.

            jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 01 Apr 2002 08:33:28 -0800

Hello Jim,

> intended applications of context transfer, so I believe it is in scope.

Agreed.  However, I think that whatever data format is used to _supply_
the context for a QoS handover, would be similar to the data format
to _request_ whether it is available.  Differences might be needed for
mandated vs. preferential, and for accounting purposes, but those are
details that should not obscure the basic similarity.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 01 Apr 2002 08:33:28 -0800

Hello Jim,

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 01 Apr 2002 08:56:25 -0800

Hello again,

> about it and contribute on the mailing list to discussing it.

I'm fascinated by this request, and I would really like it if you
could give some further clues about what you are looking for.
For instance, can you identify the processes that you think might
be coupled?  Can you say something more about the decision criteria?

I would think that CARD would "naturally" be constrained to consider
dynamic behavior with time constants not less than, say, 30 ms.
At least, until 2005 or so.  The (independent!) processes that
are of interest would include:

1. Something that triggers CAR discovery
2. Something else that subsequently triggers handover
3. Something that carries out remote signaling to optimize
   whatever needs fixing up after the localized handover
   has occurred.

Regarding (3), note that a local optimization for time and
smoothness is "typically" not good for wide-area optimization
of network paths.  Chained tunnels provide a good illustration
about why this is the case.  It would be even worse for extended
patch-ups to QoS.

Another way of saying this, is that although CARD is separable
from smooth handover, it has to be considered in light of what
is likely to happen once the discovery takes place.  And, I
would also say that we should be allowed to discover whatever
information by way of (1) that would be use during process (2).

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 01 Apr 2002 08:56:25 -0800

Hello again,

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 1 Apr 2002 08:26:06 -0800

IETF is
do in
an

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 1 Apr 2002 09:38:38 -0800

> details that should not obscure the basic similarity.

Off the top of my head, I can't see the connection, but this sounds like
a subtle enough point that it is probably worth doing a draft on it if
you think you have some insight to share.

BTW, I don't believe that Seamoby will be standardizing on the data
format for particular context features. At least, it is not in the
charter.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 1 Apr 2002 09:38:38 -0800

jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 1 Apr 2002 09:58:37 -0800

Hi Charlie,

> could give some further clues about what you are looking for.

Well, I'm not looking for anything, except to reduce my email volume.
:-) So far, I seem to have failed miserably. :-(

> be coupled?  Can you say something more about the decision criteria?

Obtaining measurements of IP level QoS is one process. Per our previous
discussion, the estimate was a time constant on the order of 100's of
msec. The other process is making the handover decision. That is 10's of
msec estimated.

There is another issue here. Suppose we consider a dynamic QoS
measurement on the order of 200 ms and a total (L2 + L3) handover time
of 40 ms as in previous email. Now, just for the sake of argument,
suppose we consider that the QoS measurement delivers 20 bytes of data,
minus IPv6 headers which are removed by header compression. This should
be enough for the IPv6 address of the access router and a 4 byte QoS
level. By my calculation, that is approximately 8kbps just to deliver
QoS measurement data to the mobile node. That's a lot of bandwidth. In
fact, it is more bandwidth than is used to deliver cellular voice in
current 3G systems.

> dynamic behavior with time constants not less than, say, 30 ms.

I see the time constant as rather higher, more like seconds.

>    whatever needs fixing up after the localized handover

I think one needs to distinguish between InterTHO and IntraTHO. I
believe the time constants can be considerably different, and the need
for involvement of the mobile, it's user, or potentially software agents
acting on behalf of the user, are considerably different. For InterTHO,
the time constant can be up to seconds, for IntraTHO it is 10's of ms.

> about why this is the case.  It would be even worse for extended

I'm not sure I understand your point. I agree about chained tunnels, but
I don't see how this applies to QoS.

> information by way of (1) that would be use during process (2).

Again, I think the distinction between InterTHO and IntraTHO is
important.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 1 Apr 2002 09:58:37 -0800

Hi Charlie,

            jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 01 Apr 2002 11:29:55 -0800

> msec. The other process is making the handover decision. That is 10's of

I'd like to suggest that we allow handovers based on availability
of resources for less than 100ms.  The handover can be accomplished
in a lot shorter than that amount of time, and the CAR discovery is
exactly for the purposes of doing a handover.  Why disallow the more
dynamic behavior?

> fact, it is more bandwidth than is used to deliver cellular voice in

Are you worried about delivering _any_ data to the mobile node?
What was special about QoS data here?  If we had 20 bytes of data
to be delivered to the mobile node, that wouldn't take very long
compared to the handover time.  Do you suggest that this be delivered
periodically?  I would not like that!  Otherwise, I don't see how
the 8kbps figure was arrived at...

> I see the time constant as rather higher, more like seconds.

Are you saying that a quantity being measured has to be stable for
seconds, before a mobile node can act on the measurement?

This is not right, I'm pretty sure.  Consider the following:

- CAR agrees to provide video QoS to a mobile node.  CAR even
  reserves the capacity for 100ms, waiting for the node to arrive.

- Another customer shows up 120ms later (we have lots of customers :-)
  and uses up that video bandwidth

By your definition, the mobile node should not even consider CAR,
because CAR is unwilling to tie up its resources for more than 100ms
just on the _prospect_ of a handover.  By my understanding, it would
be better (for smoother handovers) for the CAR to reserve the bandwidth,
but it would be uneconomical to do so for "seconds".

> the time constant can be up to seconds, for IntraTHO it is 10's of ms.

The time constant _could_ be large, but even for InterTHO it does
not have to be -- the two interfaces could (and often would) be on
the same router.  I would hope that we don't have to deal with mobile
agents here.

Besides that, IP-layer stuff should not depend on the specifics
of the technology (i.e., the 'T').  It should work over whatever
reasonable technology is going to support handovers.  Maybe not
carrier pigeons.

> I don't see how this applies to QoS.

Nothing deep here...  If I get QoS at the router, by appending a
QoS-reserved path between access routers to a QoS-reserved path
ending at the previous access router, I get QoS, but it takes more
network resources than would otherwise be necessary.

> Again, I think the distinction between InterTHO and IntraTHO is

I don't think we should design CAR discovery around such a
distinction.  Of course, it's important for any reasonable
system design, but that does not have to affect the discovery
protocol by which CARs are identified.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 01 Apr 2002 11:29:55 -0800

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 1 Apr 2002 12:03:15 -0800

> fact, it is more bandwidth than is used to deliver cellular voice in

Sorry, actually for 200 ms, the data rate should be 800bps. For 20 ms,
it is
8kbps. 800bps is probably not unreasonable.

So the problem in data rate only occurs if the sampling time is the same
order of magnitude as the decision time.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 1 Apr 2002 12:03:15 -0800

jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 1 Apr 2002 12:16:19 -0800

Charlie,

Let's take this off the list. I'm still conferring with Allison about
whether dynamic QoS sampling and decision making at handover is covered
in the Seamoby charter.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 1 Apr 2002 12:16:19 -0800

Charlie,

            jak

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 01 Apr 2002 13:49:20 -0800

Hello Jim,

> whether dynamic QoS sampling and decision making at handover is covered

O.K.  I wouldn't mind it, though, if Allison wished to make
her participation public.  There might be some additional
working group comments to help formulate the appropriate charter
language, if any changes need to be made.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 01 Apr 2002 13:49:20 -0800

Hello Jim,

Regards,
Charlie P.

---

From: "Satish Jamadagni" <[email-masked]>
Date: Tue, 2 Apr 2002 11:24:32 +0530

Please find a draft that proposes combining CT and CAR. This is just a
beginning - QOS classes (or context classes can be identified and the
proposal enhanced). Also this draws heavely from previous drafts on CT and
CAR. Your comments please.

Regards,
Satish Jamadagni.
Sasken Communication Technologies Ltd,
Bangalore, India.

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: "Phil Neumiller" <[email-masked]>; "Charlie Perkins"
<[email-masked]>
Cc: "Hemant Chaskar" <[email-masked]>; <[email-masked]>
Sent: Monday, April 01, 2002 9:56 PM
Subject: Re: [Seamoby] Examples of CAR discovery

---

From: "Satish Jamadagni" <[email-masked]>
Date: Tue, 2 Apr 2002 11:24:32 +0530

Regards,
Satish Jamadagni.

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Tue, 2 Apr 2002 20:30:17 +0200

Charlie, James,

	A question for clarification: When talking about QoS here, do you
mean specifically QoS as in diffserv or RSVP, or do you mean a more
general 'quality of service, as determined by first hop available
bandwidth, latency, SIR etc.' ?

	The first might be close to intractable for CARD, while I believe
the latter is not.

	Best,
		Henrik

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Tue, 2 Apr 2002 20:30:17 +0200

Charlie, James,

	Best,
		Henrik

---

From: "James Kempf" <[email-masked]>
Date: Tue, 2 Apr 2002 10:52:11 -0800

> bandwidth, latency, SIR etc.' ?

I've been under the assumption that it's the first, i.e. IP QoS.

        jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 2 Apr 2002 10:52:11 -0800

jak

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 02 Apr 2002 11:49:54 -0800

> > bandwidth, latency, SIR etc.' ?

I was not intending to bring RSVP or diffserv into the discussion, since
I think they are either end-to-end, or else related to infrastructure
protocol.  I wouldn't call handover an infrastructure operation.

To this end, we have made a definition for a "QoS object" which
is not oriented towards RSVP or diffserv, and is intended exactly to
describe the more general QoS reqiurement that may be specified
by a node.  We did this for specifying QoS contexts, as would be
useful within a context transfer framework.  I believe that the same
general data layout would be useful in suboptions to a CAR discovery
protocol, to identify the QoS requirements or preferences for target
access routers.

> > The first might be close to intractable for CARD, while I believe

I agree completely.

> James Kempf wrote in response:

That would give a much different perspective on the issues, but
I hope we can eventually agree to leave RSVP and diffserv problems
out of the discussion.  Otherwise, we might have to spend as many
months as they have to get answers, and still not be done, as
Henrik pointed out.

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 02 Apr 2002 11:49:54 -0800

I agree completely.

Regards,
Charlie P.

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Tue, 2 Apr 2002 22:10:10 +0200

2 comments inline:

	Henrik

> protocol, to identify the QoS requirements or preferences for target

Yes, this makes sense. I used some very rough general quality of
service quantifications in draft-levkowetz-seamoby-sample-00.txt, where
I described an experimental combined CAR and CT protocol we implemented
at my previous employer's. It'll be interesting to compare them with the 
QoS object you describe, and maybe get new insights. 

> out of the discussion.  

Yes, I agree.

> Otherwise, we might have to spend as many

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Tue, 2 Apr 2002 22:10:10 +0200

2 comments inline:

	Henrik

Yes, I agree.

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Wed, 3 Apr 2002 00:22:38 +0200

James,

	I'm not 100% sure what you mean below, but I do believe that 
parameters such as available bandwidth and link latency are highly
relevant to especially inter-technology CAR discovery. 

	With respect to standardizing a common representation of such 
parameters for both CAR and CT, I don't feel that _that_ is
necessarily part of the seamoby work.

	Best,
		Henrik

James Kempf wrote:
> 
> Charlie,
> 
> The work you describe below sounds potentially valuable, but  I really
> don't think Seamoby is the right place to standardize it, since it is
> not specifically focused on QoS. There may be need for QoS CT, but,
> again, I don't think Seamoby's charter extends to standardizing
> particular feature contexts. My understanding of the charter is that
> Seamoby will be standardizing on a container for CT.
> 
> >From what John described about about NSIS, I think it would fit into the
> charter (i.e. end to edge).
> 
>             jak
> 
> From: "Charlie Perkins" <[email-masked]>
> Cc: "Henrik Levkowetz" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, April 02, 2002 11:49 AM

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Wed, 3 Apr 2002 00:22:38 +0200

James,

	Best,
		Henrik

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 02 Apr 2002 14:30:21 -0800

Hello James,

I'm O.K. with your suggestion, except that if we don't have any
data, we can't show interoperability.  We ought to pick out some
reasonable contexts just to show that the seamoby protocol
really works.  I've never heard of any working group standardizing
a framework that didn't include some guts too.

Having said that, even though I can go along, I still think it might
be better to do the work in seamoby.  Otherwise, the process will
drag on a lot longer.  Plus, I reckon that a lot of people in this
group will have some expertise with handovers, even if they are
not highly experienced in other QoS areas that are more related
to interdomain traffic engineering.

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 02 Apr 2002 14:30:21 -0800

Hello James,

Regards,
Charlie P.

---

From: "James Kempf" <[email-masked]>
Date: Tue, 2 Apr 2002 14:04:27 -0800

Charlie,

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 2 Apr 2002 14:04:27 -0800

Charlie,

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 2 Apr 2002 14:37:14 -0800

Henrik,

> relevant to especially inter-technology CAR discovery.

My comment was intended to address just the notion of a QoS object and
its contents. I do not think that these are currently part of Seamoby's
charter, thus, I do not think the right people would be involved in the
WG to address standardizing them.

With respect to available bandwidth and link latency, these sound like
particular CAR capabilities. My reading of the current charter is that
we will not be actually standardizing on particular capabilities, just
on how to transfer them, similarly to how we will not be standardizing
on particular CT feature contexts, just how to carry them for CT.

Of course, in both cases, we need to specify the process by which
capabilities and feature contexts are standardized (IANA, IETF standards
action, special expert review, etc.)

> necessarily part of the seamoby work.

If by common respresentation you mean what I said above, then I agree.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 2 Apr 2002 14:37:14 -0800

Henrik,

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 2 Apr 2002 15:39:43 -0800

Hi Charlie

> a framework that didn't include some guts too.

I can think of cases where containers get standardized but their
contents don't. SLP is a good example. It defines the protocol and a way
to define services but does not define the services themselves. LDAP is
another.

But I appreciate your point about actually showing interoperability, and
even some performance enhancing effect (since CT in particular is
supposed to have a performance enhancing effect).

> to interdomain traffic engineering.

Sure, we would have to recharter, which would require the AD's consent.

For now, I frankly think we have enough to do. As I said, since paging
was moved out, we seem to have just the right number of people matched
with just the right number of tasks.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 2 Apr 2002 15:39:43 -0800

Hi Charlie

            jak