RE: [MIP-QOS] Re: MIP-QOS -- Scope of discussions

["ext Gwendal Le Grand" <Gwendal.Le-Grand@lip6.fr>]

> Jak,
>
>
> I don't totally agree with your three "seperate" issues :
>
> >> So I think there are three separate issues here:
> >>
> >> 1) How to get signalling that is handover friendly and provides Intsrv
> >> like properties in the radio access network without requiring the
> >> entire network to be Intsrv?
>
>
> >It seems to me that the answer is micro mobility.
>
> Just wondering, what does micro-mobility have to do with IntServ?


I think that we can only use Intserv in a local domain (obviously not in the
core), if Intserv is to be used.
Moreover, micro mobility "hides" mobility to the home network. It eases the
use of Diffserv-like mechanisms (stateless)
in the core since SLAs will likely not be changed very often. Hopefully, the
mobile executes a handoff within a domain and
remains attached to the top of the micro mobility hierarchy. Thus, QoS
parameters do not change from the correspondent to the top of the micro
mobility hierarchy. Within this hierarchy, soft states can probably be
maintained. If it is not the case, then the hierarchy should be "Diffserv"
but probably not the wireless link (in my view).

I'd say micro mobility has nothing to do with Intserv apart that it may
enable to use Intserv (since it solves the scalability problem).


>
> >> 2) How to match up the above with a DiffSrv like core, like Diff-edge?
>
> >Same answer here. I would use Intserv in the micro mobility domain (to
> >handle high mobility) and Diffserv in the core.
>
> Can we claim that IntServ is optimized for high mobility scenarios?

Maybe not ! But if we could have some predicitve QoS negociation then yes
surely !
On the other hand, stateless schemes used by Diffserv suffer from a lack of
dynamicity support.
I don't see how to support QoS efficiently in a wireless network by using
only Diffserv (unless you overprovision ,but then QoS is useless !!)

> Would it suffice to say as a requirement that:
>
> "QoS mechanism must interoperate with HETEROGENEOUS QoS domains
> that may be
> encountered in the new end-to-end path."

I agree with this statement

>
> That way we will not wander into territory of saying which QoS
> scheme to be
> used in which part of the network.

But i definately believe micro mobility can considerably improve (and
facilitate) QoS deployment in mobile environment if we want to provide and
End to end scalable solution since the stateless and static part of the
network (the core) sees no mobility most of the time. Then dealing with
intra and inter domain QoS continuity is not the same problem ... I believe
HETERGENEOUS QoS domains is perfectly fitted (Diffserv vs Intserv, local
resources in each cell etc. match this definition)




> > 3) How to do handover friendly, end to end QoS for those service
> > providers that don't want to overprovision and want to provide
> > the "all circuits" message?
>
> >I'd say Micro mobility again !
>
>
> >Finally, i'd like to point out that it seems to me one issue is not being
> >discussed : a call which is initiated in a cell may have some bandwidth
> >guarantee in a cell (domain ?). Howerver, when the mobile terminal roams,
> it
> >may move into an area which cannot offer the same bandwidth to the
> >terminal(because the bandwidth has been allocated to users with the same
> >priority level). There are 2 issues :
> >	- degrade the QoS for the user or connect through another path if
> this >path
> >exists (which has been mentioned)
> >	- make sure that this does not happen to often (maybe by
> distinguishing
> >handoffs and new calls as it is done in most cellular systems)
>
> I think the above issue is outside the scope of solution for which we are
> formulating the requirements. The above issue is a special case of service
> discovery problem at large. We will still assume that target AR
> is known and
> hand over to it. Whether target AR wants to reserve bandwidth for handover
> calls or wants to handover connection to yet another AR is not within the
> scope of our problem statement.

Suppose a node has a negociated bandwidth. This node will likely wish to
benefit from the same bandwidth after a handover.
Bandwidth is one "classical" QoS parameter. If it is not guaranteed ... then
we do not provide seamless mobility with QoS. If bandwidth is not available
this means that the connection is blocked (which is bad in itself). But
worse, this could lead to a dramatic situation where all the nodes get
blocked sometimes during their communication. In that case, no terminal
benefits from a guaranteed bandwidth (which is obviously not what we want).
Good bandwidth allocation policies can provide a solution to this and i
really think we should keep this issue in mind if we intend to provide
seamless bandwidth guarantees.

This leads to a new question : what QoS parameters should be provided ? with
hard or statistical guarantees ?

Gwendal