[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1336158359.3752.382.camel@edumazet-glaptop>
Date: Fri, 04 May 2012 21:05:59 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Rick Jones <rick.jones2@...com>
Cc: David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
Perry Lorier <perryl@...gle.com>,
Matt Mathis <mattmathis@...gle.com>,
Yuchung Cheng <ycheng@...gle.com>,
Neal Cardwell <ncardwell@...gle.com>,
Tom Herbert <therbert@...gle.com>,
Wilmer van der Gaast <wilmer@...gle.com>,
Dave Täht <dave.taht@...ferbloat.net>,
Ankur Jain <jankur@...gle.com>
Subject: Re: [PATCH net-next] tcp: be more strict before accepting ECN
negociation
On Fri, 2012-05-04 at 11:48 -0700, Rick Jones wrote:
> On 05/04/2012 11:23 AM, Eric Dumazet wrote:
> > On Fri, 2012-05-04 at 11:09 -0700, Rick Jones wrote:
> >> What sort of networks were these? Any chance it was some sort of
> >> attempt to add ECN to FastOpen?
> >
> > Nothing to do with fastopen.
> >
> > Just take a look at a random http server and sample all SYN packets it
> > receives.
> >
> > Some of them have TOS bits 0 or 1 set, or even both bits set.
>
> I'll fire-up tcpdump on netperf.org:
>
> tcpdump -i eth0 -vvv '(tcp[tcpflags] & tcp-syn != 0) && (ip[1] != 0x0)'
>
> and see what appears.
>
> rick
of (ip[1] & 3 != 0)
Note that you could catch SYNACK with this filter (if your machine
initiates some active TCP sessions), since SYNACK might have ECT bits,
if some stacks implemented :
http://tools.ietf.org/html/draft-kuzmanovic-ecn-syn-00 ( Adding
Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK
Packets )
http://tools.ietf.org/id/draft-ietf-tcpm-ecnsyn-04.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists