New: No ECN marking in IPv6

Bugme-new Applied Andrew Morton 5 participants 9 messages May 5, 2011 – May 13, 2011 1 message not in the archive

Subsystems (2)

Networking Network drivers

lore

Share & tools

lore

Andrew Morton

author

2011-05-05 22:43 UTC #1 lore raw

In reply to a message not in the archive

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 20 lines · On Tue, 3 May 2011 20:05:00 GMT [email protected] wrote:

https://bugzilla.kernel.org/show_bug.cgi?id=34322

           Summary: No ECN marking in IPv6
           Product: Networking
           Version: 2.5
    Kernel Version: 2.6.38.4
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: IPV6
        AssignedTo: [email protected]
        ReportedBy: [email protected]
        Regression: No

Hi,

Quoted 9 lines

I'm completely unable to get ECN to work for IPv6. /proc/sys/net/ipv4/tcp_ecn is set to 1 on both sides, and ECN works just fine for IPv4 TCP connections, but when I connect over IPv6 tclass just stays at 0x0, and as far as I'd understood, there should be two bits here set to 10 (like in the diffserv field of IPv4), right?
I do get ECN-echo bits in the TCP header, though (for the initial SYN and SYN/ACK packets).

and

Quoted 8 lines

I looked at the code, and although I don't understand all of it, it looks like e9df2e8fd8fbc95c57dbd1d33dada66c4627b44c (which also brought ECN for IPv6 SCTP) might be the culprit. It seems like TCP_ECN_send() calls INET_ECN_xmit(), which only sets the ECN bit in the IPv4 ToS field (inet_sk(sk)->tos), but after the patch, what's checked is inet6_sk(sk)->tclass, which is a completely different field.
Is the analysis correct? Should the tclass be set as well?

and

Quoted 18 lines

OK, as a quick hack, I did this:
linux-2.6.38.5/include/net/inet_ecn.h 2011-05-04 00:36:52.803377902+0200 renamed from linux-2.6.38.5/include/net/inet_ecn.h 2011-04-14 22:03:56.000000000+0200 +1 -1
@@ -38,7 +38,7 @@
     return outer;
 }
 
-#define    INET_ECN_xmit(sk) do { inet_sk(sk)->tos |= INET_ECN_ECT_0; } while (0)
+#define    INET_ECN_xmit(sk) do { inet_sk(sk)->tos |= INET_ECN_ECT_0; if (inet6_sk(sk) != NULL) inet6_sk(sk)->tclass |= INET_ECN_ECT_0; } while (0)
 #define    INET_ECN_dontxmit(sk) \
     do { inet_sk(sk)->tos &= ~INET_ECN_MASK; } while (0)
 
and now my packets are properly marked with tclass 0x02 (ie., signalling ECN-capable transport, no congestion experienced yet).
I guess this isn't the right way of doing it, but at least it confirms that the lack of setting tclass is part of the problem.

Eric Dumazet

2011-05-06 15:04 UTC #2 lore raw

Quoted 62 lines · Andrew Morton

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 20 lines · On Tue, 3 May 2011 20:05:00 GMT [email protected] wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=34322
           Summary: No ECN marking in IPv6
           Product: Networking
           Version: 2.5
    Kernel Version: 2.6.38.4
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: IPV6
        AssignedTo: [email protected]
        ReportedBy: [email protected]
        Regression: No
Hi,
Quoted 9 lines
I'm completely unable to get ECN to work for IPv6. /proc/sys/net/ipv4/tcp_ecn is set to 1 on both sides, and ECN works just fine for IPv4 TCP connections, but when I connect over IPv6 tclass just stays at 0x0, and as far as I'd understood, there should be two bits here set to 10 (like in the diffserv field of IPv4), right?
I do get ECN-echo bits in the TCP header, though (for the initial SYN and SYN/ACK packets).
and
Quoted 8 lines
I looked at the code, and although I don't understand all of it, it looks like e9df2e8fd8fbc95c57dbd1d33dada66c4627b44c (which also brought ECN for IPv6 SCTP) might be the culprit. It seems like TCP_ECN_send() calls INET_ECN_xmit(), which only sets the ECN bit in the IPv4 ToS field (inet_sk(sk)->tos), but after the patch, what's checked is inet6_sk(sk)->tclass, which is a completely different field.
Is the analysis correct? Should the tclass be set as well?
and
Quoted 13 lines
OK, as a quick hack, I did this:
linux-2.6.38.5/include/net/inet_ecn.h 2011-05-04 00:36:52.803377902+0200 renamed from linux-2.6.38.5/include/net/inet_ecn.h 2011-04-14 22:03:56.000000000+0200 +1 -1
@@ -38,7 +38,7 @@
     return outer;
 }
 
-#define    INET_ECN_xmit(sk) do { inet_sk(sk)->tos |= INET_ECN_ECT_0; } while (0)
+#define    INET_ECN_xmit(sk) do { inet_sk(sk)->tos |= INET_ECN_ECT_0; if (inet6_sk(sk) != NULL) inet6_sk(sk)->tclass |= INET_ECN_ECT_0; } while (0)
 #define    INET_ECN_dontxmit(sk) \
     do { inet_sk(sk)->tos &= ~INET_ECN_MASK; } while (0)
 

Quoted 6 lines

Quoted 5 lines
and now my packets are properly marked with tclass 0x02 (ie., signalling ECN-capable transport, no congestion experienced yet).
I guess this isn't the right way of doing it, but at least it confirms that the lack of setting tclass is part of the problem.

Cc YOSHIFUJI Hideaki <[email protected]>

Hello Steinar

Analysis seems fine, but you also need to change INET_ECN_dontxmit() for retransmitted packets.

Any chance you can refine your patch ?

Thanks !

Steinar H. Gunderson

2011-05-06 17:43 UTC #3 lore raw

Quoted 4 lines · Eric Dumazet

Analysis seems fine, but you also need to change INET_ECN_dontxmit() for retransmitted packets.
Any chance you can refine your patch ?

Sure, but is really checking against NULL the right way of checking for IPv6 sockets? I'd imagined I should have checked address family or something instead...

/* Steinar */

Signature · 1 line

Homepage: http://www.sesse.net/

Eric Dumazet

2011-05-07 09:44 UTC #4 lore raw

From: Steinar H. Gunderson <[email protected]>

Quoted 4 lines · Steinar H. Gunderson

Sure, but is really checking against NULL the right way of checking for IPv6 sockets? I'd imagined I should have checked address family or something instead...

It should be fine.

I cooked for you the official patch and made sure it worked with a RED ECN setup, and one ipv6 tcp xmit.

# tc -s -d qdisc show dev eth1
...
qdisc red 11: parent 1:11 limit 120Kb min 8Kb max 80Kb ecn ewma 2 Plog 21 Scell_log 11
 Sent 114694826 bytes 76446 pkt (dropped 15, overlimits 485 requeues 0) 
 rate 12126Kbit 1011pps backlog 0b 0p requeues 0 
  marked 470 early 15 pdrop 0 other 0

Thanks again !

[PATCH] ipv6: restore correct ECN handling on TCP xmit

Since commit e9df2e8fd8fbc9 (Use appropriate sock tclass setting for routing lookup) we lost ability to properly add ECN codemarks to ipv6 TCP frames.

It seems like TCP_ECN_send() calls INET_ECN_xmit(), which only sets the ECN bit in the IPv4 ToS field (inet_sk(sk)->tos), but after the patch, what's checked is inet6_sk(sk)->tclass, which is a completely different field.

Close bug https://bugzilla.kernel.org/show_bug.cgi?id=34322

[Eric Dumazet] : added the INET_ECN_dontxmit() fix and replace macros by inline functions for clarity.

Signed-off-by Steinar H. Gunderson <[email protected]>

Signed-off-by Eric Dumazet <[email protected]>

Cc YOSHIFUJI Hideaki <[email protected]>

Cc Andrew Morton <[email protected]>

---
 include/net/inet_ecn.h |   16 +++++++++++++---
 1 files changed, 13 insertions(+), 3 deletions(-)

include/net/inet_ecn.h +13 -3

index 88bdd01..2fa8d13 100644
@@ -38,9 +38,19 @@ static inline __u8 INET_ECN_encapsulate(__u8 outer, __u8 inner)
 	return outer;
 }
 
-#define	INET_ECN_xmit(sk) do { inet_sk(sk)->tos |= INET_ECN_ECT_0; } while (0)
-#define	INET_ECN_dontxmit(sk) \
-	do { inet_sk(sk)->tos &= ~INET_ECN_MASK; } while (0)
+static inline void INET_ECN_xmit(struct sock *sk)
+{
+	inet_sk(sk)->tos |= INET_ECN_ECT_0;
+	if (inet6_sk(sk) != NULL)
+		inet6_sk(sk)->tclass |= INET_ECN_ECT_0;
+}
+
+static inline void INET_ECN_dontxmit(struct sock *sk)
+{
+	inet_sk(sk)->tos &= ~INET_ECN_MASK;
+	if (inet6_sk(sk) != NULL)
+		inet6_sk(sk)->tclass &= ~INET_ECN_MASK;
+}
 
 #define IP6_ECN_flow_init(label) do {		\
       (label) &= ~htonl(INET_ECN_MASK << 20);	\

Steinar H. Gunderson

2011-05-07 09:59 UTC #5 lore raw

Quoted 2 lines · Eric Dumazet

I cooked for you the official patch and made sure it worked with a RED ECN setup, and one ipv6 tcp xmit.

Great, thanks :-) This looks good to me.

/* Steinar */

Signature · 1 line

Homepage: http://www.sesse.net/

David Miller

maintainer Applied

2011-05-12 22:52 UTC #6 lore raw

From: "Steinar H. Gunderson" <[email protected]>
Date: Sat, 7 May 2011 11:59:10 +0200

Quoted 5 lines · Eric Dumazet

Quoted 2 lines
I cooked for you the official patch and made sure it worked with a RED ECN setup, and one ipv6 tcp xmit.
Great, thanks :-) This looks good to me.

Applied, thanks everyone.

Steinar H. Gunderson

2011-05-12 22:55 UTC #7 lore raw

Quoted 4 lines · David Miller

Quoted 3 lines
Quoted 2 lines
I cooked for you the official patch and made sure it worked with a RED ECN setup, and one ipv6 tcp xmit.
Great, thanks :-) This looks good to me.
Applied, thanks everyone.

Do you think it would be possible to get it backported to stable kernels? (I've been told getting it into the 2.6.32.x series is the easiest way to get it into Debian stable, and I guess it should be a candidate.)

/* Steinar */

Signature · 1 line

Homepage: http://www.sesse.net/

David Miller

maintainer

2011-05-12 23:00 UTC #8 lore raw

From: "Steinar H. Gunderson" <[email protected]>
Date: Fri, 13 May 2011 00:54:58 +0200

Quoted 9 lines · David Miller

Quoted 4 lines
Quoted 3 lines
Quoted 2 lines
I cooked for you the official patch and made sure it worked with a RED ECN setup, and one ipv6 tcp xmit.
Great, thanks :-) This looks good to me.
Applied, thanks everyone.
Do you think it would be possible to get it backported to stable kernels? (I've been told getting it into the 2.6.32.x series is the easiest way to get it into Debian stable, and I guess it should be a candidate.)

I only submit patches for what [email protected] is actively maintaining which is 2.6.38 right now.

Ben Hutchings

2011-05-13 04:05 UTC #9 lore raw

In reply to Steinar H. Gunderson

Quoted 9 lines · Steinar H. Gunderson

Quoted 4 lines · David Miller
Quoted 3 lines
Quoted 2 lines
I cooked for you the official patch and made sure it worked with a RED ECN setup, and one ipv6 tcp xmit.
Great, thanks :-) This looks good to me.
Applied, thanks everyone.
Do you think it would be possible to get it backported to stable kernels? (I've been told getting it into the 2.6.32.x series is the easiest way to get it into Debian stable, and I guess it should be a candidate.)

If this doesn't apply directly to 2.6.32 then you'll need to prepare the backport and send it to [email protected] with a reference to the commit in mainline.

Ben.

Signature · 2 lines

Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.