Re: [16NG] Re: traffic classification

Jari, it may be that the mappings are not yet clear.  There seems to be 
no agreement on the necessity to map Traffic Class to certain 802.16 
parameters.  I agree.  Maybe future work will look at these, if necessary.

Jari Arkko wrote:
> Alexandru,
>> For QoS, there exist no resolution function like ND or DNS that 
>> would resolve a DSCP into a 802.16 Traffic Priority.
>> 
>> Remark I'm not talking about mapping an IPv6 Traffic Class DSCP 
>> into a CID but into a 802.16 Traffic Priority or a 802.16 Service 
>> Name.
>> 
> I browsed the relevant parts of 802.16 standards today.
> 
> The standard clearly says that it has a capability to filter based on
>  multiple fields in an IP packet, including the DSCP field.

Yes, absolutely, it does:
> 802.16-2004 11.13.19.3.4.2 ...(DSCP)...
> The values of the field specify the matching parameters for the IP
> type of service/DSCP (rfc 2474) byte range and mask.  An IP packet
> with IP type of service (ToS) byte value "ip-tos" matches this
> parameter if tos-low<=(ip-tos AND tos-mask)<=tos-high.  If this field
> is omitted, then comparison of the IP packet ToS byte for this entry
> is irrelevant.

I don't think there's any more DSCP-relevant text in 802.16-2004.

Remark that (1) DSCP in Traffic Class is only 6bits and their values 
can't be ordered with semantics "lower to higher",  DSCP is about 
selectors (2) last 2bits can be used for ECN (rfc3168), separately than 
the first 6bits.  Thus classifying on contents with semantics like "a 
higher DSCP may need a higher bandwidth is not relevant.

Also, there's no ToS byte in the IPv6 packet.

> The standard also clearly says that the classification ensures the 
> packet is delivered using the right QoS characteristics.

Can we state that ^ in the draft?  Something like: 802.16MAC
implementation ensures proper classification of packets whose IPv6 
Traffic Class fields require a certain level of priority, bandwidth,
latency.

Once we put that in the draft and the draft becomes a RFC maybe one
comment will be how actually that happens, because the spec doesn't say,
or I don't seem to find that _how_.

> I understand the desire to have an automatic mapping that operates 
> without any configured policy. But in this case we clearly have 
> functionality in the lower layer that is designed for the QoS 
> purpose. We may disagree with that design. But it would be odd if the
>  IETF added its own competing QoS mapping mechanisms on top of it.

I don't find it odd, and I don't disagree with the MAC QoS design, it's
necessary to have QoS mechanisms well adapted to the radio.  And I also
find it necessary for IP to take advantage of it.  Traffic reservation 
with DSCP fields happens on the entire IP path, end-to-end.  But the 
first-hop?

DSCPs are IANA Assigned: http://www.iana.org/assignments/dscp-registry

None of the IANA Assigned DSCP keywords (CS0-7, AF11-43, EF PHB) appear
in the 802.16-2004 spec.

That said, I agree that the mappings I'm proposing aren't yet tested.  I 
haven't even proposed a concrete one.  It may be too early to talk about 
it in this document.

Alex

_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng