I must say, that seems not terribly sporting. :-) Seriously, I would expect that most public Internet carriers, unless you paid them extra fees to pay attention to the DSCP markings, would completely ignore them and treat it all as best-effort traffic, right up to and including the last-mile circuit that should be the congestion point at which QoS would be most useful to differentiate. I don't think it would be the stated policy of any public ISP to drop other-than-zero-marked packets, especially if it's a transit somewhere that's out of reach of either you or the other customer you're trying to reach. But I know from personal experience that some pieces of Ethernet switch gear can have policies, even at Layer 2, which affect traffic in ways that were not obvious when the human engineers deployed them. I ran into one such problem while deploying a straight-up Internet service to a customer on some GPON gear, and I used a built-in filter to select traffic on a VLAN basis, but I didn't realize that the filter also (unconditionally) matched on Layer 2 QoS markings (802.1p in the VLAN tag) at the same time. And my core Ethernet switch had QoS globally enabled, which meant that it was snooping at the Layer 3 DSCP tag and adapting it (dividing by 8, basically) and placing it into the 802.1p field on the way out the trunk port to the GPON gear. This didn't affect anything until the customer started using a remote backup service -- Mozy, I believe -- which, in a lame attempt to obtain better transit "for free" from ISPs who accidentally pay attention to markings, marked its own HTTPS traffic higher than zero. So my customer could reach anyplace on the Internet except for this backup service -- pings to them worked, but starting a Web session or a backup to the same exact IP address would return no packets. And when I tried from our core (not going through the GPON), it worked perfectly. It was a bit of a head-scratcher until we tcpdump'ed the traffic and looked at it carefully. I assume the same thing would have happened had one of my customers tried to use a SIP VoIP carrier through our Internet. So, in short, I would guess that your upstream's dropping problem was *probably* accidental rather than intentional, and if you can bring it to the attention of the right people at that ISP, they'd probably be grateful. -- Jeff Saxe Blue Ridge InternetWorks Charlottesville, VA ________________________________________ From: Jesse McGraw [jlmcgraw@gmail.com] Sent: Friday, September 02, 2011 10:24 AM To: nanog@nanog.org Subject: Silently dropping QoS marked packets on the greater Internet I've recently run into a hard-to-troubleshoot issue where, somewhere out in the greater Internet, someone was silently dropping packets from my company that happened to be marked with DSCP AF21. I'd fully expect others to either ignore these markings or zero them out but just silently dropping them seems unnecessary. So, how do you guys treat marked packets that come into/through your networks?