Subject: [NSIS] Support needed for Throughput Adaptive QoS in wireless

From: "Steve Gilbert" <[email-masked]>
Date: Fri, 18 Jan 2002 10:20:50 -0600 (CST)

I tend to agree with the need which Herman identifies (below) for throughput
adaptive capabilities in a wireless QoS system.

The cellular wireless QoS problem is very different than that of wired QoS
because of the need to handle the case of a user with a QoS "guarantee" handing
off into a different cell.  In the worst case, the cell which it is entering may
have its resources fully allocated to existing users. Dropping the session of
the user being handed off is not a good idea. This points out the need for some
rational way to accommodate such calls. The approach taken in some wireless
voice systems is to reserve resources for use only by sessions which are handing
off into the cell. This may suffice if the resource needs of the hand off
session are predictable. However, in a system in which arbitrary applications
can utilize a wide range of throughput values, reserving enough capacity to
handle the range of throughputs which could potentially be needed by a single
flow may not be practical.

What is needed is the use of throughput adaptive applications and the ability
for a traffic flow to express its QoS preferences with regard to the throughput
values which it may be allocated. Upon handing off into the new cell, the QoS
preferences of the handoff traffic flow and of the existing traffic flows in
that cell would be considered and resources reallocated to best meet their
preferences. Some of the existing traffic flows may have their throughput
allocations reduced in order to free up resources to be allocated to the handoff
traffic flow.

The QoS signaling needs of this approach include the ability of the system to
notify traffic flows of their new allocations, and the ability for a new traffic
flow requesting "admission" to express its QoS preferences, possibly in terms of
a list of throughput values and the benefit it receives from each. A
non-adaptive real-time application would indicate a single throughput value
which it desires rather than a list of throughput values.

One could argue that this provides no throughput "guarantee" and changes what it
means to have a QoS request "admitted". This is true. But in wireless, it is
difficult and sometimes impractical to provide the same QoS guarantees that
could be provided in a wireline system which doesn't have to deal with
handoff. In a wireless system, there is the possibility that the user will drive
into a tunnel or take the elevator to a sub-basement of a building where the
wireless signal is lost. Radio coverage and QoS can not be guaranteed under all
possible situations.  Wireless channel resources are often more scarce or
expensive than those of a wired channel. This generally results in the
motivation to utilize them more efficiently. What is more realistic than trying
to provide wireless QoS identical to that of wire-line is to come up with a
useful approach for "QoS management" and "resource allocation" which can be
applied in a wireless system.

If efficient utilization of the resources by QoS flows is not a major concern,
the QoS of admitted users could be increased (or at least made less prone to
reductions) through over-provisioning or preventing admission of new calls even
when the level of congestion is still low. The resources not guaranteed to QoS
traffic flows could be used by best effort traffic. Systems with significant
best effort traffic would be able to increase the overall utilization of the
channel without negatively effecting QoS traffic flows.

Steve

> Date: Thu, 17 Jan 2002 19:49:13 +0000
> To: "Georgios Karagiannis (ELN)" <[email-masked]>,
>    "'Loughney John (NRC/Helsinki)'" <[email-masked]>,
>    "'ext Kappler Cornelia'" <[email-masked]>
> From: Hermann De Meer <[email-masked]>
> Cc: <[email-masked]>
> Subject: RE: [NSIS] Two kinds of requirements
> 
> Hi Georgios and all
> 
> At 14:09 17/01/2002 +0100, Georgios Karagiannis (ELN) wrote:
> >Hi John and Cornelia
> >
> >I think that one of the requirements that should be included
> >in the NSIS WG requirements document is that the NSIS protocol
> >should be modular. Modular in the context of having
> >a toolkit from which one can choose the applicable tools
> >in order to manage QoS in a particular networking environment.
> 
> I believe you are raising a very important issue with the emphasis on 
> modularity
> of QoS architectures/signalling.
> 
> But one can generalize that: it's all about flexibility,
> namely flexibility of signalling/control/provisioning vs. flexibility of 
> applications/users.
> 
> Flexibility does not necessarily mean complexity, often on the contrary:
> one side being flexible makes the life for the other side easier (think of 
> airline ticket pricing:
> the price for the *same seat* can vary in an order of magnitude simply
> depending on how flexible you are!)
> 
> QoS signalling is about indicating of how "inflexible" you are from that 
> perspective.
> But looking at IntServ (RSVP) or DiffServ,  an interpretation of these signals
> have traditionally been seen rather statically:
> 
> - a "one-size-fits-all"  "end-to-end" implementation of the mechanisms
> - a "take-it-or-leave-it" approach: statically defined QoS classes.
> 
> this makes QoS provisioning cumbersome, complex, expensive (unnecessarily)
> (and it may be a good deal the reason for the "failure/insufficiency" of 
> current QoS solutions/
> signalling techniques).
> 
> Remember, the success of IP networking has to a larger extend been due to 
> the fact of
> relying on flexibility and cooperation, for example, for congestion handling.
> (or "exception" handling, if you want, by TCP-similar schemes)
> 
> in <draft-demeer-nsis-analyis-00.txt> we therefore make a point to extend 
> QoS signalling for:
> 
> 1) explicitly dealing with such "QoS exceptions" (there is also an economic 
> argument for this)
>      that is, not only signaling QoS preferences from applications to the 
> network, but also
>      QoS exceptions back from networks to applications or to between networks,
>      and an expected cooperative adaptation.
> 
> 2) allowing for flexible interpretations in different domains (core, 
> access, mobile, wireless,
>       administrative conditions, ....)
> 
> 
> The "trick" may be to modify signalling (including RSVP) such that most 
> flexibility/cooperation
> can be re-gained by assuring a minimum support of inflexibility 
> (intentionally not using the
> the term QoS guarantee here).
> 
> 
> --Hermann
> 
...

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

---

From: [email-masked]
Date: Tue, 22 Jan 2002 11:01:33 +0000

Steve, All,

I agree with what you write in your mail, Steve, and in my opinion this is a 
very good summary of the wireless characteristics. In fact, your description of 
the wireless characteristics are much in line with our draft about wireless 
issues :
http://www.ietf.org/internet-drafts/draft-fodor-intserv-wireless-issues-00.txt

Let me try to summarize the main characteristics (C1-C3) of the wireless 
transport that may impact the requirements on the QoS protocol at the IP level 
in an IP over wireless situation.

C1: The wireless resources (frequency, time slot, power, code-point, etc.) are 
scarce and therefore expensive. In addition they may change in time due to 
mobility, hand-over, interference, etc.

C2: The wireless link  imposes often significant delay on the bits that are 
transmitted over it. This delay is typically order(s) of magnitude longer than 
that imposed by the fixed (e.g optical) transmission links.

C3: It causes bit errors with typically orders of magnitude higher probability 
than that caused by the fixed transmission links.

From these one can easily derive at least two main objectives of the wireless 
link resource management :

O1. To provide the required QoS for the entity (e.g. an IP application running 
on a mobile station) that requests the wireless transport service over the 
air interface. The QoS of the wireless transport service is typically 
characterized by C2 and C3 above.

O2. To make as efficient use of the wireless resources as possible (because of 
C1 above).

From these two objectives it follows that the radio resource management 
requires information about (1) the required QoS and (2) the characteristics of 
the traffic that is transported over the wireless link. These two pieces of 
information are required in order to exercise admission control and to allocate 
the necessary resources.

In a scenario, where the wireless link provides the transport service for 
applications running over IP, it is a challenging task to provide these two 
pieces of information, because the application may not be aware of the wireless 
link. Therefore, in such a scenario, the QoS and resource reservation mechanism 
at the IP layer (e.g. resource reservation and/or signaling protocols and the 
IP level bearer service) need to provide support for the resource management at 
the wireless link layer.

From this observation it follows that we need fine grained QoS and traffic 
characteriztaion per user IP flow in the host-edge part. In fact, there are
applications, such as adaptive codecs, see :

http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-amr-10.txt

that allow QoS differentiation within an IP packet by employing the so called 
unequal bit protection technique. We may need to support this technique as 
well. Therefore, in my opinion it is important that we consider which 
paramaters (information elements) we support in the protocol. 

/Gabor

> Date:          Fri, 18 Jan 2002 10:20:50 -0600 (CST)
> To:            [email-masked]
> From:          "Steve Gilbert" <[email-masked]>
> Reply-to:      [email-masked]
> Subject:       [NSIS] Support needed for Throughput Adaptive QoS in wireless

> because of the need to handle the case of a user with a QoS "guarantee"
> handing off into a different cell.  In the worst case, the cell which it is
> entering may have its resources fully allocated to existing users. Dropping
> the session of the user being handed off is not a good idea. This points out
> the need for some rational way to accommodate such calls. The approach taken
> in some wireless voice systems is to reserve resources for use only by
> sessions which are handing off into the cell. This may suffice if the resource
> needs of the hand off session are predictable. However, in a system in which
> arbitrary applications can utilize a wide range of throughput values,
> reserving enough capacity to handle the range of throughputs which could
> potentially be needed by a single flow may not be practical.
> 
> for a traffic flow to express its QoS preferences with regard to the
> throughput values which it may be allocated. Upon handing off into the new
> cell, the QoS preferences of the handoff traffic flow and of the existing
> traffic flows in that cell would be considered and resources reallocated to
> best meet their preferences. Some of the existing traffic flows may have their
> throughput allocations reduced in order to free up resources to be allocated
> to the handoff traffic flow.
> 
> notify traffic flows of their new allocations, and the ability for a new
> traffic flow requesting "admission" to express its QoS preferences, possibly
> in terms of a list of throughput values and the benefit it receives from each.
> A non-adaptive real-time application would indicate a single throughput value
> One could argue that this provides no throughput "guarantee" and changes what
> it means to have a QoS request "admitted". This is true. But in wireless, it
> is difficult and sometimes impractical to provide the same QoS guarantees that
> handoff. In a wireless system, there is the possibility that the user will
> drive into a tunnel or take the elevator to a sub-basement of a building where
> the wireless signal is lost. Radio coverage and QoS can not be guaranteed
> under all possible situations.  Wireless channel resources are often more
> scarce or expensive than those of a wired channel. This generally results in
> the motivation to utilize them more efficiently. What is more realistic than
> trying to provide wireless QoS identical to that of wire-line is to come up
> with a useful approach for "QoS management" and "resource allocation" which
> can be applied in a wireless system.
> 
> reductions) through over-provisioning or preventing admission of new calls
> even when the level of congestion is still low. The resources not guaranteed
> to QoS traffic flows could be used by best effort traffic. Systems with
> significant best effort traffic would be able to increase the overall
> utilization of the channel without negatively effecting QoS traffic flows.
> 
> Steve
> 
> 
>