Setting ECN bits in UDP packets

[f***@gmail.com]

Dear all,
for an application I am developing, I would like to set the ECN bits in outgoing UDP packets. As I understand, I could use setsockopt() to set the TOS byte in the IP header, but I read in "man 7 socket"

IP_TOS (since Linux 1.0)
Set or receive the Type-Of-Service (TOS) field
...
There are some standard TOS flags defined:
IPTOS_LOWDELAY ...
Other bits are invalid and shall be cleared

If I understand the man page correctly, the ECN bits (that are part of the TOS byte) cannot be set using setsockopt(). (Unfortunately I cannot test this right now).

Am I correct? Do you know about an alternative way to set the ECN bits? Is my only option to use raw sockets?

[Jorgen Grahn]

Post by f***@gmail.com
Dear all,
for an application I am developing,

And a new protocol, too.

Post by f***@gmail.com
I would like to set the ECN bits in outgoing UDP packets.
As I understand, I could use setsockopt() to set the TOS byte
in the IP header, but I read in "man 7 socket"
IP_TOS (since Linux 1.0)
Set or receive the Type-Of-Service (TOS) field
...
IPTOS_LOWDELAY ...
Other bits are invalid and shall be cleared
If I understand the man page correctly, the ECN bits (that are part
of the TOS byte) cannot be set using setsockopt(). (Unfortunately I
cannot test this right now).
Am I correct? Do you know about an alternative way to set the ECN
bits? Is my only option to use raw sockets?

No idea, but the Wikipedia entry says:

It should in principle be possible to use ECN with protocols
layered above UDP. However, UDP requires that congestion control
be performed by the application, and current networking APIs do
not give access to the ECN bits.

I also note that you can lose a lot by doing this:
- it's harder for others to implement your protocol
- going raw sockets may affect performance, if that matters

/Jorgen

[f***@gmail.com]

Post by Jorgen Grahn

Post by f***@gmail.com
Dear all,
for an application I am developing,

And a new protocol, too.

Well, OK, yes, the application uses a protocol of its own layered over UDP.
The reason for wanting to use the ECN bits is that it is suggested (e.g., in RFC 5404 -- Unicast UDP Usage Guidelines for Application Designers, http://tools.ietf.org/html/rfc5405) that applications using UDP should do congestion control.

I am thinking of using TFRC (http://tools.ietf.org/html/rfc5348) for which I have a ready to use library. TFRC can make use of the ECN bits to recognize congestion in advance and avoiding it. Therefore, my idea of setting the ECN bits.

Post by Jorgen Grahn

Post by f***@gmail.com
I would like to set the ECN bits in outgoing UDP packets.
As I understand, I could use setsockopt() to set the TOS byte
in the IP header, but I read in "man 7 socket"
IP_TOS (since Linux 1.0)
Set or receive the Type-Of-Service (TOS) field
...
IPTOS_LOWDELAY ...
Other bits are invalid and shall be cleared
If I understand the man page correctly, the ECN bits (that are part
of the TOS byte) cannot be set using setsockopt(). (Unfortunately I
cannot test this right now).
Am I correct? Do you know about an alternative way to set the ECN
bits? Is my only option to use raw sockets?

It should in principle be possible to use ECN with protocols
layered above UDP. However, UDP requires that congestion control
be performed by the application, and current networking APIs do
not give access to the ECN bits.

Yes, I found that entry too. To be honest, in my opinion partly conflicts with the availability of setsockopt() that WOULD allow you to set the ECN bits if Linux did not reset them by policy. Also note that it is always possible to READ them by using recvmsg() instead of recv().

If I remember correctly, by using raw socket you can specify the whole IP header.

Post by Jorgen Grahn
- it's harder for others to implement your protocol
- going raw sockets may affect performance, if that matters

Also going raw sockets it would mean to reinvent the wheel and rewrite the whole UDP-like part. In my case it is not worth it.

Post by Jorgen Grahn
/Jorgen
--
\X/ snipabacken.se> O o .

[Jorgen Grahn]

Post by f***@gmail.com

Post by Jorgen Grahn

Post by f***@gmail.com
Dear all,
for an application I am developing,

And a new protocol, too.

Well, OK, yes, the application uses a protocol of its own layered over UDP.

Yes, my point was that you're involved in protocol design. "Developing
an application" sounds too modest :-)

(BTW, can you please limit your line lengths to 70 or so? I have to
reformat manually when replying.)

Post by f***@gmail.com
The reason for wanting to use the ECN bits is that it is suggested
(e.g., in RFC 5404 -- Unicast UDP Usage Guidelines for Application
Designers, http://tools.ietf.org/html/rfc5405) that applications using
UDP should do congestion control.

You mean RFC 5405. Thanks! I never heard of that RFC, and yet it
covers all those things that come up when UDP is discussed here and on
comp.protocols.tcp-ip.

...

Post by f***@gmail.com

Post by Jorgen Grahn

Post by f***@gmail.com
I would like to set the ECN bits in outgoing UDP packets.
As I understand, I could use setsockopt() to set the TOS byte
in the IP header, but I read in "man 7 socket"
IP_TOS (since Linux 1.0)
Set or receive the Type-Of-Service (TOS) field
...
IPTOS_LOWDELAY ...
Other bits are invalid and shall be cleared
If I understand the man page correctly, the ECN bits (that are part
of the TOS byte) cannot be set using setsockopt(). (Unfortunately I
cannot test this right now).
Am I correct? Do you know about an alternative way to set the ECN
bits? Is my only option to use raw sockets?

It should in principle be possible to use ECN with protocols
layered above UDP. However, UDP requires that congestion control
be performed by the application, and current networking APIs do
not give access to the ECN bits.

Yes, I found that entry too. To be honest, in my opinion partly
conflicts with the availability of setsockopt() that WOULD allow you
to set the ECN bits if Linux did not reset them by policy.

But it does, so the Wikipedia article is correct.

Or is it? I had a quick look in the kernel (do_ip_setsockopt() in
ip_sockglue.c) and I can't see any resetting take place, except for
SOCK_STREAM sockets, where it makes perfect sense. Perhaps it's done
elsewhere. The kernel I'm looking at is 3.2.6.

/Jorgen