I've been debating whether the TOS header information must be left untouched by an ISP, or if it's ok to zero/(or modify) it for internet traffic. Does anyone know of a BCP that touches on this?
My thoughts was otherwise to zero TOS information incoming on IXes, transits and incoming from customers, question is if customers expect this to be transparent or not.
Reading <http://www.sanog.org/resources/sanog4-kaulgud-qos-tutorial.pdf> it looks like in the Diffserv terminology, it's ok to do whatever one would want.
Any feedback appreciated.
Out of curiosity, what did you hope to accomplish by zeroing that field?
(If you're planning to zero it on ingress to your network, use it for your
own nefairious traffic-engineering purposes, and then re-zero on egress,
*and* your contracts with your customers say it's OK to do it, then it might
be defensible. Maybe. 
Out of curiosity, what did you hope to accomplish by zeroing that field?
IMHO only reason not to zero TOS byte on AS ingress border is that you
explicitly agreed with your neighbour how it is used (what traffic it
can contain, what is the absolute limit they will send that traffic in,
etc.)
I personally don't want to see DoS traffic taking eg. VoIP priority.
I've been also thinking about possibility to differentiate in MPLS EX/TOS
AS internal and AS external traffic and under congestion start to drop
AS external traffic first.
Long ugly history here that I will try to avoid.
IP is end-to-end and you aren't supposed to muck with the packets that are
know what the bits mean to their applications (unless you are one of the
end-points of course) and screwing around with that stuff is a good way to
make people very angry. They're not your packets--leave them alone unless
you are being paid to do otherwise.
Little history here, one of the claims of justification for overwriting
the tos bits with diffserv was that ISPs were supposedly already blanking
out the data. I asked several of the proponents for "just one" example of
this and nobody could produce one. I got a few comments like "I think ISP
X is doing it" but then I would ping a host in that network (with TOS
flags on the ICMP message's packet) and would get the flags back thereby
disproving the anecdotal claims. To my knowledge, nobody was rewriting
this data prior to diffserv, or at least if they did it, they preserved
the original bits somewhere. Dunno about now, but I would imagine a few
providers have fallen for the "everybody else is doing it" invented
justification, and thus became the self-fulfilling claim themselves. I
reference this history in the hope that you will do similar tests--if you
think you can/must do this because of competitive reasons, probe your
competitor networks and see if they're really doing it or not.
It doesn't seem to me that diffserv has picked up momentum and its not
something I hear people whining for. If it were me, I'd limit rewriting
the flag data to clients that requested it, and otherwise try to preserve
the original markings.
While it's true that IP is end-to-end, are fields such as TOS and DSCP meant to be end to end? A case could be argued that they are used by the actual forwarding devices on route in order to make QoS or even routing decisions, and that the end devices shouldn't actually rely on the values of these fields?
For example if ISPA is paying ISPX for a different amount of garenteed (sic) bandwidth than ISPB, how is ISPX meant to mark their traffic in such a way to control them seperately without using DSCP/TOS marking (assuming a non-MPLS network).
Also, if you are using TOS in your network to mark VoIP traffic for garenteed bandwidth then you're pretty much gonna have to zero it on entry into the network or people are going to be able to eat into your VoIP buckets just by setting the right TOS bits.
Seems to me that the actual meaning of TOS and DSCP is utilised on-route and not by the end nodes. What cause could the end nodes have to rely on these values?
Sam
I personally don't want to see DoS traffic taking eg. VoIP priority.
If you're seeing enough DoS traffic that an incorrect TOS is causing an issue
for you, you probably need to find better ways to mitigate that traffic. Remember
that at the *source* end, the DoS traffic is pretty minimal, and at the target
end, I doubt that the TOS labelling will matter in the slightest....
I've been also thinking about possibility to differentiate in MPLS EX/TOS
AS internal and AS external traffic and under congestion start to drop
AS external traffic first.
I'd recommend making sure that either the AS-external traffic isn't
revenue-generating, or the AS-internal traffic generates more revenue than the
external, or that the people who are generating the dropped traffic are a
set of captive customers.
RFC 2474 permits the DSCP to be over-written on ingress to a network. RFC 3168 gives rules for over-writing the ECN flags.
US NCS currently has a filing before the FCC (unless FCC has recently responded) asking for a DSCP value that would be set only by NCS-authorized users, never over-written, and that ISPs would either ignore or observe in order to give that traffic preferential service. Yes, I have made my comments about that too.
I guess the question is why, just because you don't want to offer a specific service, you want to prevent other ISPs from offering a stated service to a user? There are some fairly good-sized ISPs offering services based on the TOS octet. Are you trying to drive users to them? Any customer that is setting EF on VoIP service is certainly expecting that to go end to end.
It used to be that TCP would reset a session if the TOS byte changed in mid-session. That certainly sounds like an end-to-end expectation.
If you're seeing enough DoS traffic that an incorrect TOS is causing an issue
for you, you probably need to find better ways to mitigate that traffic. Remember
that at the *source* end, the DoS traffic is pretty minimal, and at the target
end, I doubt that the TOS labelling will matter in the slightest....
We have lot of 256k, 512k, 1024k and 2048k customer. And we're taking
multiple gigabits of traffic in our AS. How would you pick 256kbps of
offending prec5 stream from that traffic and pick it immediately since the
first packet, so that voice calls are not disturbed?
The 256kbps can be even legal FTP transfer some clever kid decided
to tag with prec5 since he noticed that he can get whole capacity with it.
I'd recommend making sure that either the AS-external traffic isn't
revenue-generating, or the AS-internal traffic generates more revenue than the
external, or that the people who are generating the dropped traffic are a
set of captive customers.
AS-internal is eg. MPLS-VPN and SIP to PSTN-GW, things that corporate
business rely on, I don't care about dropping Internet in favor of keeping
those services running. Congestion should not happen in our network, if it
happens it's most probably intended network disturbance,
The markings may be used on customer networks too, even if they are not
interpreted or processed by intermediary networks (you). I mean, maybe
they are tagging different kinds of database traffic at egress and ingress
so that they can do their own congestion management. Unilaterally
rewriting all of the packets that cross your network imposes unnecessary
penalties on them and is generally rude.
It's also near blackmail--pay us or we'll overwrite your packets.
The problem is opposite, because I want to offer differentiated services
I want to rewrite the TOS byte. If I don't want to offer differentiated
services myself I can leave it untouched.
Users' rarely set DSCP/TOS bits. On the other hand lots of software and
applications, such as Cisco IOS and IP Phones, gratutiously set DSCP/TOS
bits regardless of the network policies. The user may have no easy method
to change the behaivor of the application.
Do you drop out of profile packets because they violate the network's
marking policies?
Or
Do you allow out-of-profile packets ingress by remarking them to meet the
network's policies?
Back in 1999 or early 2000, at GBLX we decided to implement DSCP settings
on transit network traffic.
We found that a remotely small % of TCP traffic abended when the DSCP
were changed within the stream. Understandably, we were concerned.
Given the incompatibility with intended TOS/DSCPs behavior, and the
TCP spec, we 'fixed' TCP in RFC 2873, June, 2000.
Another 'fix' to interpretations of the TCP spec was authored by S. Floyd,
RFC 3360, August, 2002.
-alan
Thus spake Fred Baker (fred@cisco.com)
on or about Wed, May 25, 2005 at 11:18:42AM -0700: