Subject: [Seamoby] NSIS was:Examples of CAR discovery

From: [email-masked]
Date: Tue, 2 Apr 2002 11:12:48 +0300

Hi James,

> > If one access router has 5 Mb/s available, and another only has
> > 10 Kb/s available, I would like to get my streaming video from
> > the first access router.  I might be able to have the choice.
> >
> 
> Wouldn't it be better to let the IP QoS signaling protocol 
> handle this?
> I believe this is exactly what NSIS is working on,
> but John Loughny could say more.

NSIS will not be involved in the handoff, nor resource allocation.
There may be some longer term work which would handle signaling between
network elements that would look more like capability signaling,
but that is outside of the current scope of NSIS.

I think that NSIS and SeaMoby / Context Transfer may interwork to provide 
a good solution, in my opinion.

NSIS most likely will be using a 'on path' signaling model, where the 
QoS signaling takes the same path as the data.

> I was speaking of last hop link capacity. I agree that IP is the right
> place to handle next to last hop QoS (i.e. DiffServ). I believe the NSIS
> charter also speaks about last hop QoS signaling as well. There is some
> interest in NSIS to tie Layer 2 QoS and  IP QoS together on the last
> hop, but there has not yet been much work done on it.

Actually, this is current out of scope of NSIS.

What NSIS will be working on is a generalized framework, to enable 
end to edge signaling, end to end signaling and perhaps edge to edge
signaling.

For the end-to-edge signaling, the access network (maybe even the access
router) would/could be proxying QoS for network towards the end node.

John

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

---

From: [email-masked]
Date: Wed, 3 Apr 2002 09:20:39 +0300

Hi James,
> > For the end-to-edge signaling, the access network (maybe even the
> > access router) would/could be proxying QoS for network towards the 
> > end node.
> >
> 
> So it sounds to me the only issue is that NSIS would look at 
> prehandoff or posthandoff end to edge (host to network?) signaling 
> rather than at the time of handoff, is that right?

I'm not sure what you mean.  I will say it another way.  NSIS would
not like to re-negotiate QoS after each handoff.  If Seamoby could
do some work with CARD (pre-handoff) and CT (during & post-handoff)
that would make renogotiation less needed, that would be great.

John

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 09:37:07 -0500

John, et al:

As far as I am concerned, we worked hard on defining CT requirements to be
"proactive":
that is, happening "before" a handoff. Has CAR now supplanted this
capability in 
everyones mind? If so, then I think the main value of CT has been lost.

Here's an observation for everyone to consider: in the manner that CAR (and
TARS) is
being talked about, there is an implication that the mobile will have a
choice of 
channels to handover to. These channels are to be differentiated by the
services and
QoS that they provide. It is hard, at this point, to see that this will be
the norm
for near future. Yes, if 802.11 is used for "hot spot coverage", there will
very likely
be overlap with cellular channels, but the need to make a choice for one
over the other
(if based upon QoS parameters like bandwidth, then the choice will almost
always be
802.11), will be rare.

On the other hand, if there is *any* opportunity to handover, then CT can be
employed
to improve the handover.

In short, CT has a wider applicability and benefit to improving handover
performance, whereas,
CAR has a limited applicability, particularly in the short term.

Cheers,
Gary

PS: I think it that everyone should be concerned that the definition of CAR
is being massaged 
into a being a replacement for the proposal to perform CT from MN to access
network - a concept 
that the working group did not favour, for many good, technical, reasons.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: April 3, 2002 01:21
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Seamoby] RE: NSIS was:Examples of CAR discovery
> 
> 
> Hi James,

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 09:49:20 -0500

Marcus:

  I agree with your point about PATH QoS entirely. This is one of
the issues I have with the idea that QoS "discovery" by the MN is
a problematical approach. 

  CT, as a concept, is NOT restricted to the access edge routers.
It could be used anywhere along the path. There are issues to be
resolved with this model, and the real nature of CT is currently 
academic until (and if) we start discussing actual solutions.

  The alternative is to use signalling to set up a new path with the
necessary resources. To do this during or after handover would clearly
add to the handover delay. 

  To complete the QoS path set up prior to the handover, along potential
handover paths, could consume significant resources that would not 
necessarly be used. There are approaches to minimizing this resource 
consumption, but they require different approaches to the problem then
taken in the past. There is an analogy here with RSVP.

Gary

> From: Marcus Brunner [mailto:[email-masked]]
> Sent: April 3, 2002 08:38
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery
> 
> 
> 
> 
> --On Tuesday, April 02, 2002 11:12 AM +0300 
> [email-masked] wrote:
> 
> [...]
> 
> I agree that CT might help for a good solution. However, for 
> the QoS part, 
> it is not only about a CT from one acess to anouther, but 
> also about the 
> rest of the path providing guarantees involved, where (as far as I 
> understood the CT work) context transfer itself does not help 
> too much.
> 
> I don't think we have this aggreement in the NSIS group.
> 
> 
> Marcus
> 
> --------------------------------------
> Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
> 
> E-Mail: [email-masked]
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
> 
> 
>

---

From: [email-masked]
Date: Wed, 3 Apr 2002 18:17:08 +0300

Gary,

> As far as I am concerned, we worked hard on defining CT requirements to be "proactive": 
> that is, happening "before" a handoff. Has CAR now supplanted this capability in 

CT -> Before, during, after handoff

CARD -> capability of AR irrespective of handoff.

The two are completely complimentary.

CT will not discover the target to where the handoff will go to; CARD will not
transfer any context.  I don't see why we need to be mixing the two.

John

---

From: [email-masked]
Date: Wed, 3 Apr 2002 18:17:08 +0300

Gary,

John

---

From: [email-masked]
Date: Wed, 3 Apr 2002 18:21:52 +0300

Gary & Marcus,

> a problematical approach. 

Centralized QoS solution is not something that NSIS will do.  The
IESG is extremely allergic to such things - they do not scale
Internet wide.  

It is entirely probable that NSIS will work on on-path signaling,
perhaps using a proxy architecture, yet allow (optionally) a 
pre-configured entity as well.

If NSIS does work on a proxy-based solution, CT between the proxy 
may very well be an attractive solution.

All follow-ups should go to the NSIS list.

John

---

From: [email-masked]
Date: Wed, 3 Apr 2002 18:21:52 +0300

Gary & Marcus,

John

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 10:30:18 -0500

I agree John. But I wanted to make sure this was clear.

I also want to be clear that CT does not require CAR (CARD/TARS).

I'm not against CAR, per se, but in my view, it has more applicability
to MANET type scenarios then to a well-engineered wireless data network.
Let me try to explain my position by posing a semi-rhetorical question:
would CAR be useful in a wired network (think plug and play)? Do we
need QoS discovery (for example), when I plug my laptop into a hotel
LAN?

I only want to make sure that the two, CAR and CT, stay independent.

Cheers
Gary

> Sent: April 3, 2002 10:17
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]
> Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery
> 
> 
> Gary,
>

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 10:30:18 -0500

Cheers
Gary

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 11:17:28 -0500

Marcus:

> Sent: April 3, 2002 10:50
> To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Seamoby] NSIS was:Examples of CAR discovery
> 
> 
> Gary,
> 
> --On Wednesday, April 03, 2002 9:49 AM -0500 Gary Kenward 
> <[email-masked]> wrote:
> [...]
> 
> I do not completly know the CT concept, but I still assume it 
> is about 
> transfering context information from one box to another box 
> (no matter 
> where they are located. For QoS however we talk about 
> potential context in 
> a set of boxes along a path which needs to be changed.

This is my view of the problem that CT can solve. I do not claim, however,
that
others share it.

> Might nevertheless be not that a bad idea.

If you can do it within, say, one radio frame time. Keeping in mind that
radio frame times
are getting shorter and shorter (let's not debate numbers, the point is that
there is a performance
requirement that can only be indirectly addressed within the IETF).

Gary

> Sure.

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 11:17:28 -0500

Gary

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 11:19:32 -0500

John:

 I tried to find the email that discussed "centralized QoS", or
"proxies". Can you elaborate where these threads originated?

Gary

PS: Since this is about CT, I am following it up on the Seamoby list.

> Sent: April 3, 2002 10:22

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 11:19:32 -0500

John:

Gary

---

From: [email-masked]
Date: Wed, 3 Apr 2002 20:13:21 +0300

Hi Gary,

> PS: Since this is about CT, I am following it up on the Seamoby list. 

My comment was about NSIS, not about CT so I don't think this 
conversation is really of relevance to SeaMoby.  If the signaling
path is not along the data path, then NSIS signaling
probably would not need CT.  If you see how CT could be used, please
let us know, especially on the NSIS list.

John

PS - reminds me of an old Rodney Dangerfield routine 'So, I was 
at a SeaMoby meeting when an NSIS discussion broke out.'

---

From: [email-masked]
Date: Wed, 3 Apr 2002 20:13:21 +0300

Hi Gary,

John

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 12:41:30 -0500

John:

  Clearly there is an overlap as all three solutions, CT, CAR and
NSIS are dealing with QoS. 

  I was content to let this thread drop until I came across the following
requirement in re-reading draft-ietf-nsis-req-00.txt:

"5.1.2 Resource availability information on request

   In some scenarios, e.g., the mobile terminal scenario, it is
   required to query, whether resources are available, without
   performing a reservation on the resource. One solution might be a
   feedback mechanism based on which a QoS inferred handover can take
   place."

There seems to be some overlap in functionality here. Alternative solutions
are usually great choices to have, but clearly the conversation on the
respective
roles of NSIS and CAR must continue.

Gary

> Sent: April 3, 2002 12:13

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 12:52:37 -0500

Charlie:

   Since we are talking about QoS mechanisms such as DS and IS, queue
congestion
isn't the only issue. There needs to be filtering/policing resources
available 
(and assigned), and bandwidth allocated for specific services (such as, for
example, EF).

   Or have I misinterpreted what you mean by "congestion"?

Gary

> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: April 3, 2002 12:47
> To: [email-masked]
> Cc: [email-masked]
> Hello Marcus,
> Marcus Brunner wrote:
> > I agree that CT might help for a good solution. However, 
> for the QoS part,
> > understood the CT work) context transfer itself does not 
> help too much.
> 
> My first model of the access networks is that they are not
> congested, and can move packets back and forth between access
> routers without problems.  This isn't always true, of course,
> but it is good enough to get us started.  Under this model,
> then we can get good mileage out of using QoS as just another
> context to be transferred, as long as the new access router
> has enough spare capacity over the air to satisfy the QoS
> needs of the mobile node.
> 
> If the access networks themselves are constrained, then the
> CAR discovery operation would have to be augmented by operations
> to insure availability of capacity between the old and new
> access routers, but I don't see that we have to design for that
> case right now.  Moreover, I think that whatever design we come
> up with, will be easily extendible whenever it needs to be extended
> to cover the more constrained access networks.
> 
> Regards,
> Charlie P.
>

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 14:40:57 -0500

Charlie:

  EF was just an example, and to clarify, it is a queue management
feature, but in order to fulfill the EF PHB criteria, certain
bandwidth constraints have to be met (e.g. if you cram 400 people into
first class on a 747, it will be hard to provide first class service; 
likewise, it would be hard for a flight crew to provide first class
service to everyone on a 747).

  I guess my point of view is that the real tough problems that need
to be solved for all of this to work are out of scope. Which makes it
seem somewhat like the old cliché for building cities in the sky: 
"first, assume that we have developed anti-gravity . . . ".

  On the other hand, I would not want to get in the way of creating
enablers for this functions to be solved. Like I said, I'm not against
CAR, I just want to make sure that we (Seamoby) have clearly identified
the alternative approach.

Just asking,
Gary

> Sent: April 3, 2002 14:15
> Hello Gary,
> This is all fine with me.  Presumably, the design of the
> access router that is involved with CAR discovery will take
> into account anything more that is needed for EF and so on,
> although I thought EF itself was more properly a queue
> managment feature than a bandwidth-reservation feature.
> Anyway, by the time we get down to brass tacks to design
> the actual QoS descriptor, I reckon we'll find answers for
> these problems.  As far as policing goes, I thought that
> was mainly an issue at the edge anyway.  If the handover is
> between domains, this will be an issue, but I reckon it's
> solvable.
> 
> From the standpoint of the mobile node, the _mechanisms_ by
> which QoS is determined to be available for the mobile node
> at the candidate access router can be outside the scope of
> the CAR discovery protocol itself.  Various access networks
> might use completely different methods to make this determination.
> However, from the standpoint of the access routers themselves,
> specific choices have to be made.
> 
> I'd be just as happy to leave out EF for now myself, since
> that is a per-hop thing and two access routers could both be
> neighboring the same mobile node, and yet have multiple
> hops between themselves otherwise.
> 
> Regards,
> Charlie P.
> 
> 
> Regards,
> Charlie P.
> 
> 
> > Gary Kenward wrote:
> > 
> > Charlie:
> > 
> > isn't the only issue. There needs to be filtering/policing 
> resources available
> >

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 14:40:57 -0500

Charlie:

Just asking,
Gary

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 14:54:30 -0500

The real overlap I was concerned with was between CT and NSIS.
What is the role of NSIS with regards to handover? If NSIS is
invoked to establish/negotiate QoS for a handover, what happens
to the context being transferred? How are the two synchronized,
or are they? Are the two compatible or mutually exclusive?

I have no difficulty with offering alternate solutions for the 
same problem, but we should be clear that they are either 
alternatives or complements, and if they are the latter, how they
interplay, and how the work on a stand alone basis, should we not?

Anyways, I think that this is a rather minor issue at this point
in time.

Gary

> From: James Kempf [mailto:[email-masked]]
> Sent: April 3, 2002 14:40
> To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]
> Cc: [email-masked]
> I don't see any overlap if the time constants are different. That is,
> the QoS query might occur just prior to handover, while CAR 
> might happen
> sometime alot more distant from handover.
> 
>             jak
> 
> ----- Original Message -----
> From: "Gary Kenward" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, April 03, 2002 9:41 AM

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 14:54:30 -0500

Gary

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 14:46:54 -0500

James:

 Ok. You probably know something about the solution that I don't see.

 But, in your email describing a scenario with QoS handover between GPRS 
and 802.11: if CT/QoS signalling were available today, why would Docomo 
need CAR to enable GPRS/802.11 handovers? Could they not engineer both 
wireless subnets with sufficient static mapping of QoS capabilities between 
the two? Within a year time frame, which solution is most likely to be 
available? 

Just asking,
Gary

> Sent: April 3, 2002 14:14
> Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery
> 
> 
> Gary,
> 
> I disagree about your assessment of the near term prospects 
> for CAR, see
> my earlier note to Charlie.
> 
> But I agree that CT has wider applicability, because it may be used in
> cases where the next access router is
> deterministically selected by the Layer 2 protocol due to timing
> considerations.
> 
> I also see the two as separate and, to a certain extent 
> complimentary in
> function. But the process question of "how do we standardize the
> contents?" is a similar one, though the answer may differ for the two.
> 
>             jak
> 
> To: <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, April 03, 2002 6:37 AM
> > Here's an observation for everyone to consider: in the 
> manner that CAR
> (and
> > TARS) is
> > being talked about, there is an implication that the mobile 
> will have
> a
> > choice of
> > for near future. Yes, if 802.11 is used for "hot spot 
> coverage", there
> will
> > very likely
> > On the other hand, if there is *any* opportunity to 
> handover, then CT
> can be
> > employed
> > to improve the handover.
> >

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 15:29:18 -0500

James:

> Sent: April 3, 2002 15:02
> I did not say that there would be QoS handover. What I see is CAR

  "QoS handover": a handover in which their is a quality of service
attribute associated with the session either before or after or before
and after handover. As opposed to a "best effort" handover in which
the forwarding treatment of the IP packets before, during and after handover
are "best effort".

  No specific mechanisms implied.

> providing the user on the mobile with information about what's
> available, and the user makes the selection. When they buy 
> the service,
> they're told that they can get "broadband"  or "narrowband" 
> and how the
> laptop tells them when broadband is available. A much more tractable
> problem I think.

  ? Are we talking about handover here or initial access? I fully agree
with the idea that if I turn on my laptop/pda, and there are multiple
wireless services available, it would be nice to be able to have a choice
of which one I used (I would also like to know cost, reliability, coverage 
- i.e. will I loss the service in one step). 

Do I need to do this with a dynamic protocol? Well, if I assume that 
there are many operators, and through some unknown (and complicated
subscription process), I will have an active subscription for wireless 
access with all of them, and if I assume that every operator has a different
QoS offering, yes a dynamic protocol is needed.

Do I need to know bandwidth, latency, error rates, etc., etc. Well, *I*
might
be able to make a choice given these parameters, but the majority of
Internet
users are not engineers (frankly, I think I would get tired of making this
decision). How does one translate "bandwidth", "latency" etc. into
"narrowband",
"broadband", etc. Implied here is a standardized translation of QoS
capabilities
to Classes of Service which catching marketing labels like Gold, Silver, and
Bronze.
They have to be standard if the user is going to be able to compare two QoS
offerings.

But why would I need a discovery protocol if I was subscribed to Docomo
access 
services and choosing between Docomo 802.11 access and Docomo GPRS access?
And why
would I need it to handoff between Docomo 802.11 access and Docomo GPRS
access?

(I appologize for over-use of the Docomo name. It is just a convenient
proper
noun for "THE operator".)

What am I missing here? 

Gary

> To: "'James Kempf'" <[email-masked]>;
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, April 03, 2002 11:46 AM
> > > But I agree that CT has wider applicability, because it 
> may be used
> in
> > > > As far as I am concerned, we worked hard on defining CT
> requirements
> > > to be
> > > > "proactive":
> > > > everyones mind? If so, then I think the main value of 
> CT has been
> > > lost.
> > > >
> > > > channels to handover to. These channels are to be differentiated
> by
> > > the
> > > > services and
> > > > QoS that they provide. It is hard, at this point, to 
> see that this
> > > will be
> > > > the norm
> > > > be overlap with cellular channels, but the need to make a choice
> for
> > > one
> > > > over the other
> > > > (if based upon QoS parameters like bandwidth, then the 
> choice will
> > > almost
> > > > always be
> > > > 802.11), will be rare.
> > > >
> > > > PS: I think it that everyone should be concerned that the
> definition
> > > of CAR
> > > > is being massaged
> > > > into a being a replacement for the proposal to perform 
> CT from MN
> to
> > > access
> > > > network - a concept
> > > > > > > What NSIS will be working on is a generalized 
> framework, to
> > > enable
> > > > > > > For the end-to-edge signaling, the access network (maybe
> even
> > > the

---

From: "Gary Kenward"<[email-masked]>
Date: Wed, 3 Apr 2002 16:06:20 -0500

No, not too simple. But I still haven't heard a need for a dynamic
protocol, particularly over-the-air. Inter-operability can be resolved
through SLAs.  

I agree that you need some indication in the change of availability of
coverage, however, I wonder how you will detect the recent availability of 
an 802.11 channel if your modem is powered down ;^}?

It's probably time to drop this thread. I will monitor the list to see
if I can discern an answer to my main question. 

Thanks,
Gary

> Sent: April 3, 2002 15:46
> Like I said, hotspot coverage may not be continuous and so it would be
> convenient to have some way to inform the user or some software on the
> laptop when such service is available so they can turn on the 
> interface
> card. The presumption is that they keep the card off (as I do with my
> 802.11 interface on my laptop) when there is no service to avoid
> unnecessary power drain or interference, such as on an airplane.
> 
> Also, if The Operator has multiple kinds of coverage, they 
> could just as
> easily offer a proprietary solution. An interoperability standard is
> needed because there will be some operators who won't offer hotspot
> service, but they will have business arrangements with others who do.
> 
> Does this sound too simple?
> 
>                 jak
> 
>

---

From: [email-masked]
Date: Thu, 4 Apr 2002 06:32:13 +0300

Hi Gary,

> The real overlap I was concerned with was between CT and NSIS. 

There is no overlap.

> What is the role of NSIS with regards to handover? 

There is no role of NSIS in a handover.

> If NSIS is invoked to establish/negotiate QoS for a handover, what happens
> to the context being transferred? 

NSIS will not be invoked to establish/negotiate QoS for a handover.

In chartering NSIS, discussion of Seamoby came up with the ADs.
The idea was that NSIS may use CT for QoS support with handovers.

I hope CT is done soon, so that NSIS could use CT ...

John

---

From: [email-masked]
Date: Thu, 4 Apr 2002 06:32:13 +0300

Hi Gary,

There is no overlap.

John

---

From: [email-masked]
Date: Thu, 4 Apr 2002 06:37:27 +0300

Hi Gary,

>   feedback mechanism based on which a QoS inferred handover can take 

As there is no CARD solution yet, NSIS may need to have its own 
solution, unless CARD meets NSIS' needs.  However, feel free to
bring this up on the NSIS list.

John

---

From: "Gary Kenward"<[email-masked]>
Date: Thu, 4 Apr 2002 12:50:46 -0500

Thanks Eunsoo.
 
I have no problem with the basic concept of this advertisement. I do not
support the idea of trying to capture the nature
of the 802.11 channel, in particular dynamically. I do not believe that
accurate (and thus useful) information can be captured
and relayed. 
 
So be it. The usual way out of this is to allow the advertisement to contain
data chunks that are opaque to the IP layer (and thus,
to the IETF ;^} ).
 
Gary

-----Original Message-----
From: Eunsoo Shim [mailto:[email-masked]]
Sent: April 4, 2002 19:25
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf'; [email-masked]
Cc: [email-masked]
Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery

Hi, Gary,
 
The idea is that the current access router can inform the mobile node of the
availability of other access technology if the current access router has the
knowledge.
Then the mobile node can turn on, for example, the 802.11 interface and
start scanning for the (802.11) L2 beacon.
The advantage of this approach is that the mobile node does not have to keep
the 802.11 interface on all the time. I think this advantage applies no
matter whether the different access networks belong to the same operator or
now.
 
A dynamic protocol that enables the current access router to have such
knowledge is necessary. Being dynamic is, of course, good because the
availability of the 802.11 channel may change.
 
We have not discussed about concrete solutions (or the actual discovery
protocol) yet on the mailing list. So we will have to see what will be
over-the-air and what others won't.
 
Hope this may answer your question.
Thanks.
 
Eunsoo

----- Original Message ----- 
From: Gary Kenward <mailto:[email-masked]>  
To: 'James  <mailto:[email-masked]> Kempf' ;
[email-masked] <mailto:[email-masked]>  
Cc: [email-masked] <mailto:[email-masked]>  
Sent: Wednesday, April 03, 2002 1:06 PM
Subject: RE: [Seamoby] RE: NSIS was:Examples of CAR discovery

Thanks, 
Gary 

> From: James Kempf [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: "Gary Kenward"<[email-masked]>
Date: Thu, 4 Apr 2002 12:50:46 -0500

Thanks Eunsoo.

 
Gary

-----Original Message-----
From: Eunsoo Shim [mailto:[email-masked]]
Sent: April 4, 2002 19:25
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'James Kempf'; [email-masked]
Cc: [email-masked]
Subject: Re: [Seamoby] RE: NSIS was:Examples of CAR discovery

Hi, Gary,

 

Eunsoo

----- Original Message ----- 
From: Gary Kenward <mailto:[email-masked]>  
To: 'James  <mailto:[email-masked]> Kempf' ;

Thanks, 
Gary

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 4 Apr 2002 15:02:08 -0600

Marcus the idea behind CT was to transfer information that
is common between the oldnetwork and new network. 
If the new network is forcing the MN to accept new allocations
or if the QoS control mechanisms in the new network deploy different
QoS information than the old network, then QoS CT is less beneficial.

CT was never intended to do protocol matching or negotiations.
And since it is a "seamoby" protocol, to my understanding it  
would not penetrate beyond the access network (or maybe even
access router).
end to end protocol signaling would not be handled by CT as defined
in seamoby.

BR,
Madjid

-----Original Message-----
From: Marcus Brunner [mailto:[email-masked]]
Sent: Wednesday, April 03, 2002 7:38 AM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]

--On Tuesday, April 02, 2002 11:12 AM +0300 [email-masked] wrote:

[...]

> a good solution, in my opinion.

I agree that CT might help for a good solution. However, for the QoS part, 
it is not only about a CT from one acess to anouther, but also about the 
rest of the path providing guarantees involved, where (as far as I 
understood the CT work) context transfer itself does not help too much.

Marcus

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 4 Apr 2002 15:02:08 -0600

BR,
Madjid

-----Original Message-----
From: Marcus Brunner [mailto:[email-masked]]
Sent: Wednesday, April 03, 2002 7:38 AM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]

[...]

Marcus