Jinmei,
My concern was to change the default. Your text below seem
to indicate this, so it would solve my concern. As far as your
text is concerned, I would love to see more explicitly the sentence
"the default setting of this option for a socket is -1". In addition,
i would strongly recommend to call this the "API default" instead of the
"kernel default", because "kernel default" sounds as if it is up to the
kernel to decide what the default is (i.e.: i am worried that some kernel
developer could think that he can decide what to do in the -1 case). But
that's probably just me being paranoid.
Beside this, i would just argue that psychologically i'd love to see
the differentiation UNICAST/MULTICAST to show up in the API parameters
explicitly to help developes think about the difference, but that's just
cosmetic. I agree with you that just a _MULTICAST_ option like Eric sugested
is a bit confusing, but i have no strong opinions here. The real advantage
of NOT using IPV6_USE_MIN_MTU is to catch the hopefully small/non-existing
number of applications who already think that the value 0 to it is the
default and thus set it.
Thanks
Toerless
On Fri, Apr 12, 2002 at 08:48:00PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote:
> >>>>> On Thu, 11 Apr 2002 18:26:32 +0200 (CEST),
> >>>>> Erik Nordmark <[EMAIL PROTECTED]> said:
>
> > Is there a middle ground where the API can be made more clear
> > than using "-1" without having to replace IPV6_USE_MIN_MTU?
>
> > We already have IPV6_option and IPV6_MULTICAST_option in some cases.
> > Thus would it make sense to
> > 1) declare the IPV6_USE_MIN_MTU only applies to unicast.
> > 2) define a new IPV6_MULTICAST_USE_MIN_MTU whose default would be "true".
>
> This is essentially the same idea of the original proposal...the
> problem of this approach is that programmers would wonder "why
> does IPV6_USE_MIN_MTU not contain "UNICAST" but the use of it is
> limited to unicast?". I don't think this makes the API "more clear".
> Either way we'll need to describe the background and its limitation
> clearly, and if so, I'd prefer to keep the number of options.
>
> Actually I can make a compromise with either approach *if we can make
> a quick consensus*. To make the approach I proposed clearer, I've
> attached concrete text for the revised version of IPV6_USE_MIN_MTU
> according to my proposal. If we can live with this (though you may
> prefer the other one), please let us go.
>
> Thanks,
>
> JINMEI, Tatuya
> Communication Platform Lab.
> Corporate R&D Center, Toshiba Corp.
> [EMAIL PROTECTED]
>
> ===
> 11.1. Sending with the Minimum MTU
>
> Unicast applications should usually let the kernel to perform path
> MTU discovery, as long as the kernel support it, and should not
> care about the path MTU. Some applications, however, might not
> want to incur the overhead of path MTU discovery, especially if the
> applications only send a single datagram to a destination. A
> potential example is a DNS server.
>
> Also, path MTU discovery for multicast has severe scalability
> limitations and should thus be avoided.
>
> This specification defines a mechanism to avoid path MTU discovery by
> sending at the minimum IPv6 MTU [RFC-2460]. If the packet is larger
> than the minimum MTU and this feature has been enabled the IP layer
> will fragment to the minimum MTU. To control the policy about path
> MTU discovery, applications can use the IPV6_USE_MIN_MTU socket
> option.
>
> As described above, the default policy should depend on whether the
> destination is unicast or multicast. For unicast destinations path
> MTU discovery should be performed by default. For multicast
> destinations path MTU discovery should be disabled by default.
> This option thus takes the following three types of integer
> arguments,
>
> x == -1: use kernel default. That is, perform path MTU discovery
> for unicast, and disable it for multicast.
> x == 0: always perform path MTU discovery.
> x >= 1: always disable path MTU discovery and send packets at
> the minimum MTU.
> (values less than -1 are invalid.)
>
> For example, if a unicast application intentionally wants to
> disable path MTU discovery, it will add the following lines:
>
> int on = 1;
> setsockopt(fd, IPPROTO_IPV6, IPV6_USE_MIN_MTU, &on, sizeof(on));
>
> This option can also be sent as ancillary data. In the cmsghdr
> structure containing this ancillary data, the cmsg_level member
> will be IPPROTO_IPV6, the cmsg_type member will be
> IPV6_USE_MIN_MTU, and the first byte of cmsg_data[] will be the
> first byte of the integer.
--
Thanks
Toerless Eckert
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
