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

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

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: April 3, 2002 12:47
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Seamoby] NSIS was:Examples of CAR discovery
> 
> 
> 
> Hello Marcus,
> 
> Marcus Brunner 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.
> 
> 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.
> 
> _______________________________________________
> Seamoby mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/seamoby
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 03 Apr 2002 11:14:48 -0800

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:
> isn't the only issue. There needs to be filtering/policing resources available
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 03 Apr 2002 11:14:48 -0800

Hello Gary,

Regards,
Charlie P.

Regards,
Charlie P.