RE: stds-80220-requirements: New Material: Priority Access
Jim,
I agree with Rex that the notion of "bumping" is not really relevant to
priority access in a packet switched system that assigns resources on an
on-demand basis. In circuit switched systems where there's a one-to-one
relationship between users and resources -- and also a one-to-one
relationship between services and resources, by the way -- providing a
resource (circuit) to a high-priority user might require that a resource be
reclaimed from a lower priority user (bumping). In packet switched
systems, resources are steered towards high priority services, "starving"
lower priority services rather than bumping them.
Also, a comprehensive QoS design can include different access policies for
different service classes, addressing the issue of low-priority terminal
populations raised in your points 2 and 3 below.
Regards,
Marc
------- start of digest (2 messages) (RFC 934 encapsulation) -------
From: Jim Tomcik <jtomcik@qualcomm.com>
To: "Chickinsky, Alan" <alan.chickinsky@ngc.com>,
"'Stds-80220-Requirements (E-mail)'" <stds-80220-requirements@ieee.org>,
Marc Goldburg <marcg@arraycomm.com>
Subject: RE: stds-80220-requirements: New Material: Priority Access
Date: Mon, 27 Oct 2003 12:09:32 -0800
Message-Id: <5.2.0.9.2.20031027115933.019dedd8@m2.qualcomm.com>
At 04:42 PM 10/24/2003 -0700, Chickinsky, Alan wrote:
>Jim-
>
>can we say that Priority Access is a case of QOS?
Alan,
I was considering whether QoS was sufficient, but I fear it might not
be. To deal with priority access there are several items to consider, some
of which involve MAC, in particular.
1. QoS support is certainly part of the picture; its needed to control the
flow of data to/from a Mobile Terminal in the presence of network congestion.
2. I don't think QoS covers the ability of the infrastructure to bump
(i.e. terminate connected service to) already connected terminals in an
overloaded system when priority-authorized stations are trying to gain
access. This function isn't as simple as a disconnect, either. Most MTs
today will retry until they succeed, thus keeping the access mechanism
clogged up.
3. QoS doesn't seem to cover the MAC issue of allowing/granting a subset
of so-authorized MTs to contend for access to the wireless medium when many
un-authorized MTs may be trying to access the medium too.
Marc, to achieve items 2 and 3 above, I think this might have to be be a
device-type authorization issue. From an infrastructure viewpoint, there
has to be some way to sort out devices trying to get access to the system.
Jim
>alan
>
>-----Original Message-----
>From: James Tomcik [mailto:jtomcik@qualcomm.com]
>Sent: Friday, October 24, 2003 5:55 PM
>To: 'Stds-80220-Requirements (E-mail)'
>Subject: stds-80220-requirements: New Material: Priority Access
>
>
>
>As I review the requirements document, I realize that the requirement for a
>priority access mechanism has been lost. Accordingly, please re-include
>the following in an appropriate section:
>
>x.x.x Priority Access Mechanism
>
>The Air Interface shall provide priority access to authorized Mobile
>Terminals.
>
>
>Rationale:
>
>In emergency situations, wireless communications systems typically are
>overloaded very quickly, making communication among emergency personnel
>nearly impossible. This requirement provides for support to these critical
>communication situations. This is becoming a requirement in other
>commercial systems and should be also carried into 802.20's air interface.
>
>............................................................................
>......
>
> James D. Tomcik
> QUALCOMM, Incorporated
> (858) 658-3231 (Voice)
> (619) 890-9537 (Cellular)
> From: San Diego, CA
> PGP: 5D0F 93A6 E99D 39D8 B024 0A9B 6361 ACE9 202C C780
>............................................................................
>......
..................................................................................
James D. Tomcik
QUALCOMM, Incorporated
(858) 658-3231 (Voice)
(619) 890-9537 (Cellular)
From: San Diego, CA
PGP: 5D0F 93A6 E99D 39D8 B024 0A9B 6361 ACE9 202C C780
..................................................................................
------------------------------
From: Rex Buddenberg <budden@nps.navy.mil>
To: Jim Tomcik <jtomcik@qualcomm.com>
Cc: "Chickinsky, Alan" <alan.chickinsky@ngc.com>,
"'Stds-80220-Requirements \"(E-mail)'\"" <stds-80220-requirements@ieee.org>,
Marc Goldburg <marcg@arraycomm.com>
Subject: RE: stds-80220-requirements: New Material: Priority Access
Date: 27 Oct 2003 12:59:59 -0800
Message-Id: <1067288398.3768.9.camel@ro178-98.ro.nps.navy.mil>
When I teach QoS to my class, I use these as terms of reference:
- bandwidth efficiency
- latency, interactivity
- jitter
- determinism
You could argue for other terms but these are sufficient to make the
principle point: no free lunch.
If you want to optimize bandwidth efficiency -- certainly a laudable
goal in some instances -- then you'll be trading off everything else to
get it. Including any mechanisms that would provide priority access (a
decrease in latency). If you need to optimize priority access, you can
do that too, but it will be purchased at the expense of bandwidth
efficiency.
The means to this control is the design and the configuration of the
MAC. A timeslice (TDM) access system coupled with a scheduling
algorithm can provide determinism, control jitter and allow you to trade
off b/w efficiency vs latency by the way you configure it (by
controlling what we used to call token holding times in token LANs)
In a packet switched system, the notions of 'bumping' don't make much
sense. The lower priority customer/application simply waits longer for
access and gets less of it when it is his turn.
Do we need some QoS control (which at layer two boils down to access
control)? Definitely.
On Mon, 2003-10-27 at 12:09, Jim Tomcik wrote:
> At 04:42 PM 10/24/2003 -0700, Chickinsky, Alan wrote:
>
> >Jim-
> >
> >can we say that Priority Access is a case of QOS?
>
> Alan,
>
> I was considering whether QoS was sufficient, but I fear it might not
> be. To deal with priority access there are several items to consider, some
> of which involve MAC, in particular.
>
> 1. QoS support is certainly part of the picture; its needed to control the
> flow of data to/from a Mobile Terminal in the presence of network congestion.
>
> 2. I don't think QoS covers the ability of the infrastructure to bump
> (i.e. terminate connected service to) already connected terminals in an
> overloaded system when priority-authorized stations are trying to gain
> access. This function isn't as simple as a disconnect, either. Most MTs
> today will retry until they succeed, thus keeping the access mechanism
> clogged up.
>
> 3. QoS doesn't seem to cover the MAC issue of allowing/granting a subset
> of so-authorized MTs to contend for access to the wireless medium when many
> un-authorized MTs may be trying to access the medium too.
>
> Marc, to achieve items 2 and 3 above, I think this might have to be be a
> device-type authorization issue. From an infrastructure viewpoint, there
> has to be some way to sort out devices trying to get access to the system.
>
> Jim
>
>
> >alan
> >
> >-----Original Message-----
> >From: James Tomcik [mailto:jtomcik@qualcomm.com]
> >Sent: Friday, October 24, 2003 5:55 PM
> >To: 'Stds-80220-Requirements (E-mail)'
> >Subject: stds-80220-requirements: New Material: Priority Access
> >
> >
> >
> >As I review the requirements document, I realize that the requirement for a
> >priority access mechanism has been lost. Accordingly, please re-include
> >the following in an appropriate section:
> >
> >x.x.x Priority Access Mechanism
> >
> >The Air Interface shall provide priority access to authorized Mobile
> >Terminals.
> >
> >
> >Rationale:
> >
> >In emergency situations, wireless communications systems typically are
> >overloaded very quickly, making communication among emergency personnel
> >nearly impossible. This requirement provides for support to these critical
> >communication situations. This is becoming a requirement in other
> >commercial systems and should be also carried into 802.20's air interface.
> >
> >............................................................................
> >......
> >
> > James D. Tomcik
> > QUALCOMM, Incorporated
> > (858) 658-3231 (Voice)
> > (619) 890-9537 (Cellular)
> > From: San Diego, CA
> > PGP: 5D0F 93A6 E99D 39D8 B024 0A9B 6361 ACE9 202C C780
> >............................................................................
> >......
>
> ..................................................................................
>
> James D. Tomcik
> QUALCOMM, Incorporated
> (858) 658-3231 (Voice)
> (619) 890-9537 (Cellular)
> From: San Diego, CA
> PGP: 5D0F 93A6 E99D 39D8 B024 0A9B 6361 ACE9 202C C780
> ..................................................................................
- --
b
------- end -------