RE: [Fwd: stds-80220-requirements: Proposal for Section 4.1.1MBWAQoS]
Branislav,
Again, the incorporation of MF classifiers into this standard does not
require an operator to make use of this logic. A system operating
without MF classifiers will simply map all traffic through the default
forwarding behavior priority queue, consistent with the diffserv model.
I'm concerned by your proposal of using the 6-bit DSCP field within the
IP header as the only means of classifying and mapping a packet to a
specific PHB. With this proposal and without MF classifiers, an
external application must be present to mark *uplink* packets. DSCP
fields encoded by a customer knowledgable of diffserv and fed into the
mobile terminal can now have free high priority service. Certain
forwarding behaviors are deemed expensive in terms of resources and
their un-authorized use is not acceptable.
For uplink traffic, in most cases the mobile terminal should be the only
hardware device that marks the DSCP field of the IP header, based on a
unique set of operator defined MF classifications. The system must
check other fields such as destination IP address, IP protocol field,
etc, prior to making the decision that it is acceptable to map a packet
belonging to a microflow to a particular forwarding behavior. Whether
or not the traffic is then encapsulated is irrelevant.
The submission I made encompasses this layer of security and also
introduces other features such as dropping packets (zero buffer queue)
matching a certain MF classification criteria prior to being mapped to
air interface resources. This "certain criteria" could be an MF
classification of the latest sleeping worm-virus known to operate on a
particular TCP/UDP port. Without fingerprinting this worm-virus using
an MF classifier, uplink resources could be negatively impacted to the
point the system may not be able to pass a significant amount of good
traffic.
With this in mind, I urge yourself, Samir, and Vince to reconsider your
position in this matter.
Thanks,
Jim Landon
On Wed, 2003-08-06 at 18:31, Branislav Meandzija wrote:
> Jim,
>
> If you mandate MF classifiers but say they don't have to be applied to
compressed and/or encapsulated packets, in essence you say that any kind
of classifiers are optional, if all traffic is encapsulated, as is in
some mobile standards. So, the requirement you propose is then
inconsistent with the example you give.
>
> MF classifiers may be used for initial traffic classification. That
may be done at the .20 interface but also may be done somewhere else in
the access network. If the traffic is initially classified somewhere
else in the network, the .20 interface needs to classify only based on
DSCPs and map them to PHBs. That is complete standard DiffServ.
>
> This is more powerful than the solution you give as it allows
compressing and tunneling, and classifying encapsulated traffic as well.
Different classes of traffic can be differentiated through the TOS byte
which is available in the IP wrapper of the tunneled packet. That is
IETF standard and means VoIP traffic would simply be tagged with a VoIP
DSCP that may only be unique to the DiffServ domain of the access
network.
>
> Therefore, we definitely don't see any need for mandating MF
classifiers in the .20 interface.
>
> The essence here is that there are different network architectures in
which .20 could be deployed, each one of which may have a different way
of associating DSPCs with PHBs and traffic flows. Therefore, we strongly
agree with the sentiment and proposal expressed by Samir and Vince.
>
> Branislav
>
>
>
> > -----Original Message-----
> > From: Jim Landon [mailto:james.w.landon@mail.sprint.com]
> > Sent: Wednesday, August 06, 2003 9:19 AM
> > To: Branislav Meandzija
> > Cc: 802-20 IEEE requirements list; byoung@navini.com; David McGinniss
> > Subject: RE: [Fwd: stds-80220-requirements: Proposal for Section 4.1.1
> > MBWAQoS]
> >
> >
> > Branislav,
> >
> > The MF classifier model should not and will not prevent encapsulating
> > and compressing packets between the mobile and nodes upstream of the
> > BS. If an encapsulated or compressed packet cannot be
> > fingerprinted by
> > the MF classifier, it will simply be dropped into a default forwarding
> > behavior priority queue. As such, I am still of the opinion that MF
> > classifiers must be a part of the this standard. One example for this
> > necessity is enabling the prioritization of certain applications, such
> > as VoIP.
> >
> > In adition, the system should support the ability to apply
> > both varying
> > degrees of adaptive coding and ARQ to a forwarding behavior. The
> > rational is that certain applications need better RF link reliability
> > characteristics or the overall performance of the application is
> > negatively impacted.
> >
> > Please review attached.
> >
> > Thanks,
> > Jim Landon
> >
> >
> >
> > On Wed, 2003-07-30 at 20:04, Branislav Meandzija wrote:
> > >
> > > .20 should not prevent encapsulating and compressing packets between
> > the mobile and nodes upstream of the BS (e.g. TCP/IP header
> > compression
> > or PPP compression in 3GPP2). Therefore MF classifiers, especially if
> > extended to fields beyond TCP/IP, should be optional. I made the small
> > edit in Jim's write-up to reflect that.
> > >
> > > Branislav
> > >
> > >
> > > > -----Original Message-----
> > > > From: owner-stds-80220-requirements@majordomo.ieee.org
> > > >
> > [mailto:owner-stds-80220-requirements@majordomo.ieee.org]On Behalf Of
> > > > Jim Landon
> > > > Sent: Wednesday, July 30, 2003 3:54 PM
> > > > To: 802-20 IEEE requirements list; byoung@navini.com
> > > > Cc: David McGinniss
> > > > Subject: [Fwd: stds-80220-requirements: Proposal for Section
> > > > 4.1.1 MBWA
> > > > QoS]
> > > >
> > > >
> > > > All,
> > > >
> > > > While I agree in principle with the contribution submitted by Bill
> > > > Young, it lacks certain components that this group should consider
> > > > including within the 802.20 standard.
> > > >
> > > > Attached, please find proposed revision.
> > > >
> > > >
> > > > Jim Landon
> > > > Sprint Broadband Wireless
> > > > Principle Engineer
> > > > 425-830-3272
> > > > james.w.landon@mail.sprint.com
> > > >
> > > >
> > > > -----Forwarded Message-----
> > > >
> > > > From: bill young <byoung@navini.com>
> > > > To: stds-80220-requirements@ieee.org
> > > > Cc: david.s.mcginniss@mail.sprint.com
> > > > Subject: stds-80220-requirements: Proposal for Section
> > 4.1.1 MBWA QoS
> > > > Date: 24 Jul 2003 12:52:55 -0500
> > > >
> > > > Colleagues,
> > > >
> > > > Please find attached an updated Section 4.1.1 QoS For MBWA.
> > > > This recommendation is submiited by:
> > > > Arif Ansari - Nextel
> > > > Samir Kappor - Flarion
> > > > Vince Park - Flarion
> > > > Bill Young - Navini
> > > > Mike Youssefmir - Aarrycom
> > > >
> > > > <<Requirements_QOS_07.24.03_Final.doc>>
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Bill Young
> > > >
> > > > Navini Networks
> > > >
> > > > Office (972) 852-4242
> > > > Mobile (972) 814-9191
> > > > Email: mailto:byoung@navini.com
> > > > URL: www.navini.com
> > > >
> > > > Internet at the Speed of Thought......
> > > >
> > > >
> > > >
> >
>