Setting TOS/TCLASS/TTL options on socket

Setting TOS/TCLASS/TTL options on socket

[Tom Henderson, 2012-09-26 04:26:47]

Looks good to me in general.  I guess the other half of the patch would be the
RECVTOS support.

I had a question about adding the TOS/TClass as a packet tag in the outbound
direction.  What about instead modifying the Send() API to support the parameter
explicitly and avoid the tag?  What would be the drawbacks of doing it that way?

[Daniel L., 2012-09-26 18:28:41]

On 2012/09/26 04:26:47, Tom Henderson wrote:
> Looks good to me in general.  I guess the other half of the patch would be the
> RECVTOS support.

I think setting IP_RECVTOS is at tcp-socket-base/udp-socket-impl is similar to
IP_TOS. The code should be at the "DoForwardUp" in tcp, and "ForwardUp" in udp
as these two methods are already taking IP header as a parameter so TOS can be
read there.

However, for setting IP_RECVTCLASS (IPv6), it looks like their corresponding
DoForwardUp and ForwardUp are not taking IP header as a parameter so
tcp-socket-base/udp-socket-impl won't see TCLASS there. Is there any reason why
IPv6's methods do not take IP header at the socket? Can we do the same for both
IPv4 and IPv6?

> 
> I had a question about adding the TOS/TClass as a packet tag in the outbound
> direction.  What about instead modifying the Send() API to support the
parameter
> explicitly and avoid the tag?  What would be the drawbacks of doing it that
way?

I think modifying Send () requires introducing new calls in many places: from
tcp-socket-base/udp-socket-impl, tcpl4-protocol/udpl4-protocol, down to
ipv4-l3-protocol. Also I think there are other options for IP header and we may
not want to have once call for each option?

[Daniel L., 2012-10-04 21:10:15]

I have finished the RECV part of the code. Basically, a tag will be added to the
packet before forwarding it up the stack. The higher layer can remove the tag to
see the TTL/TOS/TCLASS values.

I have another question though. Currently the SetIpTos/Ttl/Tclass are not
returning values. I would like to make them similar to the setsockopt that they
return 0 if succeeded or -1 if failed. My problem is as follow:

In the BSD socket, it is possible to call setsockopt right after the socket is
created. If the socket is IPv4 and the user tries to access the IPv6 options,
setsockopt returns -1 (and vise versa).

In ns-3, however, the newly created socket does not know if it is v4 or v6
because it needs to have an endPoint/endPoint6 allocated first. The problem is,
endPoint/endPoint6 are not allocated until the Bind/Send(To)/Connect is called.
Given this situation, it is not possible to distinguish between v4/v6 right
after the socket is created.

My current implementation is that, a user can set all options. If later the
socket uses different version, then the options will be ignored.

Another option is changing the Socket to let it knows about v4/v6 from the
beginning, but I think that will create a very big API changes and would not be
good.

[Daniel L., 2012-10-05 22:06:49]

Allows a user to set TOS/TTL/TCLASS/HOPLIMIT of a socket.

The changes are:

Sending:
- Socket now has API to set TOS/TTL/TCLASS/HOPLIMIT
- Socket stores the values
- When sending a packet out, TcpSocketBase, UdpSocketImpl, (or other classes
that extended from Socket) checks if the user has supplied a non-default value.
It adds a corresponding Tag to the packet before passing it down the stack
- Ipv4(6)L3Protocol checks for a corresponding tag for each option and use them
to BuildHeader

Receiving:
- Socket now has API to set RECVTOS/RECVTTL/RECVTCLASS/RECVHOPLIMIT
- If the user set RECV*, a socket adds a tag to the packet before passing it up
the stack. An application can remove the tag to retrieve the desired info

Notes:
- The user can set a mis-matched options at the socket (e.g. the socket is a
IPv4 socket but the user can set TCLASS option). There is no error returned from
doing such thing. The mis-matched values are ignored by the socket.
- To get the IPV6_RECVTCLASS to work, a few changes to APIs have been made so
that Ipv6Header is passed up to TcpSocketBase/UdpSocketImpl. This changes make
the IPv6 to work similarly to the way IPv4 header is passed up.

[Daniel L., 2012-10-05 22:22:47]

dsr-routing/icmpv4-l4-protocol/icmpv6-l4-protocol are affected because they
extended IpL4Protocol, which has to be changed since IpL4Protocol  was changed.