Appropriate byte counting, revisited.

[Kentaro A. Kurahone]

There was some discussion a while back regarding Appropriate Byte
Counting (RFC 3465). As part of poking at HSTCP, I found a compelling
reason to implement this mechanism:

When a connection is in congestion avoidance, we currently grow the
window like thus:
u_int cw = tp->snd_cwnd;
u_int incr = tp->t_segsz;

incr = incr * incr / cw;

The problem occurs when the congestion window grows past t_segsz
segments, since the increment is under a byte, the congestion window
won't be opened further.

Diff:
http://www.sigusr1.org/~kurahone/misc-hacks/tcp-abc-netbsd-3.99.20.diff.gz

The diff implements straight forward per-RFC ABC, with the "L" parameter
set at "1*SMSS". As an additional bonus, I changed the header prediction
code to execute even when the connection is congestion window bound,
which should help overall performance.

Questions/Comments?

[Rui Paulo]

At Sun, 4 Jun 2006 18:41:54 +0000,

Post by Kentaro A. Kurahone
There was some discussion a while back regarding Appropriate Byte
Counting (RFC 3465). As part of poking at HSTCP, I found a compelling
When a connection is in congestion avoidance, we currently grow the
u_int cw = tp->snd_cwnd;
u_int incr = tp->t_segsz;
incr = incr * incr / cw;
The problem occurs when the congestion window grows past t_segsz
segments, since the increment is under a byte, the congestion window
won't be opened further.
http://www.sigusr1.org/~kurahone/misc-hacks/tcp-abc-netbsd-3.99.20.diff.gz
The diff implements straight forward per-RFC ABC, with the "L" parameter
set at "1*SMSS". As an additional bonus, I changed the header prediction
code to execute even when the connection is congestion window bound,
which should help overall performance.
Questions/Comments?

I found a typo ;-)
+ /* Grow our congestion window if neccecary. */

What about a sysctl to disable/enable this ? As the RFC says:

On the other hand, in some cases
the modified cwnd growth algorithm causes larger bursts of segments
to be sent into the network. In some cases this can lead to a non-
negligible increase in the drop rate and reduced performance (see
section 4 for a larger discussion of the issues).



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Kentaro A. Kurahone]

Post by Rui Paulo
At Sun, 4 Jun 2006 18:41:54 +0000,
I found a typo ;-)
+ /* Grow our congestion window if neccecary. */

Thanks!

Post by Rui Paulo
On the other hand, in some cases
the modified cwnd growth algorithm causes larger bursts of segments
to be sent into the network. In some cases this can lead to a non-
negligible increase in the drop rate and reduced performance (see
section 4 for a larger discussion of the issues).

If my reading of the spec is correct this only really applies in cases
where L > 1*SMSS. As it stands right now, I'm using L=1*SMSS, so
behavior durring slow start will either be identical to, or more
conservative than the traditional algorithm. With that said, it may be
beneficial to provide the option for using L=2*SMSS and have a sysctl
for that.

[Rui Paulo]

At Mon, 5 Jun 2006 15:56:06 +0000,

Post by Kentaro A. Kurahone
If my reading of the spec is correct this only really applies in cases
where L > 1*SMSS. As it stands right now, I'm using L=1*SMSS, so
behavior durring slow start will either be identical to, or more
conservative than the traditional algorithm.

Yes, I re-read the RFC and it makes sense now.

Post by Kentaro A. Kurahone
With that said, it may be
beneficial to provide the option for using L=2*SMSS and have a sysctl
for that.

Indeed that would be benefical. As long as we don't use this limit
during slow start as the spec says.

Thanks.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Kentaro A. Kurahone]

Post by Rui Paulo

Post by Kentaro A. Kurahone
With that said, it may be
beneficial to provide the option for using L=2*SMSS and have a sysctl
for that.

Indeed that would be benefical. As long as we don't use this limit
during slow start as the spec says.

Well, the limit only applies during slowstart. It can be beneficial to
do something like this since it deals with delayed acking prolonging the
slow start duration[0]. It's just that it needs to be toggleable since
bad things can happen.

[Kentaro A. Kurahone]

Post by Kentaro A. Kurahone
With that said, it may be
beneficial to provide the option for using L=2*SMSS and have a sysctl
for that.

New and improved version of the patch available at the same location[0].
It fixes most of the nits in the earlier version, and adds a sysctl that
will set L=2*SMSS (on by default).

One other difference to the previous incarnation of the patch is that
the ack prediction code will only grow snd_cwnd if it's < snd_wnd. I'm
not sure if this is entirely correct, but it does preserve the existing
behavior.

Unless anyone has any objections I'm going to commit this.

[YAMAMOTO Takashi]

Post by Kentaro A. Kurahone

Post by Kentaro A. Kurahone
With that said, it may be
beneficial to provide the option for using L=2*SMSS and have a sysctl
for that.

New and improved version of the patch available at the same location[0].
It fixes most of the nits in the earlier version, and adds a sysctl that
will set L=2*SMSS (on by default).
One other difference to the previous incarnation of the patch is that
the ack prediction code will only grow snd_cwnd if it's < snd_wnd. I'm
not sure if this is entirely correct, but it does preserve the existing
behavior.
Unless anyone has any objections I'm going to commit this.

what's the status of this?
i've adapted it to -current. (attached)

YAMAMOTO Takashi

[Rui Paulo]

Post by YAMAMOTO Takashi

Post by Kentaro A. Kurahone

Post by Kentaro A. Kurahone
With that said, it may be
beneficial to provide the option for using L=2*SMSS and have a sysctl
for that.

New and improved version of the patch available at the same
location[0].
It fixes most of the nits in the earlier version, and adds a
sysctl that
will set L=2*SMSS (on by default).
One other difference to the previous incarnation of the patch is that
the ack prediction code will only grow snd_cwnd if it's <
snd_wnd. I'm
not sure if this is entirely correct, but it does preserve the existing
behavior.
Unless anyone has any objections I'm going to commit this.

what's the status of this?
i've adapted it to -current. (attached)

You're faster than me ;-)
Now, seriously, I asked Kentaro to change the sysctl variable name to
simply "abc".
Your patch looks good.

--
Rui Paulo



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[YAMAMOTO Takashi]

Post by Rui Paulo
Now, seriously, I asked Kentaro to change the sysctl variable name to
simply "abc".

abc.aggressive, maybe?
the current description ("Enable RFC3465 Appropriate Byte Counting")
in the patch is not quite right.

YAMAMOTO Takashi

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Rui Paulo]

Post by YAMAMOTO Takashi

Post by Rui Paulo
Now, seriously, I asked Kentaro to change the sysctl variable name to
simply "abc".

abc.aggressive, maybe?
the current description ("Enable RFC3465 Appropriate Byte Counting")
in the patch is not quite right.

Yes, I can see that. I think we should have:
net.inet.tcp.abc=1
net.inet.tcp.abc.agressive=0

--
Rui Paulo



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Laight]

Post by Rui Paulo

Post by YAMAMOTO Takashi

Post by Rui Paulo
Now, seriously, I asked Kentaro to change the sysctl variable name to
simply "abc".

abc.aggressive, maybe?
the current description ("Enable RFC3465 Appropriate Byte Counting")
in the patch is not quite right.

net.inet.tcp.abc=1
net.inet.tcp.abc.agressive=0

I think that "abc" is too obtuse, although "rfc3465" is even less user friendly.
What is the variable in the code called - it ought to have (much the) same
name.

Also I'm not sure it is a good idea (valid ?) to have both "net.inet.tcp.abc"
and "net.inet.tcp.abc.agressive".

David

[YAMAMOTO Takashi]

Post by David Laight

Post by Rui Paulo

Post by YAMAMOTO Takashi

Post by Rui Paulo
Now, seriously, I asked Kentaro to change the sysctl variable name to
simply "abc".

abc.aggressive, maybe?
the current description ("Enable RFC3465 Appropriate Byte Counting")
in the patch is not quite right.

net.inet.tcp.abc=1
net.inet.tcp.abc.agressive=0

I think that "abc" is too obtuse, although "rfc3465" is even less user friendly.

while "abc" without a context might be obtuse,
what "net.inet.tcp.abc" means is clear.
(at least, it's clear to me. otoh, i can't remember what "rfc3465" is. :-)

Post by David Laight
What is the variable in the code called - it ought to have (much the) same
name.

it can be the same as whatever sysctl name is.

Post by David Laight
Also I'm not sure it is a good idea (valid ?) to have both "net.inet.tcp.abc"
and "net.inet.tcp.abc.agressive".

unless anyone objects, i'll rename the sysctl as the following
and commit. it's consistent with net.inet.tcp.sack.

net.inet.tcp.abc.enable=1
net.inet.tcp.abc.aggressive=1

YAMAMOTO Takashi

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael van Elst]

Post by YAMAMOTO Takashi
while "abc" without a context might be obtuse,
what "net.inet.tcp.abc" means is clear.
(at least, it's clear to me. otoh, i can't remember what "rfc3465" is. :-)

Possible. But everyone can look it up which is not so clear for 'abc'.

[Ignatios Souvatzis]

Post by Michael van Elst

Post by YAMAMOTO Takashi
while "abc" without a context might be obtuse,
what "net.inet.tcp.abc" means is clear.
(at least, it's clear to me. otoh, i can't remember what
"rfc3465" is. :-)

Possible. But everyone can look it up which is not so clear for 'abc'.

By look it, you mean go to google and type rfc 3465 ?

No. http://www.ietf.org/rfc/rfc3465.txt

-is

[Rui Paulo]

Post by Michael van Elst

Post by YAMAMOTO Takashi
while "abc" without a context might be obtuse,
what "net.inet.tcp.abc" means is clear.
(at least, it's clear to me. otoh, i can't remember what
"rfc3465" is. :-)

Possible. But everyone can look it up which is not so clear for 'abc'.

By look it, you mean go to google and type rfc 3465 ?
Besides the fact that the RFC number is in the sysctl MIB
description, try searching for "tcp abc rfc" :)

--
Rui Paulo



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael van Elst]

By look it, you mean go to google and type rfc 3465 ?

Looking at ftp://ftp.rfc-editor.org/in-notes/rfc3465.txt,
but google is fine too :)

Besides the fact that the RFC number is in the sysctl MIB
description, try searching for "tcp abc rfc" :)

But "tcp abc" also revealed the "TCP Atomic BrooadCasting" :-)

For my taste "abc" doesn't say much and is ambigous. Using
the rfc number is precise, just like net.inet.tcp.rfc1323
says what it does.

[YAMAMOTO Takashi]

Post by Michael van Elst

By look it, you mean go to google and type rfc 3465 ?

Looking at ftp://ftp.rfc-editor.org/in-notes/rfc3465.txt,
but google is fine too :)

Besides the fact that the RFC number is in the sysctl MIB
description, try searching for "tcp abc rfc" :)

But "tcp abc" also revealed the "TCP Atomic BrooadCasting" :-)
For my taste "abc" doesn't say much and is ambigous. Using
the rfc number is precise, just like net.inet.tcp.rfc1323
says what it does.

if you want to know the meaning of a netbsd sysctl knob,
you should look at our documents, rather than rfc or google.

net.inet.tcp.rfc1323 was rather ambigous, and now somewhat obsolete.
you should use net.inet.tcp.{win_scale,timestamps} instead.

YAMAMOTO Takashi

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael van Elst]

Post by YAMAMOTO Takashi
if you want to know the meaning of a netbsd sysctl knob,
you should look at our documents

Can you give a pointer to our document of tcp.abc?

[YAMAMOTO Takashi]

Post by Michael van Elst

Post by YAMAMOTO Takashi
if you want to know the meaning of a netbsd sysctl knob,
you should look at our documents

Can you give a pointer to our document of tcp.abc?

it hasn't been written yet.

YAMAMOTO Takashi

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Rui Paulo]

Post by YAMAMOTO Takashi

Post by Michael van Elst

Post by YAMAMOTO Takashi
if you want to know the meaning of a netbsd sysctl knob,
you should look at our documents

Can you give a pointer to our document of tcp.abc?

it hasn't been written yet.

And, seriously, what's the problem of sysctl -D ?

--
Rui Paulo



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christian Biere]

Post by Rui Paulo

Post by YAMAMOTO Takashi

Post by Michael van Elst
Can you give a pointer to our document of tcp.abc?

it hasn't been written yet.

And, seriously, what's the problem of sysctl -D ?

Nothing except that you probably meant -d. Of course that means
you don't need any name at all. Just enumerate the knobs and
use -d if you need to know what it is. Saves tons of memory.
If you can't remember which number refers to which option,
you can always use (shell) variables.

Another issue with "abc" is simply that it's so short that
a clash with something else is more likely than for a long
identifier.

Further arguments for "rfc3465" are:

- There's prior art.
- It's bijective i.e. you'll find it when searching for
this RFC as well as the RFC when searching for this
option.
- The TV channel won't sue you.

[YAMAMOTO Takashi]

Post by Christian Biere
Another issue with "abc" is simply that it's so short that
a clash with something else is more likely than for a long
identifier.

an acronym with three letters is too short?

Post by Christian Biere
- There's prior art.

if you mean rfc1323, it's rather an execption (timestamps, sack, newreno, ...)
and, IMO, a mistake.

Post by Christian Biere
- It's bijective i.e. you'll find it when searching for
this RFC as well as the RFC when searching for this
option.

it isn't a problem as far as sysctl -d and/or other documents
have rfc numbers.

Post by Christian Biere
- The TV channel won't sue you.

a good point. :)

after all, it's a matter of taste, and continuing this discussion
doesn't buy us much. let's ask core a decision.
(maybe i'll abstain from core voting on this.)

YAMAMOTO Takashi

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Pavel Cahyna]

Post by YAMAMOTO Takashi
after all, it's a matter of taste, and continuing this discussion
doesn't buy us much. let's ask core a decision.

Can't we just let the person doing the change decide?

Pavel

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Rui Paulo]

I would love to shut up, but I can't sorry ;-)

Post by YAMAMOTO Takashi

Post by Christian Biere
- There's prior art.

if you mean rfc1323, it's rather an execption (timestamps, sack, newreno, ...)
and, IMO, a mistake.
sysctl net.inet.tcp.abc

net.inet.tcp.abc: 1

Post by YAMAMOTO Takashi
uname -s

DragonFly

Post by YAMAMOTO Takashi
after all, it's a matter of taste, and continuing this discussion
doesn't buy us much. let's ask core a decision.
(maybe i'll abstain from core voting on this.)

1) You are right that it's a matter of taste.
2) this is not a technical decision for core.
3) you MUST abstain, or else the level of fairness would be low.

--
Rui Paulo



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[YAMAMOTO Takashi]

Post by Rui Paulo
2) this is not a technical decision for core.

who can make this kind of decisions, then?

YAMAMOTO Takashi

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Rui Paulo]

Post by YAMAMOTO Takashi

Post by Rui Paulo
2) this is not a technical decision for core.

who can make this kind of decisions, then?

The developers in a respectful way? And most important, the person(s)
who is/are doing the work should have the last word.

--
Rui Paulo



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Elad Efrat]

Post by YAMAMOTO Takashi

Post by Rui Paulo
2) this is not a technical decision for core.

who can make this kind of decisions, then?

Come on, YAMAMOTO-San, let's be rational here. It's just a variable
name. It doesn't *really* matter what it's called, as long as it comes
along with (a) descriptive paragraph(s) in the man-page(s) and a good
sysctl description.

Let's not drag core into minor issues like that. I think most of us
wouldn't care and/or would rather the developer doing the work to
make the choice (unless it's a really bad one, but this hasn't been
proven in this case -- it seems like a matter of personal taste).

Can we move on, please? :)

-e.

[YAMAMOTO Takashi]

Post by Elad Efrat

Post by YAMAMOTO Takashi

Post by Rui Paulo
2) this is not a technical decision for core.

who can make this kind of decisions, then?

Come on, YAMAMOTO-San, let's be rational here. It's just a variable
name. It doesn't *really* matter what it's called, as long as it comes
along with (a) descriptive paragraph(s) in the man-page(s) and a good
sysctl description.

but it seems that it's what people here care most.

Post by Elad Efrat
Let's not drag core into minor issues like that. I think most of us
wouldn't care and/or would rather the developer doing the work to
make the choice (unless it's a really bad one, but this hasn't been
proven in this case -- it seems like a matter of personal taste).
Can we move on, please? :)

the author of the code is silent on this.
as i said, i'll go with tcp.abc unless anyone objects.
but people objecting.

YAMAMOTO Takashi

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by YAMAMOTO Takashi
the author of the code is silent on this.
as i said, i'll go with tcp.abc unless anyone objects.
but people objecting.

Well, I think most people who've noticed this thread are just sitting
around, as I am, utterly astonished that anyone would find it reasonable
to keep bothering you about this after several days.

Please, just use tcp.abc and be done with it! Not every objection should
be taken seriously.

[YAMAMOTO Takashi]

Post by Thor Lancelot Simon
Please, just use tcp.abc and be done with it! Not every objection should
be taken seriously.

ok, maybe i'll do so...
if anyone has any serious problem with "tcp.abc" beyond tastes,
please speak up (again).

YAMAMOTO Takashi

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[YAMAMOTO Takashi]

Post by YAMAMOTO Takashi

Post by Thor Lancelot Simon
Please, just use tcp.abc and be done with it! Not every objection should
be taken seriously.

ok, maybe i'll do so...
if anyone has any serious problem with "tcp.abc" beyond tastes,
please speak up (again).

here's a patch.
i omitted ack prediction part of the original patch because
it's a separate change.

YAMAMOTO Takashi

[Rui Paulo]

Post by YAMAMOTO Takashi

Post by YAMAMOTO Takashi

Post by Thor Lancelot Simon
Please, just use tcp.abc and be done with it! Not every
objection should
be taken seriously.

ok, maybe i'll do so...
if anyone has any serious problem with "tcp.abc" beyond tastes,
please speak up (again).

here's a patch.
i omitted ack prediction part of the original patch because
it's a separate change.

Thanks, this looks fine.
I'd say commit it.

--
Rui Paulo



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Pavel Cahyna

Post by YAMAMOTO Takashi
after all, it's a matter of taste, and continuing this discussion
doesn't buy us much. let's ask core a decision.

Can't we just let the person doing the change decide?

We sure can!

Dave

[Rui Paulo]

The most stupid details are the ones people discuss most.
I'm sorry to take part in this pointless discussion about the name of
a sysctl MIB.

--
Rui Paulo



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Laight]

Post by Michael van Elst

Post by YAMAMOTO Takashi
while "abc" without a context might be obtuse,
what "net.inet.tcp.abc" means is clear.
(at least, it's clear to me. otoh, i can't remember what "rfc3465" is. :-)

Possible. But everyone can look it up which is not so clear for 'abc'.

Something like "net.inet.tcp.app_byt_cnt" wpould give a clue that it is/isn't
the place you were looking for a parameter.

David

[Rui Paulo]

Post by YAMAMOTO Takashi

Post by David Laight

Post by Rui Paulo

Post by YAMAMOTO Takashi

Post by Rui Paulo
Now, seriously, I asked Kentaro to change the sysctl variable name to
simply "abc".

abc.aggressive, maybe?
the current description ("Enable RFC3465 Appropriate Byte
Counting")
in the patch is not quite right.

net.inet.tcp.abc=1
net.inet.tcp.abc.agressive=0

I think that "abc" is too obtuse, although "rfc3465" is even less user friendly.

while "abc" without a context might be obtuse,
what "net.inet.tcp.abc" means is clear.
(at least, it's clear to me. otoh, i can't remember what "rfc3465" is. :-)

Post by David Laight
What is the variable in the code called - it ought to have (much the) same
name.

it can be the same as whatever sysctl name is.

Post by David Laight
Also I'm not sure it is a good idea (valid ?) to have both
"net.inet.tcp.abc"
and "net.inet.tcp.abc.agressive".

unless anyone objects, i'll rename the sysctl as the following
and commit. it's consistent with net.inet.tcp.sack.
net.inet.tcp.abc.enable=1
net.inet.tcp.abc.aggressive=1

Why default to 2 * LMSS ?
--
Rui Paulo



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[YAMAMOTO Takashi]

Post by Rui Paulo

Post by YAMAMOTO Takashi
net.inet.tcp.abc.enable=1
net.inet.tcp.abc.aggressive=1

Why default to 2 * LMSS ?

i have no strong reason.
it was inherited from kurahone's original code.

YAMAMOTO Takashi

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de