Re: [16NG] Re: traffic classification

[Alexandru Petrescu <[e-mail]>]

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

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?

If you do then ignore the below text...

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