On Mon, 25 May 2015, Fred Baker (fred) wrote:
On May 24, 2015, at 9:31 PM, Mikael Abrahamsson <[email protected]> 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: [email protected]
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
