From: "Michael Chan" <mchan@broadcom.com>
To: "Dan Reader" <Dan.Reader@neterion.com>
Cc: "Ravinandan Arakali" <Ravinandan.Arakali@neterion.com>,
"David Miller" <davem@davemloft.net>,
herbert@gondor.apana.org.au, netdev@vger.kernel.org,
steve.arden@neterion.com,
"Leonid Grossman" <Leonid.Grossman@neterion.com>,
"Ananda Raju" <Ananda.Raju@neterion.com>
Subject: Re: [PATCH]NET: Add ECN support for TSO
Date: Wed, 26 Jul 2006 12:40:45 -0700 [thread overview]
Message-ID: <1153942845.3167.56.camel@rh4> (raw)
In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7793B29B@nekter>
On Fri, 2006-07-14 at 12:12 -0400, Dan Reader wrote:
> If we implement the approach you suggest and all data sent uses TSO, the
> receiver can easily determine the expected codepoint of almost any
> isolated CE packet. It simply has to look at the segment before and the
> segment after (which it can wait for, thanks to delayed ACKs). If they
> have the same ECT value, use that one. If they're different, then it
> just has to perform a check for non-MSS (i.e. the boundary between TSOs
> if send ops do not yield a multiple of MSS) and it might know.
I don't think it's that easy to guess. The TSO sizes are almost always
multiples of MSS because they get trimmed or they are limited by the
congestion window. The receiver will eventually make a mistake using
your scheme above that the sender can reliably detect.
I agree that replicating the ECT bits makes it less random, but it seems
to be the simplest and best approach. In real life, there will be some
TSO and some non-TSO packets making it even more difficult to guess.
Randomizing the ECT bits in hardware makes verification of the nonce-sum
very complicated and unreliable.
next prev parent reply other threads:[~2006-07-26 19:39 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-14 16:12 [PATCH]NET: Add ECN support for TSO Dan Reader
2006-07-26 19:40 ` Michael Chan [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-07-13 19:35 Michael Chan
2006-07-14 5:03 ` David Miller
2006-07-12 4:53 Michael Chan
2006-07-12 6:11 ` David Miller
2006-07-12 17:15 ` Ravinandan Arakali
2006-07-08 1:01 Michael Chan
2006-07-08 20:32 ` David Miller
2006-07-12 1:45 ` Ravinandan Arakali
2006-07-12 1:51 ` David Miller
2006-07-13 17:26 ` Ravinandan Arakali
2006-07-07 20:57 Michael Chan
2006-07-07 21:59 ` David Miller
2006-07-07 22:52 ` David Miller
2006-06-28 3:06 Michael Chan
2006-06-28 3:10 ` Herbert Xu
2006-06-28 3:40 ` Michael Chan
2006-06-28 3:48 ` Herbert Xu
2006-06-28 4:37 ` Michael Chan
2006-06-28 4:42 ` Herbert Xu
2006-06-28 4:54 ` Michael Chan
2006-06-28 4:57 ` Herbert Xu
2006-06-29 19:30 ` David Miller
2006-07-07 18:56 ` Ravinandan Arakali
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=1153942845.3167.56.camel@rh4 \
--to=mchan@broadcom.com \
--cc=Ananda.Raju@neterion.com \
--cc=Dan.Reader@neterion.com \
--cc=Leonid.Grossman@neterion.com \
--cc=Ravinandan.Arakali@neterion.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.org \
--cc=steve.arden@neterion.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).