Subject: Re: [Seamoby] Examples of CAR discovery

From: "Govind Krishnamurthi" <[email-masked]>
Date: Mon, 01 Apr 2002 10:29:16 -0500

Hello all,
I think that figuring out whether the AR that the MN is going to get IP 
connectivity from has the necessary QoS support for the MN is in the scope 
of CAR discovery as this is an IP capability.

The second scenario illustrated in the Issues draft
as a justification for the need of CAR discovery,
is very similar to the example that Charlie pointed out.
It talks about the case when a MN moves into a different AR's domain and
that AR cannot support the MN's QoS needs. This example from the Issues 
draft, talks about the MN not connecting to the new AR if the AR cannot 
support the MN.

I therefore think this clearly is a case where CAR discovery is useful.
I think that QoS support in the AR is an IP capability of the AR and 
therefore CAR discovery can help.

My two cents,
Best regards,
Govind.

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

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

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Mon, 01 Apr 2002 10:48:32 -0500

Hello James,

>Well, we need to confirm this with Allison, but my reading of the
>Seamoby charter does not include anything on doing QoS for handover. I
>believe NSIS was established for purposes of consolidating all the QoS
>for wireless work. Of course, if that isn't covered and the WG wants to
>expand the charter we could discuss it when we finish our current work
>items.
>

[Govind] CAR discovery informs the capabilities of the AR (here QoS) to the 
TAR selection protocol. I think this is very different from the act of doing 
explicit QoS signalling.

Also, if QoS support is recognized as a capability of the AR, we don't need 
to expand the charter of the WG, IMHO.

Again from the CAR discovery issues draft, Section 5.2:

"For example, the MN may
need some hardware or software support from the AR or need some
application servers topologically close to the AR, to run certain
IP-based applications. Support for QoS, security, multicast, header
compression etc. are some other aspects that need to be considered
when choosing the CAR for MN's handoff. "

Best regards,

Govind.

---

From: "Hemant Chaskar" <[email-masked]>
Date: Mon, 01 Apr 2002 16:44:55

Hi James:

Pardon my ignorance here, but isn't CT about *transferring* context rather 
than negotiating capabilities. In other words, doesn't CT protocol take 
source and dest. of CT as input? Now, source is obvious, we still need to 
work on finding dest. which is target AR of handoff.

BR,
Hemant

>From: "James Kempf" <[email-masked]>
>To: "Charlie Perkins" <[email-masked]>
>CC: "Hemant Chaskar" <[email-masked]>, <[email-masked]>
>Subject: Re: [Seamoby] Examples of CAR discovery
>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
>
>

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

---

From: "Hemant Chaskar" <[email-masked]>
Date: Mon, 01 Apr 2002 16:44:55

Hi James:

BR,
Hemant

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Mon, 01 Apr 2002 12:40:59 -0500

James,
I agree, but atleast it has cleared WG last call.
If that document shouldn't be the basis of our discussions henceforth on the 
scope of  CAR discovery could you point out what other document I should 
use? Just for clarification.

Regards,
Govind.

>
>Govind,
>
>The issues draft has not yet been approved by the IESG. Until it is, I
>don't think we can rely on specific examples to guide the discussion of
>requirements.
>
>             jak
>
>

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Mon, 01 Apr 2002 12:40:59 -0500

James,

Regards,
Govind.

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Mon, 01 Apr 2002 13:19:45 -0500

James,
Two points:
1. I believe that the AR's QoS capability info through CAR discovery
is a necessary (not sufficient) condition, in deciding the TAR by the TAR 
selection algorithm. Also, as I had mentioned in an earlier mail, link 
scenarios like SIR from the AP etc are a given. Clearly, SIR will be an 
important part of the TAR decision making process.
What CAR discovery aims to do is beyond this and dealing with the 
capabilities of the AR attached to the AP. Regarding where the QoS
capability of the AR falls w.r.t other parameters while making the TAR
decision is under purview of the TAR selection implementation.

2. I don't think the example mentioned is restricted to inter-technology
handovers. I think it is quite valid for the WLAN -> WLAN case.

Please correct me if I misunderstood your comments.

Regards,
Govind.

>
>Govind,
>
>As I mentioned to Charlie, I don't see a problem with advertising
>configured QoS and having the mobile use that as a possible criteria on
>an intertechnology handover, for example. Where I have a problem is in
>using QoS as a first order deterimant of handover, on the order of
>power.

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Mon, 01 Apr 2002 13:19:45 -0500

James,
Two points:

Regards,
Govind.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 1 Apr 2002 18:11:04 -0600

Please note that transferring the QoS context as part of context transfer
is something you do when you already have made a decision on where
you are moving to (unless you are blasting context to a bunch of
candidates).

While making a decision on where to move (which I think is one usage for 
CAR as Govind mentioned) based on QoS capabilities of the sorounding ARs
is different issues and cannot be handled by context transfer (unless you 
are blasting context to all your neighbors, as I said).

I have been following NSIS (to the extent possible :) )
I know John L. is on this list, but to me it
Seems like they are dealing with e2e signaling for QoS, with
RSVP like protocols. How can you do that if you don't know 
your first hop router?? Maybe I am missing something.

I was hoping that QoS capability would be an input to the
CAR discovery protocol.

Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Monday, April 01, 2002 10:16 AM
To: Charlie Perkins
Cc: Hemant Chaskar; [email-masked]
Subject: Re: [Seamoby] Examples of CAR discovery

Hi Charlie,

            jak

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 1 Apr 2002 18:11:04 -0600

Madjid

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Monday, April 01, 2002 10:16 AM
To: Charlie Perkins
Cc: Hemant Chaskar; [email-masked]
Subject: Re: [Seamoby] Examples of CAR discovery

Hi Charlie,

            jak

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 1 Apr 2002 18:16:24 -0600

Bingo, Hemant,

you hit it right in the bulls eye. CAR discovery is
about finding the destination, CT will happen after you found
the destination. QoS CT will only help maintaining QoS after 
(or during) the handoff, but it cannot be used to determine
where to handoff to.

Madjid

-----Original Message-----
From: Hemant Chaskar [mailto:[email-masked]]
Sent: Monday, April 01, 2002 10:45 AM
To: [email-masked]
Subject: Re: [Seamoby] Examples of CAR discovery

Hi James:

BR,
Hemant

---

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

James,

> So it sounds to me like dynamic QoS negotiation for handover 
> has fallen between the cracks of the WGs.

Do we need full-blown dynamic QoS negotiation for handover?  Originally
(meaning circa last spring, after the MicroMobility work was removed from
SeaMoby), part of the access router section work was to be a capabilities
exchange between ARs, or so I thought.  Thinking in terms of baby steps,
havning some mechanism which allows a basic mechanisms (which may end up
looking like context tranfer) would not be a bad thing.

To express it more concretely, AR1 and AR2 exchange capability information.
This could be done using context transfer even ...

John

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 2 Apr 2002 10:25:27 -0500

Satish:

  The reason that CT should remain separate from CAR is that
CT is useful in many scenarios where CAR is not required. Consider
the (trivial) case of an access network engineered to provide all
the necessary QoS capabilities at each AR (note: this does not mean
that the network is homogenous, just designed/configure with forethought). 

  Indeed, if saving time during handover is the issue, then it is
always faster to do as little signalling as possible, which, for
some networks, would be CT without CAR.

  A similar argument can be put forth for the use of an NSIS solution
during handover. Note that I am talking in the general case here, there will
always be situations where the network (including the MNs) will have to
resort to signalling to maintain or re-establish sessions. Mobility is 
always about probabilistic success, and it is overkill to apply worse
case solutions to all scenarios.

Gary

> From: Satish Jamadagni [mailto:[email-masked]]
> Sent: April 2, 2002 00:39
> To: Nakhjiri Madjid-MNAKHJI1; 'Hemant Chaskar'; [email-masked]
> Hi All,
> I feel that CT and CAR should go hand in hand. The reasons 
> are as follows
> (taking a Bottom - Up approach trying to arrive at a CAR 
> protocol from a
> final TAR selection perspective assuming that this is what 
> CAR discovery is
> supposed to assist in)
> 
> Combining CT and CAR -
> 1. Saves signaling time (Time is one of the main factors for deciding
> seamless ness)
> 2. Makes sense as during a seamless HO "Context" preservation 
> is what every
> mobile terminal aims at (we are not considering application 
> adaptation and
> such kind of stuff)
> 3. Typical TAR selection would be based on a "MATCH" of the 
> MN context and
> the AR context support capabilities (any other policies and 
> user fancies can
> also be brougnt under the "Context" perspective (I assume 
> that "context"
> reflects a desired QoS feel at the MT so for all practical purposes
> "Context" and QoS are the same).
> 
> For a TAR selection the MT would send in his present 
> "Context" list to find
> a match. This I guess would be sent to all CARs (with all the 
> signaling
> overheads)
> 
> So for all practical purposes by the time I would have done a 
> TAR selection
> I would have at least achieved a partial CT if the new AR can 
> preserve the
> messages that I use for initial inquiry for TAR selection. 
> All other CARs
> where the MT would have sent a message with a wish list ( its present
> context) can release the context list if the MT finally does 
> not choose them
> based on a timer.
> 
> So I feel a CAR discovery protocol SHOULD identify and standardize "an
> ABSTRACT Context" notion for initial CAR selection and finally should
> provide for classes of Contexts to ease the TAR selection 
> process. The exact
> match algorithms  can be left to implementations. Such 
> classes of contexts
> helps in either a partial or a full CT under TAR selection itself.
> 
> Combining CT and CAR has signaling advantages and this can 
> prove critical
> for a seamless handover where the "objective is Zero latency handover"
> 
> Regards,
> Satish Jamadagni.
> 
> 
> ----- Original Message -----
> From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
> To: "'Hemant Chaskar'" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, April 02, 2002 5:46 AM
> Subject: RE: [Seamoby] Examples of CAR discovery
> 
> 
> > Bingo, Hemant,
> >

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 2 Apr 2002 17:43:23 +0200

Charlie,

Just catching up with the Easter email!

  > 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?

=> Do you have some proof that this assertion will
hold in all cases? I mean the 100 ms time limit. 
I'm curious because I haven't seen anything published
on that and I'd like to know under what assumptions
this statement would hold. 

Hesham

  > 
  > > 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.
  > 
  > 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 would think that CARD would "naturally" be constrained 
  > to consider
  > >> dynamic behavior with time constants not less than, say, 30 ms.
  > > 
  > > 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".
  > 
  > > 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.
  > 
  > 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.
  > 
  > >> 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.
  > > 
  > > I'm not sure I understand your point. I agree about 
  > chained tunnels, but
  > > 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.
  > 
  > >> 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).
  > > 
  > > Again, I think the distinction between InterTHO and IntraTHO is
  > > important.
  > 
  > 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: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 2 Apr 2002 17:55:38 +0200

> Of course it does not hold in all cases.  But it does
  > hold in some cases of interest (e.g., 802.11), and we ought
  > to be making the protocol work for those cases.
  > 
  > I don't know what kind of assumptions you would want
  > to hear.  One easy assumption is, "the handover can
  > occur in under 100ms" -- but somehow I expect you
  > were asking for more...

=> Yes, I meant the assumptions related to 
movement detection. It seems that (in the absence
of Fast Handovers) we would need to crank up
the RA rate on all links to satisfy this time
limit. I don't know how network administrators
would like that. I don't think it would be a problem
for a small sized RA though (without all the options), 
the big RAs can be sent when the options are timing out.

Regs,
Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 2 Apr 2002 17:57:40 +0200

> would like that. I don't think it would 
                                            ^
                                please add 'not'
be a problem

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 2 Apr 2002 17:57:40 +0200

^
                                please add 'not'
be a problem

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 2 Apr 2002 12:06:23 -0500

Actually, the usual measures for handover for wireless networks are
very much QoS related. In noise limited systems (e.g. AMPS), the measure
used is Signal to Noise Ratio (SNR); in interference limited systems (e.g.
CDMA)
the measure used is Carrier to Interference Ratio (CIR), where the
interference
comes from primarly other MNs. There are also a number of wireless data
systems
out there that use BER as a measure. 

In all of these cases, the measure is used to determine whether there is a
"better"
channel for communications. This is L2 QoS.

Gary

> Sent: April 2, 2002 11:44
> To: [email-masked]; [email-masked]; [email-masked]
> John,
> > havning some mechanism which allows a basic mechanisms 
> (which may end
> up
> I think what is desired here is a way to take IP level QoS into
> consideration when selecting the next access point and access 
> router to
> move to. Today only power is taken into consideration, and 
> that at Layer
> 2.
> 
>             jak
> 
>

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 2 Apr 2002 12:06:23 -0500

Gary

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 2 Apr 2002 16:40:59 -0500

Comments in-line:

> From: Henrik Levkowetz [mailto:[email-masked]]
> Sent: April 2, 2002 15:10
> To: Charlie Perkins; James Kempf
> Cc: [email-masked]
> 2 comments inline:
> 	Henrik
> Charlie Perkins wrote:
> > Henrik Levkowetz <[email-masked]> wrote:
> > 
> > > > 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.' ?
> > 
> > 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.

Clearly I have missed something here. Is IP not "infrastructure", or
are we no playing in the L2 sandbox?

> > 
> > 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.
> 
> 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. 
> 
> > 
> > > > The first might be close to intractable for CARD, while 
> I believe
> > > > the latter is not.
> > 
> > I agree completely.
> > 
> > > James Kempf wrote in response:
> > > > I've been under the assumption that it's the first, i.e. IP QoS.
> > 
> > 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.  

I am not sure (either way). I agree that there is value in standardizing
on context objects, although I'm not sure that the IETF is the place to do
it.
In particular, a desciption of QoS that involves SIR, bandwidth, etc.
immediately
presumes certain air interface technologies and ignores others others. As a 
counter example, the QoS at one network could easily involve other layer 2 
measure/technologies then SIR (SIR applies only to interference limited
networks). 

Also, it is not our task to address diffserv (or RSVP) problems, but do we
not 
have to assume that the problems will be solved and that DS, at least, will
be
part of the context transferred?

Gary

> 
> Yes, I agree.
> 
> > 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: [email-masked]
Date: Wed, 3 Apr 2002 00:21:28 +0200

Hi,  
 
Also, the L2 measures like signal to interference ratios (SIR) etc. can be used, possibly together with some other information like required SIR for a specific QoS requirement, to estimate how much "bandwidth" are available to use for new users with a specific QoS requirement. If there are more than one candidate AP/AR available then it is useful to choose the one that meet your QoS needs also from a load situation point of view and not only the radio situation. If not, then either the QoS will be too poor or you may loose the connection. This not an IP level choice but more a L2 choice even if there are more than one radio technology involved. 
 
However an access router also need to have the required capacity to admit new users with specific QoS requirements and if a certain AR does not have the required capacity on IP level then the same problem will occur as above if the required QoS on e.g. IP-level cannot be fulfilled. Otherwise the assumption need to be that the AR capacity is always assumed to be dimensioned such that it could handle all expected traffic to/from the connected access points and the outgoing routes.
 
Regards,
Håkan Persson

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: den 2 april 2002 19:06
To: 'James Kempf'; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Seamoby] Examples of CAR discovery

Actually, the usual measures for handover for wireless networks are 
very much QoS related. In noise limited systems (e.g. AMPS), the measure 
used is Signal to Noise Ratio (SNR); in interference limited systems (e.g. CDMA) 
the measure used is Carrier to Interference Ratio (CIR), where the interference 
comes from primarly other MNs. There are also a number of wireless data systems 
out there that use BER as a measure. 

In all of these cases, the measure is used to determine whether there is a "better" 
channel for communications. This is L2 QoS. 

Gary 

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

---

From: [email-masked]
Date: Wed, 3 Apr 2002 00:21:28 +0200

Hi,  

 
Regards,
Håkan Persson

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: den 2 april 2002 19:06
To: 'James Kempf'; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Seamoby] Examples of CAR discovery

Gary

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 2 Apr 2002 17:49:50 -0500

Charlie:

> From: Charlie Perkins [mailto:[email-masked]]
> Sent: April 2, 2002 17:17
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]
> Hello Gary,
> You wrote:
> I would say that IP is definitely not "infrastructure",
> as it is commonly understood. Infrastructure is more
> towards the high-traffic backbone of the Internet,
> not the edge devices and access routers.  On the
> other hand, I don't think we are at layer two, either.
> I think we are "at" the transport layer, just above IP.

Ok. Different definition that I am aware of, where infrastructure is
all the pieces connected with wires (or these days, glass).

> > on context objects, although I'm not sure that the IETF is the place
> > to do it.
> 
> Where else?  These context objects could be
> carried as data for suboptions to IETF protocols.

Don't know. I'd love to give it a try, but the kind of objects that were
being discussed seemed very link layer dependent. Maybe what is needed is
a generic structure?

> > presumes certain air interface technologies and ignores 
> others others.
> > As a
> > measure/technologies then SIR (SIR applies only to interference
> > limited networks).
> 
> Bandwidth does not presume any particular air interface

If you bandwidth as "goodput", sure. But then, you will need a number of
other descriptive parameters, including acceptable charging limits, before 
"goodput" per se would be useful parameter. E.g. suppose I am using 100Kbps
on
an 802.11b channel at a maximum latency of 0.01 sec (arbitrary numbers), at
99%
packet transfer success reliability, and I roam to a wide area cellular
channel
where, in order to reach the 99% reliability, the overhead quadruples and
the 
latency (due to retransmissions) goes to 100s of milliseconds. Along with
the
overhead increase one would guess that there might be a charging rate
increase.
Now, I contend that only the application can really decide what parameters
might
really matter in this case; however, most applications don't know, and don't
want
to know about L2 QoS parameters. And this is not the most complex situation
- e.g.
consider most 3G systems that will multiplex IP frames into radio frames,
resulting
in packet loses occuring in bursts of two or more; some applications (such
as voice)
are very sensitive to back to back losses of this nature. Request no
multiplexing 
and the radio channel overhead goes up by the amount of unused bits in each
radio
frame.

> technology.  SIR does not either, but the relevant numbers
> are pretty high for most wired media.  Maybe instead of SIR

SIR, in my lexicon, means "Signal to Interference Ratio". Not all wireless
systems are interference limited, to begin with, so SIR may not be a very
useful parameter in those cases.

> we would specify an acceptable error rate, but anyway this
> is quibbling.

Aye, but it is the quibbling that causes the problems with defining a
general
set of QoS parameters. I am not trying to start the quibbling, simply
pointing
out the issue.

> 
> > Also, it is not our task to address diffserv (or RSVP) problems, but
> > do we not
> > have to assume that the problems will be solved and that 
> DS, at least,
> > will be
> If a mobile node specifies some DSCP as part of its context,
> that should be transferred as a relevant feature context.  Some
> mobile nodes might do this, but not all of them.

I am with you on the DSCP. 

I guess we can agree to disagree on whether the mobile should know about QoS
context. 
I contend that it is the network that is best able to contend with QoS
descrepencies, 
as these issues can be sorted out during network configuration and the
writing of
the TLAs.

So, to summarize, I believe that standardizing on QoS objects *may* be
useful, but for 
different reasons. I am also skeptical about how successful we will be, for
many bright people
have attempt this before.

Of course, if the issue is to define QoS objects only for handover between
the various flavours of
3G (UMTS utran, UMTS etran, CDMA2000 1xRTTDO, CDMA2000 DV) and three
flavours of 802.11 (a, b and g), then it's feasible.

Cheers,
Gary

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 2 Apr 2002 17:49:50 -0500

Cheers,
Gary

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 2 Apr 2002 18:00:24 -0500

SIR: For SIR to be a useful inter-networking, inter-technology, handover
parameter, we would have to standardize not only
the parameter, but the method for measuring SIR, would we not? This would
also be true for BER? Latency (for an example of
the latter I refer to the debates over the EF RFC in Diff Serv).
 
Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: April 2, 2002 17:21
To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: RE: [Seamoby] Examples of CAR discovery

Hi,  
 
Also, the L2 measures like signal to interference ratios (SIR) etc. can be
used, possibly together with some other information like required SIR for a
specific QoS requirement, to estimate how much "bandwidth" are available to
use for new users with a specific QoS requirement. If there are more than
one candidate AP/AR available then it is useful to choose the one that meet
your QoS needs also from a load situation point of view and not only the
radio situation. If not, then either the QoS will be too poor or you may
loose the connection. This not an IP level choice but more a L2 choice even
if there are more than one radio technology involved. 
 
However an access router also need to have the required capacity to admit
new users with specific QoS requirements and if a certain AR does not have
the required capacity on IP level then the same problem will occur as above
if the required QoS on e.g. IP-level cannot be fulfilled. Otherwise the
assumption need to be that the AR capacity is always assumed to be
dimensioned such that it could handle all expected traffic to/from the
connected access points and the outgoing routes.
 
Regards,
Håkan Persson

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: den 2 april 2002 19:06
To: 'James Kempf'; [email-masked]; [email-masked];
[email-masked]

Gary 

> From: James Kempf [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> move to. Today only power is taken into consideration, and 
<https://www1.ietf.org/mailman/listinfo/seamoby>

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 2 Apr 2002 18:00:24 -0500

Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: April 2, 2002 17:21
To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked];

Hi,  

 
Regards,
Håkan Persson

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: den 2 april 2002 19:06
To: 'James Kempf'; [email-masked]; [email-masked];
[email-masked]

Gary

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Tue, 02 Apr 2002 21:50:13 -0500

James,
Just one comment.
>Henrik,
>
>
> > 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.
> >
>
>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.)

[Govind] IMHO it is very important to decide the capabilities and the
size of their representation. We should  take a look at some
"important" and "likely" capabilities. This is because, unlike CT which
happens over the wired network, we may have to transmit the capabilities to 
the MN. A lot of discussion happened last week regarding whether the 
transmission of capabilities to the MN will not be a burden on the MN both 
w.r.t power as well as bandwidth. If we are to go with that assumption we 
should at least be sure that this is the case. We may also want to look at 
which capabilities are updated periodically and which aren't. I know it 
might be impossible to list all the capabilities, as this may change over 
time but I think it will be good if look at the minimum capabilities that 
will be transmitted and their formats.

Regards,
Govind.

---

From: "Govind Krishnamurthi" <[email-masked]>
Date: Tue, 02 Apr 2002 21:50:13 -0500

James,
Just one comment.

Regards,
Govind.

---

From: [email-masked]
Date: Wed, 3 Apr 2002 12:24:48 -0500

Hi James,

see comment inline...

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Tuesday, April 02, 2002 6:40 PM
To: Perkins Charles (IPRG)
Cc: [email-masked]
Subject: Re: [Seamoby] Examples of CAR discovery

> 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.
>

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.

[DOT] It is not only about the 'containers' to get standardized. Designing
a carrier protocol without considering the information to be carried might quickly serve as a 
bad example of engineering. In other words, making a decision about sending 
information from and to different entities without considering WHAT (semantics) 
and HOW MUCH (semantics plus syntax) is shuffled around might lead very soon 
after the actual standardization of CAR discovery to the proof of its uselessness 
rather than its usefulness, if the way the protocol is designed restricts the amount
of information that could be carried.

[DOT] In particular due to the involvement of mobile devices, this amount of information
is a crucial factor in designing the protocol. Hence, a proper consideration
of this information (what is this information and how is this information represented)
should be a must for us to study before we make decisions on the design of the 
final solution.

Regards,

Dirk

---

From: [email-masked]
Date: Thu, 4 Apr 2002 03:37:35 +0200

I would assume that the SIR and other specific L2 measurements used for handover are/would be best specified where the specific access techniques are defined, or? Not all techniques can provide everything. Then the selection algorithm for inter-technology/networking need to use those available togehter with any other available info. 
 
/Håkan

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: den 3 april 2002 01:00
To: Persson, Håkan N. /Research /08-713 82 33, 070-588 16 12; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Seamoby] Examples of CAR discovery

SIR: For SIR to be a useful inter-networking, inter-technology, handover parameter, we would have to standardize not only
the parameter, but the method for measuring SIR, would we not? This would also be true for BER? Latency (for an example of
the latter I refer to the debates over the EF RFC in Diff Serv).
 
Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: April 2, 2002 17:21
To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Seamoby] Examples of CAR discovery

Hi,  

 
Regards,
Håkan Persson

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: den 2 april 2002 19:06
To: 'James Kempf'; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Seamoby] Examples of CAR discovery

Gary

---

From: [email-masked]
Date: Thu, 4 Apr 2002 03:37:35 +0200

/Håkan

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: den 3 april 2002 01:00
To: Persson, Håkan N. /Research /08-713 82 33, 070-588 16 12; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Seamoby] Examples of CAR discovery

Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: April 2, 2002 17:21
To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Seamoby] Examples of CAR discovery

Hi,  

 
Regards,
Håkan Persson

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: den 2 april 2002 19:06
To: 'James Kempf'; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Seamoby] Examples of CAR discovery

Gary