Marc, I don't think that's entirely true. I have in previously run networks that remarked all precedence on inbound traffic at the borders to particular values (mostly zero except where policy dictated other) and then accepted the precedence values internally for priority control. Customers were allowed to send contracted amounts of higher precedence traffic, but anything over was marked down (or dropped). So most traffic got best effort, but marked traffic got a relatively guaranteed QOS. This was quite some time ago (2000-2001), so I'm thinking it ought to still be doable today. You have to be diligent in remarking inbound traffic at all boundaries, but it's not rocket science. Regards, -Dorn On Tue, Dec 29, 2009 at 1:17 PM, Sachs, Marcus Hans (Marc) < marcus.sachs@verizon.com> wrote:
Sorry, your original query got lost behind the smoke of my out-of-the-box musings.
My biggest quarrel with any type of IP precedence is that anybody along the chain can set or reset these bits. There is no assurance that a packet's priority will remain at the level set by the originator unless you have some very well disciplined netadmins between sender and receiver who do not fiddle with header bits. If I knew that I could reliably set ToS bits in the IP header and they would remain unchanged then I would add a shim to my local stack that sets all of my flows at the highest priority thereby making my Internet experience a wee bit faster than somebody who leaves those three bits set to 000.
I'm sure others will have widely different opinions.
Marc
-----Original Message----- From: Luca Tosolini [mailto:bit.gossip@chello.nl] Sent: Tuesday, December 29, 2009 1:38 PM To: nanog Subject: Re: ip-precedence for management traffic
Experts, my inquiry was very specific and bounded to the following assumptions: - in-band management - not possible to filter customer traffic, certainly not for somebody else's customer. - IP
In this case diffserv can help prioritize management plane traffic over user traffic. To do that only ipp6 and ipp7 values are available for non user traffic. IPP6 is used by default for routing protocols, that is control plane; so probably it is better not to mess around with it. This leaves to IPP7 for management plane traffic, value that I can not recall of having seen used by any application/protocol.
What is the general opinion about this?
Thanks.
On Tue, 2009-12-29 at 12:02 +0100, Luca Tosolini wrote:
Experts, what is the general opinion of using ipp 7 'network control' for management traffic like: telnet ssh snmp .....
The idea is that ipp 0 1 2 3 4 5 are used for user traffic ipp = 6 is used by default by routing protocols like BGP, OSPF, LDP ...
this leaves out only ipp 7 for management traffic, on the premise that routing and management should not share the same queue and resources.....
Thanks, Luca.