> 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 a
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 sinc
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/
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 disclaim
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 need
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
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
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,
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" fil
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
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 the
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.
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
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 custom
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
> > 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 t
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
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).
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 en
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
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
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 e
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-writt
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
> 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
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 tho
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
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 th
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 zeroin
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 c
30 matches
Mail list logo
