Re: BCP regarding TOS transparancy for internet traffic
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.
Re: BCP regarding TOS transparancy for internet traffic
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. ;) pgpzrIZjryqQt.pgp Description: PGP signature
Re: BCP regarding TOS transparancy for internet traffic
On (2005-05-25 11:49 -0400), [EMAIL PROTECTED] 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
Re: BCP regarding TOS transparancy for internet traffic
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. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: BCP regarding TOS transparancy for internet traffic
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
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. Hallhttp://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
Re: BCP regarding TOS transparancy for internet traffic
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. ;) pgpHV2ANB953q.pgp Description: PGP signature
Re: BCP regarding TOS transparancy for internet traffic
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 Abrahamssonemail: [EMAIL PROTECTED]
Re: BCP regarding TOS transparancy for internet traffic
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.
Re: BCP regarding TOS transparancy for internet traffic
On (2005-05-25 14:15 -0400), [EMAIL PROTECTED] 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
Re: BCP regarding TOS transparancy for internet traffic
On 5/25/2005 1:54 PM, Kevin Oberman wrote: Date: Wed, 25 May 2005 12:35:56 -0400 From: Eric A. Hall [EMAIL PROTECTED] 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. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: BCP regarding TOS transparancy for internet traffic
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. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: BCP regarding TOS transparancy for internet traffic
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
Re: BCP regarding TOS transparancy for internet traffic
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. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: BCP regarding TOS transparancy for internet traffic
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, [EMAIL PROTECTED]
Re: BCP regarding TOS transparancy for internet traffic
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
Re: BCP regarding TOS transparancy for internet traffic
On 5/25/2005 3:11 PM, [EMAIL PROTECTED] wrote: 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. 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? -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: BCP regarding TOS transparancy for internet traffic
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
Re: BCP regarding TOS transparancy for internet traffic
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
Re: BCP regarding TOS transparancy for internet traffic
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. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: BCP regarding TOS transparancy for internet traffic
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
Re: BCP regarding TOS transparancy for internet traffic
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 Abrahamssonemail: [EMAIL PROTECTED]
Re: BCP regarding TOS transparancy for internet traffic
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?
Re: BCP regarding TOS transparancy for internet traffic
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?
Re: BCP regarding TOS transparancy for internet traffic
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. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: BCP regarding TOS transparancy for internet traffic
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.
Re: BCP regarding TOS transparancy for internet traffic
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. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
