From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <hannes@stressinduktion.org>
Received: from order.stressinduktion.org (order.stressinduktion.org
	[87.106.68.36])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "order.stressinduktion.org",
	Issuer "order.stressinduktion.org" (not verified))
	by huchra.bufferbloat.net (Postfix) with ESMTPS id B938A208AAD
	for <bloat@lists.bufferbloat.net>; Wed, 26 Dec 2012 18:37:31 -0800 (PST)
Received: by order.stressinduktion.org (Postfix, from userid 500)
	id ABD8C1A0CDA8; Thu, 27 Dec 2012 03:37:28 +0100 (CET)
Date: Thu, 27 Dec 2012 03:37:28 +0100
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: bloat@lists.bufferbloat.net
Message-ID: <20121227023728.GB19548@order.stressinduktion.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Subject: [Bloat] enabling outgoing tcp-ecn by default for ipv6 links
X-BeenThere: bloat@lists.bufferbloat.net
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: General list for discussing Bufferbloat <bloat.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/bloat>,
	<mailto:bloat-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/bloat>
List-Post: <mailto:bloat@lists.bufferbloat.net>
List-Help: <mailto:bloat-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/bloat>,
	<mailto:bloat-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Thu, 27 Dec 2012 02:37:32 -0000

Hello!

I am thinking about advancing the ipv4/tcp_ecn knob in linux to
distinguish between ipv4 and ipv6 transport and enable ecn signaling
on outgoing ipv6 connections by default (for me, at least). I am
currently doing so with the help of iptables (echo 1 > tcp_ecn and -j
ECN --ecn-tcp-remove).

Currently linux does only respond to ecn signaling but does not actively
try to signal ecn capabilities by default because of the high(?) fail rate
of connections in ipv4 land. I wonder if this situation has improved in
ipv6 world because I assume most providers have upgraded their gear in
recent times to support this shiny new protocol.

Does someone know about recent data if such a change would be reasonable?

Btw, has someone looked at RFC5562 - Adding Explicit Congestion
Notification (ECN) Capability to TCP's SYN/ACK Packets;
experimental? Adam Langley has provided a patch for linux enabling ecn on
syn/ack packets some while ago[1].  This seems to be a nice addition but
I fear for new problems arising because of buggy routers. Perhaps after the
retransmit of the initial syn without the ecn-capable codepoint one could
mark this connection as non-ecn compatible in the destination cache to
reduce further latencies on follow-up syns (kind of path ecn discovery).

Greetings,

  Hannes

[1] https://www.ietf.org/mail-archive/web/tcpm/current/msg03988.html