Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [Fwd: stds-80220-requirements: Proposal for Section 4.1.1MBWAQoS]


Jim,

We really understand your viewpoint and appreciate your concern for making sure that all users are authorized and get exactly the grade of service they pay for. The misunderstanding is in that your objectives of securely classifying traffic can be met by different types of systems unrelated to the technical requirement you state and unrelated to PHY/MAC. Let me explain.

> 
> 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.   

Any type of field is subject to spoofing by malicious users. So, by the same token you can not trust any other field that MF classifiers may look into. If you take the security argument into consideration, you really don't want to be classifying on the mobile side whatsoever. 

This problem is entirely avoided if all initial classification (including MF classification if desired) is done by some other node in the access network (as stated in my message below). However, that is network architecture solution specific. 

Again, we really understand your viewpoint and appreciate your concern, but bottom line, the only thing the air interface needs to know is that it needs to associate a PHB with a microflow. Which PHB to use is signaled by the DSCP (that can be passed to the air interface on a MAC SAP and possibly across the air if no classification is done on the mobile). That is all and standard DiffServ. Everything else is network architecture specific, i.e. outside the PHY/MAC scope of the group.

I think we now really have exhausted this discussion. I am attaching the original QoS proposal made by Bill Young on behalf of a larger group, which we believe should be taken as is, as it is agreeable to the largest number of concerned parties (i.e. the rough consensus of the group).

Branislav

> 
> 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......
> > > > > 
> > > > > 
> > > > > 
> > > 
> > 
>


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......

Requirements_QOS_07.24.03_Final.doc