RE: stds-80220-requirements: New Material: Priority Access
Marc, Rex, Alan,
I think I'm OK with this - at least for now. Good points regarding QoS and
the issue of bumping resources from one to another. Scheduler can (as Marc
points out) simply starve (or shut out) other users. This does assume that
a high priority station can access the medium, of course.
Lets hold off inserting requirements on this for now.
Jim
At 05:30 PM 10/27/2003 -0800, Marc Goldburg wrote:
>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 -------
..................................................................................
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
..................................................................................