From: Stephen Hemminger <shemminger@vyatta•com>
To: Eric Dumazet <eric.dumazet@gmail•com>
Cc: Chris Wright <chrisw@redhat•com>,
David Miller <davem@davemloft•net>,
netdev@vger•kernel.org
Subject: Re: [RFC] gre: conform to RFC6040 ECN progogation
Date: Mon, 24 Sep 2012 15:30:13 -0700 [thread overview]
Message-ID: <20120924153013.553f0b76@nehalam.linuxnetplumber.net> (raw)
In-Reply-To: <1348525536.26828.1885.camel@edumazet-glaptop>
On Tue, 25 Sep 2012 00:25:36 +0200
Eric Dumazet <eric.dumazet@gmail•com> wrote:
> On Mon, 2012-09-24 at 14:44 -0700, Stephen Hemminger wrote:
> > Linux GRE was likely written before this RFC and therefore does not
> > conform to one of the rules in Section 4.2. Default Tunnel Egress Behaviour.
> >
> > The new code addresses:
> > o If the inner ECN field is Not-ECT, the decapsulator MUST NOT
> > propagate any other ECN codepoint onwards. This is because the
> > inner Not-ECT marking is set by transports that rely on dropped
> > packets as an indication of congestion and would not understand or
> > respond to any other ECN codepoint [RFC4774]. Specifically:
> >
> > * If the inner ECN field is Not-ECT and the outer ECN field is
> > CE, the decapsulator MUST drop the packet.
> >
> > * If the inner ECN field is Not-ECT and the outer ECN field is
> > Not-ECT, ECT(0), or ECT(1), the decapsulator MUST forward the
> > outgoing packet with the ECN field cleared to Not-ECT.
> >
> > This was caught by Chris Wright while reviewing VXLAN.
> > This code has not been tested with real ECN through tunnel.
> >
> > Signed-off-by: Stephen Hemminger <shemminger@vyatta•com>
>
> It seems dangerous to me without any logging ?
>
> One could argue that the outer ECN field should not be CE if the inner
> was Not-ECT
>
> It means :
> 1) the encapsulator set ECT(0), or ECT(1) and a congestioned hop set CE
> 2) the encapsulator set CE
>
> 1) or 2) while inner was not-ECT (!!!)
>
> If a router does such a thing, we should log a message to help
> diagnostics.
>
> By the way other tunnels probably have the same issues.
Logging is a bad idea in this case since the tunnel might be from a remote
host/protocol and the log would be filled with crap.
The tunnels in general do need to have rx_dropped counter, but it looks
like that isn't being done right either.
next prev parent reply other threads:[~2012-09-24 22:30 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-24 18:43 [PATCH net-next 0/3] VXLAN driver Stephen Hemminger
2012-09-24 18:43 ` [PATCH net-next 1/3] netlink: add attributes to fdb interface Stephen Hemminger
2012-09-24 18:43 ` [PATCH net-next 2/3] igmp: export symbol ip_mc_leave_group Stephen Hemminger
2012-09-24 18:43 ` [PATCH net-next 3/3] vxlan: virtual extensible lan Stephen Hemminger
2012-09-24 19:33 ` Eric Dumazet
2012-09-24 19:39 ` Eric Dumazet
2012-09-24 19:46 ` [PATCHv2 " Stephen Hemminger
2012-09-24 19:55 ` Eric Dumazet
2012-09-24 20:02 ` [PATCHv3 " Stephen Hemminger
2012-09-24 20:24 ` John Fastabend
2012-09-24 20:27 ` Stephen Hemminger
2012-09-24 23:17 ` John Fastabend
2012-09-24 20:09 ` [PATCHv2 " Eric Dumazet
2012-09-24 20:26 ` Stephen Hemminger
2012-09-24 20:41 ` Eric Dumazet
2012-09-24 20:58 ` [PATCH " Chris Wright
2012-09-24 21:11 ` Stephen Hemminger
2012-09-24 21:22 ` Chris Wright
2012-09-24 21:44 ` [RFC] gre: conform to RFC6040 ECN progogation Stephen Hemminger
2012-09-24 22:25 ` Eric Dumazet
2012-09-24 22:30 ` Stephen Hemminger [this message]
2012-09-25 5:17 ` Eric Dumazet
2012-10-01 15:55 ` Ben Hutchings
2012-10-01 15:56 ` Stephen Hemminger
2012-10-01 16:49 ` Ben Hutchings
2012-10-01 17:13 ` Eric Dumazet
2012-10-01 21:21 ` Stephen Hemminger
2012-09-24 21:50 ` [PATCHv4 net-next] vxlan: virtual extensible lan Stephen Hemminger
2012-09-25 21:55 ` Jesse Gross
2012-09-25 22:03 ` Stephen Hemminger
2012-09-25 22:09 ` [PATCHv5 " Stephen Hemminger
2012-09-27 22:47 ` David Miller
2012-09-27 23:00 ` Stephen Hemminger
2012-09-27 23:12 ` David Miller
2012-10-01 20:57 ` [PATCHv6 " Stephen Hemminger
2012-10-01 22:07 ` David Miller
2012-10-01 22:23 ` Stephen Hemminger
2012-10-01 22:30 ` Stephen Hemminger
2012-10-01 22:34 ` David Miller
[not found] ` <20121001140206.2bbf9c41@nehalam.linuxnetplumber.net>
2012-10-01 21:02 ` [PATCH 2/2] iproute2: manage VXLAN forwarding entries Stephen Hemminger
2012-10-01 21:02 ` [PATCH 1/2] iproute2: vxlan support Stephen Hemminger
2012-09-26 4:36 ` [PATCHv4 net-next] vxlan: virtual extensible lan Stephen Hemminger
2012-09-27 17:20 ` Jesse Gross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120924153013.553f0b76@nehalam.linuxnetplumber.net \
--to=shemminger@vyatta$(echo .)com \
--cc=chrisw@redhat$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox