Subject: RE: [Seamoby] Examples of CAR discovery

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

Comments in-line:

> -----Original Message-----
> From: Henrik Levkowetz [mailto:[email-masked]]
> Sent: April 2, 2002 15:10
> To: Charlie Perkins; James Kempf
> Cc: [email-masked]
> Subject: RE: [Seamoby] Examples of CAR discovery
> 
> 
> 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.
> 
> _______________________________________________
> Seamoby mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/seamoby
>

---

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

Hello Gary,

> are we no playing in the L2 sandbox?

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.

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

> measure/technologies then SIR (SIR applies only to interference
> limited networks).

Bandwidth does not presume any particular air interface
technology.  SIR does not either, but the relevant numbers
are pretty high for most wired media.  Maybe instead of SIR
we would specify an acceptable error rate, but anyway this
is quibbling.

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

Regards,
Charlie P.

---

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

Hello Gary,

Regards,
Charlie P.