Re: [aqm] I-D Action: draft-ietf-aqm-recommendation-04.txt

[Mikael Abrahamsson <[e-mail]>]

On Mon, 25 May 2015, Fred Baker (fred) wrote:

>
>> On May 24, 2015, at 9:31 PM, Mikael Abrahamsson <[e-mail]> wrote:
>>
>> I don't understand the difference between AF1 and CS1. Please elaborate.
>
> RFC 2597: any AF class (there are four rate-based classes, named AFx) has three different quanta (called AFxy) at which drop probability can change. One has a low drop probability if, during a given time interval, one has sent less than some quantum of data. If one has sent more than that but less than a second amount, one has an increased drop probability. If one has sent more than the second but less than a third amount, one has an even more increased drop probability. Crossing that third line, All traffic is presumably dropped.
>
> RFC 3662: assuming one has a priority queuing system, CS1 traffic occupies the lowest priority, and a packet in that queue might be held for at most some time interval or dropped when the queue becomes too deep. The description in the RFC isn't CoDel, but CoDel would work well there.

Ok, thanks Fred and Jonathan, I had a hunch this was implied. For me, the 
TOS field bits are the same, that's why I didn't see the distincton.

I am an operational kind of guy. I think I have a decent idea what people 
do out there in the wild. Let me elaborate a bit more than I have done 
before.

Some routers will (default) take the TOS field (3 bits) and put into 
802.1p bit when doing vlan encapsulation. Some switches will by default do 
802.1p = 0x1 and 0x2 to be lower priority than 0x0 and 0x3 when doing 
queuing.

Some other ISPs will have implemented DSCP, and treats AF[123]x as higher 
priority than BE.

A lot of ISPs will zero at least the TOS field (3 bits) at their edge, 
especially because they have business VPN QoS customers and want to assure 
that these have higher priority QoS-wise compared to Internet traffic 
(where DDOS might occur).

So with above, I don't see how we can incrementally implement either 
scheme. That's why I suggested that we create new DSCP class along the 
existing drop probability, which has the benefit of keeping TOS field=0 
(so if the ISP zeros TOS field they might not zero the last 3 bits, and 
the above DSCP ISP won't have to change all their business customer 
configuration), which will also work for the 802.1p TOS using ISP I 
mentioned first, because it'll work the same as default.

So now an ISP that wants to deploy this new "Internet-wide" BE-lowprio, 
BE-highprio, BE-default scheme can do this incrementally regardless of 
what other QoS scheme they're currently using.

-- 
Mikael Abrahamsson    email: [e-mail]