On 26/02/09 01:43 PM, Sowmini.Varadhan at Sun.COM wrote: > I'm mid-way through the list of ndd tunables (see > updates to http://cr.opensolaris.org/~sowmini/ndd.html > which also briefly describes these parameters) > and came across some items that don't look like they > belong in ndd at all- these look like good candidates > for setsockopts, or things that ought to be auto-tuned > by the stack. > > I'd like to find out if anyone's using these, or can > think of reasons why these should belong in ndd: > > - setting ip/tcp/udp/icmp TTL through ndd: > Do we really want to change the default ttl for all > ip/tcp/udp/icmp packets? Esp when there are socket options > like IP_TTL, IPV6_UNICAST_HOPS, IP_MULTICAST_TTL for this? > (See also 5046705) > > We have ip_def_ttl, ip6_def_hops, tcp_ipv4_ttl, > tcp_ipv6_hoplimit, icmp_ipv4_ttl, icmp_ipv6_hoplimit, > udp_ipv4_ttl, udp_ipv6_hoplimit, ip_broadcast_ttl. > Aren't IP_TTL, IPV6_UNICAST_HOPS, IP_MULTICAST_TTL > sufficient? >
You're presuming that the application provides the user the ability to configure this. Use of these knobs can assist when dealing with applications that are either problematic or when the environment is just a little bit different. > - icmp_bsd_compat: sounds like something that should > be a setsockopt, if we want something other than the > default. Does anyone actually alter the default here? > > ... > - ip_icmp_return_data_bytes, ip6_icmp_return_data_bytes- > for IPv4, rfc 1812 (Section 4.3.2.3) says that the icmp > datagram should contain as much info from the offending > packet as will fit in 576 bytes. Shouldn't this be > auto-tuned by the stack? > The other relevant RFC here is 1122, see section 3.2.2. We currently appear to default to 64, which is pretty good. That's going to cover 99% of packets IP+TCP header data. The real benefit in ensuring that all the IP+TCP/UDP/ICMP header data is included. There's not a lot of benefit in sending back 400 bytes of HTTP headers because the receiving stack just won't use it. Darren
