[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [MIP-QOS] Re: MIP-QOS -- Scope of discussions
Hi,
actually I am not sure if I understand this.. We need to re-establish QoS
subsequent to handover. This has some implications, including new load on
the new AR and those in the new path. If one or more of those routers cannot
support what is requested, then you (as a signaling mechanism) carry that
message to the source of origin, and let the source of origin decide
whatever to do next (either adapt, (gracefully) degrade, re-negotiate, tear
down,..).
So, what is the requirement ?
Regards,
-Rajeev
> -----Original Message-----
> From: Hemant.Chaskar@nokia.com [mailto:Hemant.Chaskar@nokia.com]
> Sent: Tuesday, April 17, 2001 9:44 AM
> To: mip-qos@research.nokia.com
> Subject: RE: [MIP-QOS] Re: MIP-QOS -- Scope of discussions
>
>
> I can even extrapolate your comment and look at the issue
> raised by you at
> the scale of new end-to-end path; then some adjustments to QoS may be
> required as the new end-to-end path may not support QoS that
> was there on
> the old end-to-end path. (of course, end-to-end path also
> includes AR).
> Collecting all this together, I can come up with the
> following requirement:
>
> The QoS mechanism must have provision to adapt to available
> resources on the
> new network path. (How it adapts to that is solution specific.)
>
> Hemant
>
> -----Original Message-----
> From: ext Xiaoming Fu [mailto:fu@ee.tu-berlin.de]
> Sent: 17. April 2001 11:13
> To: mip-qos@research.nokia.com
> Subject: Re: [MIP-QOS] Re: MIP-QOS -- Scope of discussions
>
>
> Hemant.Chaskar@nokia.com wrote:
> >
> > Hi:
> >
> > >7. Ability of QoS (re-)negotiation. A potential problem of
> > >mobility/handoff is the traffic pushing on ARs/Access Networks will
> > >change more dynamically.
> >
> > This is a very important issue, I agree. However, I am not
> sure if this is
> a
> > part of our QoS mechanism or it is a bigger problem of
> service discovery
> > mentioned in SeaMoby problem statement. QoS is one aspect of service
> > discovery at large. Shall we proceed with the standard
> assumption that the
> > target AR is known.
> The target AR can be known, however the burden on it before&after
> handover is uncertain. Then some existing QoS classes or individual
> flows have to re-negotiate with the AR (or change the incoming
> traffic's QoS requirements?) in case of congested AR to accomodate new
> ones. This might be possible for some less stringent QoS requirements
> traffic.
>
> > How to find it can be covered by some service discovery
> > protocol. We can concentrate only on programming QoS
> support over the new
> > data path.
> >
> >
>
> Xiaoming
>