|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: BCP regarding TOS transparancy for internet traffic
> Date: Wed, 25 May 2005 12:35:56 -0400 > From: "Eric A. Hall" <[email protected]> > Sender: [email protected] > > > > On 5/25/2005 7:08 AM, Mikael Abrahamsson wrote: > > > > 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. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [email protected] Phone: +1 510 486-8634
|