BCP regarding TOS transparancy for internet traffic

Mailman List Mirror (Read Only)
1

Date: Wed, 25 May 2005 12:35:56 -0400
From: "Eric A. Hall" <ehall@ehsco.com>
Sender: owner-nanog@merit.edu

>
> 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.

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
sent by your customers (or worse, sent by *their* customers). You don't
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.

--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/

ESnet is an example. You now have one.

ESnet does QoS with expedited forwarding enabled in our core. To prevent
the unauthorized use of these bits, we have long had a policy of
clearing them at our border for all traffic not authorized for the
expedited service. If we receive packets marked for less than best
effort (scavenger) service, the bits are reset.

I realize we are not a typical provider, but I don't see how any
provider doing diffserv can leave TOS bits untouched and diffserv is a
standard part of our operations. I'll concede that it is probably not
common in commercial networks.

2

Here's the correct model (imo):

1) You are under no obligation to provide expedited service to anybody who
hasn't paid for it. Packets marked with flags for services that haven't
been paid for should simply be ignored.

2) Following therefore, you only need to process flags for customers that
have paid for the expedited service.

3) You should only shuffle the bits around if they ask/need you to do it,
since the customer probably wants to flag their important packets/flows
themselves. The default is to not modify -- only to process differently.

4) The default of no-modify should also apply to non-payinng customers
since they may be flagging their packets for special processing on their
own networks (and they don't want the flags to poof away when the traffic
crosses your hop).

In sum, premium packages are for expedited processing, which is what they
are buying. Rewriting any packets without consent/request is not needed
and unrelated, and is bad mojo in general.

3

4) The default of no-modify should also apply to non-payinng customers
since they may be flagging their packets for special processing on their
own networks (and they don't want the flags to poof away when the traffic
crosses your hop).

Beatiful idea, how in practice do you suggest this is done, how will
my router know if it should just ignore the TOS bytes or do expedited
forwarding as configured for given value of TOS byte?

4

VLANs? Different route paths? Any of a dozen other ways to limit special
processing to the networks that have paid for it and dump everybody else
into the best-effort pool?

5

> Beatiful idea, how in practice do you suggest this is done, how will
> my router know if it should just ignore the TOS bytes or do expedited
> forwarding as configured for given value of TOS byte?

VLANs? Different route paths? Any of a dozen other ways to limit special
processing to the networks that have paid for it and dump everybody else
into the best-effort pool?

Seems to me these are far more complex solutions than simply rewriting
TOS at the borders.

And yes, we also rewrite TOS at the borders for Internet traffic. We
definitely intend to continue doing this.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

6

Sorry I fail to understand this. Could you elaborate with an example?
Let's assume I'm AS1 and 2.0.0.0/16 from AS2 is sending me DSCP CS5, which I
don't want to honor. And 2.1.0.0/16 from AS2 is sending me DSCP CS5, which I
want to honor.
How in practice should I honour 2.0.0.0/16 to every destination in my network
and never honor from 2.1.0.0/16 to any of destinations in my network? My
margins unfortunately don't permit building two paths to each directions.

7

All you are doing is off-loading the complexity to your customers (and
their customers).

What's the point in offering a premium service that doesn't make enough
money to pay for the work required to offer it?

8

So what you are saying is basically that ISPs should NOT offer any premium service at all over their internet access products, and only do so over dedicated provider-based VPNs, be it on L2 or L3 (MPLS/2547)? How about VoIP, should we build a parallell internet for that if we want to actually treat the traffic preferentially? If not, how do you propose we do NOT honor the traffic that we have NOT gotten paid for but that someone has merely tagged with a DSCP they know we will treat better?

I.e. my customer with two offices who run their own IPSec tunnel between, should in other words no longer be able to pay me for improved delivery without buying a full VPN offering from me (which they don't really need, or want)?

/leg

9

If they don't need or want special handling what are they paying for? But
since they are paying for it, perhaps its up to you to figure out how to
deliver on your promise.

And yet, getting somebody to pay for something/nothing (as the case may
be) doesn't come with a license to manhandle everybody else's traffic.

10

I.e. my customer with two offices who run their own IPSec tunnel between,
should in other words no longer be able to pay me for improved delivery
without buying a full VPN offering from me (which they don't really need,
or want)?

If they don't need or want special handling what are they paying for? But
since they are paying for it, perhaps its up to you to figure out how to
deliver on your promise.

But here is what you don't seem to understand - I DO deliver on my promise. Said customer's packets WILL get special handling, my backbone routers will happily put whatever packets they tag with a non-BE DSCP in the appropriate queues as the packet traverses the network. Or if they prefer, we can even tag it FOR them on the access router they are connected to. Where's the offloaded complexity you refer to?

The "general population", who does NOT pay for that privilege, gets the BE-treatment, which is what they pay for. And that requires a rewrite of the DSCP/TOS for said traffic, otherwise how do you prevent packets from the "general population" filling up the queues you have reserved for the customers who pay you more? Rewrite-to-BE is pretty commonplace these days you know.

If I understand you correctly, you are saying this service (which a lot of ISPs offer, and a lot of customers pay them for), has no right to exist, and everyone should go out and buy provider-based VPNs or dedicated L2 connectivity instead. The thing is - not all customers WANT a provider-based VPN. And if customers want something, you can be sure providers are selling it.

And yet, getting somebody to pay for something/nothing (as the case may
be) doesn't come with a license to manhandle everybody else's traffic.

Sure it does. There is this new thing called the marketplace. If you pay me for special treatment, I will give you special treatment. If you don't, then I will carry your traffic according to the terms in your contract, which, in the case of best-effort service, is best-effort service. If you are unhappy with the service, you can buy a different service, or choose a different supplier.

That being said, I don't believe ANYONE has ever complained about their packets being "manhandled" by the DSCP being rewritten to BE - even customers seem to understand that "you get what you pay for", and special treatment in the form of QoS costs more money.

/leg

11

One way is to null MPLS EXP for BE traffic and do QoS on that, and then set EXP bits to something different for non-BE traffic. That leaves DSCP transparent end-to-end on the IP packet.

But as I have read the discussion I do think that null:ing DSCP for all BE traffic is the way to go, and keep the clean copy of DSCP to EXP within the network for the customers paying for preferred treatment (or whatever service you want to prioritize).

12

If existing software applications only set the DSCP values when the user
asked, it wouldn't be as much of a problem. However some software
programmers gratuitously set DSCP/TOS values even when the user didn't
want it.

If you drop packets from unauthorized DSCP/TOS users you will break many
applications for users which are unable to change the behaivor of their
application.

On the other hand, if you clear DSCP/TOS bits from unauthorized users
you will continue to provide basic service for those users.

Which is better?

  Dropping the packets with unauthorized DSCP/TOS bits?
  Forwarding the packets with cleared DSCP/TOS bits?

13

The "general population", who does NOT pay for that privilege, gets the
BE-treatment, which is what they pay for.

Overwriting the tos flags is not "best effort", it is "degraded service"

Oh sure, it might be BE on your specific network, but all the user sees is
loss of signal. IE, it was degraded.

customers seem to understand that "you get what you pay for", and special
treatment in the form of QoS costs more money.

Again, you are under no obligation to do anything with QoS flags from
non-paying customers, and I'm not advocating for anybody to get a free
ride here. Ignore the markings, but leave them alone too.

14

Are you suggesting every router along the path needs to have a table
lookup of every customer and which DSCP/TOS bits are valid for packets
to or from that customer and which DSCP/TOS bits should be ignored.
Diffserv is hop-by-hop, with each hop making a choice.

Do you really think this scales well in a core network?

If you want bit streams: TDM, ATM or Frame-Relay works well. But in
the IP world, packets may be fragemented by intermediate nodes, TTL
values are decremented, ECN bits are changed. Packet headers are
changed on every packet passing through an IP network.

15

Feasibility can be empirically demonstrated easily enough.

Which of your competitors' networks do you want me to ping probe with ToS
flags enabled?

[Although I suppose I should add the disclaimer that things have changed
for the worse in this regard since diffserv overtook the tos flags so
maybe you can win this easily now. Alas.]

My post-count for the day (and this topic) is now at max.

16

Yes please. HOW? That is what I have been asking since the first post - how do you suggest honoring DSCP for paying customers AND ignoring them for non-paying customers (while leaving them alone) - WITHOUT putting the traffic onto "dedicated" networks (be it L2 or L3)? If you can answer that single question I'll shut up and run along to implement it. (And keep in mind not all providers have a full MPLS core, so let's stick to normal IP forwarding please).

/leg

17

Overwriting the tos flags is not "best effort", it is "degraded service"

So how do you propose to control the use of TOS flags within a network? If
I have an application that receives specific treatment because of its TOS
flags, I need to prevent non-compliant traffic from using this TOS flag at
other ingress points. This requires either dropping that traffic or
rewriting the flag.