Re: [16NG] Re: traffic classification

[Basavaraj Patil <[e-mail]>]

Hi Alex,
Inline:


On 2/5/07 10:27 AM, "ext Alexandru Petrescu"
<[e-mail]> wrote:

> Hi again Raj, can I interfere here (again :-)

Not a problem ;)

> 
> Basically, care to suggest any other way to provide QoS-guarantees to an
> IP stack other than using DSCP and mapping it coherently on a MAC flow?

First of all you have to realize that QoS is applicable primarily to the air
interface in the scope of this discussion. The ability to map IP sessions to
transport connections of various types (defined by IEEE, i.e uGS, rtPS,
nrtPS etc.) is not just via DSCP. While DSCP may be intended for such
purposes, it is not the only way.

An API to the 802.16 MAC layer may/will be provided that will enable
applications to request various types of transport connections with QoS
characteristics. The API can provide mapping of IP sessions to specific QoS
enabled transport connections based on the fact such as the codec type, RTP
being used, transport header, port numbers or IP addresses. In such a
scenario the classification rules would not need to look at DSCP to figure
out which transport connection to send the packets over.
DSCP is not the only means of guaranteeing that a packet be sent via a
specific transport connection.

> 
> If you do then ignore the below text...

So I guess, I can ignore the rest of the text below... :)

-Raj

> 
> Basavaraj Patil wrote:
>> Hi Jari,
>> 
>> Comments inline:
>> 
>> 
>> On 2/4/07 1:42 PM, "ext Jari Arkko" <[e-mail]> wrote:
>> 
>>> There are a couple of issues. The main technical question is
>>> whether host and base station need to be synchronized with respect
>>>  to the CID etc that they use. For instance, if the host puts
>>> something in CID = X and the base station drops it because it felt
>>>  that it should have travelled in CID = Y. If they need to be
>>> synchronized, then we can talk about whether that's something that
>>>  should be left to policy or mandated in the standards.
>> 
>> An IP packet is processed by the IP specific part of the packet CS.
>> On the uplink, the classification rules that are defined will map the
>>  packet to a service flow (Identified by Service flow ID). The
>> service flow is mapped to a transport connection which is identified
>> by a CID. The base-station when it receives the packet on the
>> transport connection (CID) does not check against any classifiers. It
>>  simply sends it via the service flow (SFID) to its destination.
>> Hence there is no check by the BS to see if the packet should have
>> been received on CID =y instead of CID=x. On the downlink, it is the
>> BS that applies the classification rules and maps a packet to a
>> service flow/transport connection and the MS simply processes it.
>> 
>>> I think it is pretty obvious that we're not mandating what port
>>> numbers or address ranges should be treated in what way; that's a
>>> standard policy/qos filtering function. If you agree, then its not
>>>  clear to me why DSCP is any different.
>> 
>> Exactly.. IEEE 802.16 defines the fields of an IP/transport header
>> that are used in the classification rules. It does not specify how to
>>  map DSCP to specific transport connections that may have different
>> characteristics.
> 
> Right, and it doesn't specify either how the DSCP maps to a Service
> Class Name, nor to a Traffic Priority.
> 
> However, the whole goal of having a IP DSCP is to be able to map it into
> a qos-guaranteed flow on the first-hop and all subsequent hops.
> 802.16MAC does provide QoS-guarantees on flows for the first hop, so it
> looks like a great tool, why not using it.
> 
> If not using this DSCP tool, then can you provide a suggestion how to
> provide QoS guarantees at IP layer for a stack running IPv6 over
> 802.16MAC?  I think there's no other way, none that I know of.
> 
>> And I do not believe we need to be defining DSCP to radio bearer type
>>  mappings either.
> 
> I think nobody mentioned Radio Bearer.  I mentioned Service Class Name
> or Traffic Priority.  There's no 802.16MAC rule that maps a particular
> IP DSCP (6leftmost bits of IPv6 Traffic  Class) into a Class Name or
> Traffic Priority.
> 
>>> The non-technical issue is whether the topic belongs to the IEEE or
>>>  IETF standard. My thinking is that it should be an IETF function
>>> if and only if IP needs to do something for which there is no
>>> corresponding link layer functionality. For instance, we map
>>> multicast IP addresses to multicast L2 addresses because there is
>>> no L2 multicast address resolution function. In our 16ng case there
>>>  appears to be a link layer function for mapping IP packets to
>>> CIDs. I don't know if that function is perfect or not, but it does
>>> seem to be an IEEE issue.
>> 
>> I do not believe there is anything that the IETF needs to do at this
>>  time. IEEE has defined a identified a set of fields of the
>> IP/transport header which are the basis for the classification rules
>>  for processing IP packets. For the purpose of mapping IP packets to
>>  specific transport connections, these are sufficient and we should
>> let things be as they are, because I do not believe it is broken.
> 
> I think 802.16 defined classifiers but no contents.  Filters and rules
> but not contents for these.
> 
> But I agree with you it may be questionable whether it's the right time
> and place.
> 
> Alex
> 


_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng