BCP regarding TOS transparancy for internet traffic
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. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Wed, 25 May 2005 13:08:29 +0200, Mikael Abrahamsson said:
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.
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. ;)
On (2005-05-25 11:49 -0400), Valdis.Kletnieks@vt.edu wrote:
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.
(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. ;)
-- ++ytti
On Wed, 25 May 2005 18:59:51 +0300, Saku Ytti said:
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. ;)
On (2005-05-25 14:15 -0400), Valdis.Kletnieks@vt.edu wrote:
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, -- ++ytti
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/
On Wed, 25 May 2005, Eric A. Hall wrote:
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.
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
On May 25, 2005, at 10:39 AM, Sam Stickland wrote:
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?
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.
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:
On May 25, 2005, at 10:39 AM, Sam Stickland wrote:
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?
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.
On 5/25/2005 1:39 PM, Sam Stickland wrote:
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?
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. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Date: Wed, 25 May 2005 12:35:56 -0400 From: "Eric A. Hall" <ehall@ehsco.com> Sender: owner-nanog@merit.edu
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: oberman@es.net Phone: +1 510 486-8634
On 5/25/2005 1:54 PM, Kevin Oberman wrote:
Date: Wed, 25 May 2005 12:35:56 -0400 From: "Eric A. Hall" <ehall@ehsco.com>
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.
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.
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. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On (2005-05-25 14:44 -0400), Eric A. Hall wrote:
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?
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.
-- ++ytti
On 5/25/2005 2:50 PM, Saku Ytti wrote:
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? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On (2005-05-25 15:06 -0400), Eric A. Hall wrote:
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?
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. -- ++ytti
On Wed, 25 May 2005, Eric A. Hall wrote:
On 5/25/2005 2:50 PM, Saku Ytti wrote:
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?
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
On 5/25/2005 3:42 PM, Lars Erik Gullerud wrote:
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. 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. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On Wed, 25 May 2005, Eric A. Hall wrote:
On 5/25/2005 3:42 PM, Lars Erik Gullerud wrote:
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
On Wed, 25 May 2005, Lars Erik Gullerud wrote:
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
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). -- Mikael Abrahamsson email: swmike@swm.pp.se
On 5/25/2005 4:27 PM, Lars Erik Gullerud wrote:
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. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On Wed, 25 May 2005, Eric A. Hall wrote:
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.
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.
On 5/25/2005 9:06 PM, Sean Donelan wrote:
Do you really think this scales well in a core network?
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. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On Wed, 25 May 2005, Eric A. Hall wrote:
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.
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
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.
On Wed, 25 May 2005, Eric A. Hall wrote:
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.
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?
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. On May 25, 2005, at 4: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.
-- Mikael Abrahamsson email: swmike@swm.pp.se
On (2005-05-25 11:16 -0700), Fred Baker wrote:
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.
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. -- ++ytti
On Wed, 25 May 2005, Fred Baker wrote:
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.
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?
participants (11)
-
Adi Linden -
Alan Hannan -
Eric A. Hall -
Fred Baker -
Kevin Oberman -
Lars Erik Gullerud -
Mikael Abrahamsson -
Saku Ytti -
Sam Stickland -
Sean Donelan -
Valdis.Kletnieks＠vt.edu