. This standard will
> require passing ECN and DSCP markings across network boundaries. As a result,
> we are interested in your perspective on this and in how you handle markings
> today. We have a short survey that should only take a few minutes to
> complete. Take the survey at https://fo
I would argue that question 9 needs an option of "Both".
Secondly, two additional good questions to ask would be: are the ECN
values presently being treated as RFC3168?
Are the ECN values being modified by any AQM implementations (WRED,
FQ_CODEL, etc) on any switch or router in transit?
Hi – Comcast is working on the implementation of ultra-low latency networking,
leveraging the IETF’s upcoming L4S standard. This standard will require passing
ECN and DSCP markings across network boundaries. As a result, we are interested
in your perspective on this and in how you handle
--- ra...@psg.com wrote:
lots of good research lit on catchment topology of anycasted
dns, which is very non-local.
---
For the others here that didn't know what that is and are
curious. I couldn't take it and just had to know... :)
On Thu, Nov 14, 2019 at 1:10 AM Bill Woodcock wrote:
> > On Nov 14, 2019, at 7:39 AM, Anoop Ghanwani
wrote:
> > RFC 7094 (https://tools.ietf.org/html/rfc7094) describes the pitfalls &
risks of using TCP with an anycast address. It recognizes that there are
valid use cases for it, though.
> >
>>> RFC 7094 (https://tools.ietf.org/html/rfc7094) describes the pitfalls
>>> & risks of using TCP with an anycast address.
>>
>> and two decades of operational experience are that prudent deployments
>> just work.
>
> I agree with Bill/Randy here... this does just work if you understand
> your
On Fri, Nov 15, 2019 at 1:54 AM Randy Bush wrote:
>
> > RFC 7094 (https://tools.ietf.org/html/rfc7094) describes the pitfalls
> > & risks of using TCP with an anycast address.
>
> and two decades of operational experience are that prudent deployments
> just work.
I agree with Bill/Randy here...
> RFC 7094 (https://tools.ietf.org/html/rfc7094) describes the pitfalls
> & risks of using TCP with an anycast address.
and two decades of operational experience are that prudent deployments
just work.
randy
I do plan to write this whole story up as a blog post, BTW.
Apart from just being a nice "battle story" I also think it's important
to get more visibility into these kinds of issues. I've mostly been
interested in issues related to ECN in general, but its interaction with
anycast is certainl
Baldur Norddahl writes:
> I am testing disabling our use of ECMP as it is not strictly necessary
> and we are moving to a new platform anyway. Waiting for feedback from
> the customer to hear if this fixes the issue.
Which I can confirm that it does. Thank you for the speedy resolution! :)
On Wed, 13 Nov 2019 at 22:57, Lukas Tribus wrote:
> In fact I believe everything beyond the 5-tuple is just a bad idea to
> base your hash on. Here are some examples (not quite as straight
> forward than the TOS/ECN case here):
ACK.
> TTL:
> https://mailman.nanog.org/piper
> On Nov 14, 2019, at 7:39 AM, Anoop Ghanwani wrote:
> RFC 7094 (https://tools.ietf.org/html/rfc7094) describes the pitfalls & risks
> of using TCP with an anycast address. It recognizes that there are valid use
> cases for it, though.
> Specifically, section 3.1 says this:
>Most
h
> calculation, whole TOS byte should not be used as discreet flow SHOULD
> have unique ECN bits during congestion. Toke has diagnosed the problem
> correctly, solution is to remove TOS from ECMP hash calculation.
Agreed. This also goes for the other bits, so whole byte must be excluded.
b but not in the global
Internet.
>>>
On Wed, Nov 13, 2019 at 3:33 PM Warren Kumari wrote:
> On Thu, Nov 14, 2019 at 12:25 AM Matt Corallo wrote:
> >
> > This sounds like a bug on Cloudflare’s end (cause trying to do anycast
> TCP is... out of spec to say the least), not a
On Thu, Nov 14, 2019 at 12:25 AM Matt Corallo wrote:
>
> This sounds like a bug on Cloudflare’s end (cause trying to do anycast TCP
> is... out of spec to say the least), not a bug in ECN/ECMP.
Err. I really don't think that there is any sort of spec that
covers that :-P
Usin
Hello,
On Wed, Nov 13, 2019 at 8:35 PM Saku Ytti wrote:
>
> On Wed, 13 Nov 2019 at 18:27, Matt Corallo wrote:
>
> > This sounds like a bug on Cloudflare’s end (cause trying to do anycast TCP
> > is... out of spec to say the least), not a bug in ECN/ECMP.
>
> N
On Wed, Nov 13, 2019 at 11:36 AM Saku Ytti wrote:
> On Wed, 13 Nov 2019 at 18:27, Matt Corallo wrote:
> > This sounds like a bug on Cloudflare’s end (cause trying to do anycast
> TCP is... out of spec to say the least), not a bug in ECN/ECMP.
>
> Not true. Hash result should
visible impacted user.
Owen
> On Nov 13, 2019, at 09:19 , Anoop Ghanwani wrote:
>
> Not to condone what cloudflare is doing, but...
>
> An ECN connection will have different bits on various packets for the
> duration of the connection -- pure ACKs (ACKs not piggybacking on
On Wed, 13 Nov 2019 at 18:27, Matt Corallo wrote:
> This sounds like a bug on Cloudflare’s end (cause trying to do anycast TCP
> is... out of spec to say the least), not a bug in ECN/ECMP.
Not true. Hash result should indicate discreet flow, more importantly
discreet flow should not
On 13 November 2019 17:20:18 CET, Matt Corallo wrote:
>This sounds like a bug on Cloudflare’s end (cause trying to do anycast
>TCP is... out of spec to say the least), not a bug in ECN/ECMP.
Even without anycast, an ECMP shouldn't hash on the ECN bits. Doing so will
split the flo
that the
equipment is doing hashing based on the ECN bits. I just turned off ECMP so
the customer can test. If it works we will either let ECMP stay off or move
the customer to the new platform.
Regards,
Baldur
On Wed, Nov 13, 2019 at 7:30 PM Mikael Abrahamsson wrote:
> On Wed, 13 Nov 2019, Bal
ld be very interesting if your could share what equipment you're
using that is doing ECMP hashing based on ECN bits. That vendor needs to
fix that or people should avoid their devices.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
s sounds like a bug on Cloudflare’s end (cause trying to do anycast
>> TCP is... out of spec to say the least), not a bug in ECN/ECMP.
>> >
>> > > On Nov 13, 2019, at 11:07, Toke Høiland-Jørgensen via NANOG <
>> nanog@nanog.org> wrote:
>> > >
>&
2019 17:20:18 CET, Matt Corallo wrote:
This sounds like a bug on Cloudflare’s end (cause trying to do anycast
TCP is... out of spec to say the least), not a bug in ECN/ECMP.
Even without anycast, an ECMP shouldn't hash on the ECN bits. Doing so will
split the flow over multiple paths; avoiding
ve.nanog.org/meetings/nanog37/presentations/matt.levine.pdf
>
> On Wed, Nov 13, 2019 at 10:24 AM Matt Corallo wrote:
> >
> > This sounds like a bug on Cloudflare’s end (cause trying to do anycast
> TCP is... out of spec to say the least), not a bug in ECN/ECMP.
> >
> >
Not to condone what cloudflare is doing, but...
An ECN connection will have different bits on various packets for the
duration of the connection -- pure ACKs (ACKs not piggybacking on data)
will have the ECN bits as 00b, while all other packets will have either
01b, 10b (when no congestion
ec to say the least), not a bug in ECN/ECMP.
>
> > On Nov 13, 2019, at 11:07, Toke Høiland-Jørgensen via NANOG
> > wrote:
> >
> >
> >>
> >> Hello
> >>
> >> I have a customer that believes my network has a ECN problem. We do
> >&
; This sounds like a bug on Cloudflare’s end (cause trying to do anycast
>> TCP is... out of spec to say the least), not a bug in ECN/ECMP.
>
> Even without anycast, an ECMP shouldn't hash on the ECN bits. Doing so will
> split the flow over multiple paths; avoiding that is the
This sounds like a bug on Cloudflare’s end (cause trying to do anycast TCP
is... out of spec to say the least), not a bug in ECN/ECMP.
> On Nov 13, 2019, at 11:07, Toke Høiland-Jørgensen via NANOG
> wrote:
>
>
>>
>> Hello
>>
>> I have a customer that b
> Hello
>
> I have a customer that believes my network has a ECN problem. We do
> not, we just move packets. But how do I prove it?
>
> Is there a tool that checks for ECN trouble? Ideally something I could
> run on the NLNOG Ring network.
>
> I believe it likely
> On Nov 11, 2019, at 05:01 , Baldur Norddahl wrote:
>
> Hello
>
> I have a customer that believes my network has a ECN problem. We do not, we
> just move packets. But how do I prove it?
Are you saying that none of your routers support ECN or that you think ECN only
ap
Hello
I have a customer that believes my network has a ECN problem. We do not,
we just move packets. But how do I prove it?
Is there a tool that checks for ECN trouble? Ideally something I could
run on the NLNOG Ring network.
I believe it likely that it is the destination that has
> On 28 Dec 2018, at 2:49 pm, valdis.kletni...@vt.edu wrote:
>
> On Fri, 28 Dec 2018 13:35:04 +1100, Mark Andrews said:
>> There are major operators that still have STUPID firewall settings
>> in front of DNS servers that drop SYN packets with ECE and CWR set
On Fri, 28 Dec 2018 13:35:04 +1100, Mark Andrews said:
> There are major operators that still have STUPID firewall settings
> in front of DNS servers that drop SYN packets with ECE and CWR set
> 17 years after ECN was specified.
Time to name-n-shame?
There are major operators that still have STUPID firewall settings
in front of DNS servers that drop SYN packets with ECE and CWR set
17 years after ECN was specified.
Do you really want to add a second to EVERY DNS lookup that needs
to use TCP? Modern OS actually attempt to use ECN by default
On Sat, Jun 13, 2015 at 06:20:31PM +0200, Mikael Abrahamsson wrote:
Hi,
I just want to bring to your attention the below talk (I am too lazy to
re-write the whole email for this slightly different audience).
Takeaway:
We'll see a lot of ECN enabled traffic in a few months
for this slightly different audience).
Takeaway:
We'll see a lot of ECN enabled traffic in a few months. This shouldn't be a
problem. I've been doing it to all my machines for 3-5 years without ill
effects.
you'll also find all the networks that use the entire tos field as part
of the hash key... that's
On 6/15/15 6:19 AM, Jared Mauch wrote:
On Sat, Jun 13, 2015 at 06:20:31PM +0200, Mikael Abrahamsson wrote:
Hi,
I just want to bring to your attention the below talk (I am too lazy to
re-write the whole email for this slightly different audience).
Takeaway:
We'll see a lot of ECN enabled
Hi,
I just want to bring to your attention the below talk (I am too lazy to
re-write the whole email for this slightly different audience).
Takeaway:
We'll see a lot of ECN enabled traffic in a few months. This shouldn't be
a problem. I've been doing it to all my machines for 3-5 years
On Fri, 7 Nov 2008, [EMAIL PROTECTED] wrote:
On Fri, 07 Nov 2008 08:27:58 +0100, Mikael Abrahamsson said:
for ECN to actually be useful, we (the ISPs) have to turn this option on
in the routers as well. Is anyone doing this today? What vendors support
it?
The only thing that's *required
When I thought about it, the IP core (10G links etc) first came to mind,
and there it's fairly easy to roll out (since I guess a lot of us do
WRED already), but what about on slower links? Would it make sense to
have our DSLAMs do this? What about DSL/cable modems (well, vendors
should first
David Freedman [EMAIL PROTECTED] writes:
Implementing this in an MPLS core is not an easy task, you can really
only do this on the edge, when the MPLS labelled packet arrives at an
LSR, we don't know if it contains a TCP segment or not (fancy deep h/w
implementations excluded), all we know is
Interesting , I hadn't followed this since draft-ietf-mpls-ecn-00,
, I eagerly await a vendor implementation :)
Dave.
Bjørn Mork wrote:
David Freedman [EMAIL PROTECTED] writes:
Implementing this in an MPLS core is not an easy task, you can really
only do this on the edge, when the MPLS
is that , if there is congestion,
we can discard it based on the EXP bits in the shim.
I did some more checking and neither 12000 (IOS) nor CRS-1 seems to
support WRED with ECN (at least the command doesn't show when I create a
policy-map), so I'm going to ping my Cisco SE and hear about what's
On Fri, 07 Nov 2008 08:27:58 +0100, Mikael Abrahamsson said:
for ECN to actually be useful, we (the ISPs) have to turn this option on
in the routers as well. Is anyone doing this today? What vendors support
it?
The only thing that's *required* for it to help is that the routers and
firewalls
Hi,
On LKML (Linux Kernel Mailing List) there is talk
http://lkml.org/lkml/2008/11/4/151 about shipping the Linux kernel with
ECN turned on by default (it was on by default a few years back but that
change was reverted due to too many sites dropping ECN enabled SYNs).
Recent investigations
46 matches
Mail list logo
