Thanks for the careful consideration,
>>>>> On Tue, 16 Apr 2002 21:51:56 +0700,
>>>>> Robert Elz <[EMAIL PROTECTED]> said:
> That is, I fully understand why it is the default value, but if an
> application decides it wants to use the minimium MTU (for unicast) or
> that it doesn't (for multicast), is it really likely that it will
> want to ever say (on one socket) "use it for multicast but not for
> unicast" ?
> Having that as the default makes sense, as there's no way to know in
> the stack whether unicast or multicast packets will be sent, until
> after they're sent. But the application sure knows... Do applications
> really send both unicast and multicast packets out one socket?
Sometimes yes. In fact I have a couple of examples of such
applications.
> I guess my point is that all that might need to be altered is the
> default setting, no need to add the -1 value as a possible arg to the
> syscall (if an app really needs to return to the default values, it
> could just close the socket, open a new one, and bind it to the same
> address).
It could, but it is not always a good coding style (at least I believe
not). This way we'll have to figure out the type and the protocol of
the socket, the bound address and port for the socket, all socket
option values previously set for the socket, etc..., and then recover
all the values for the new socket. This is weird, and sometimes even
almost impossible.
Also, we usually provide an application with a way to go back to the
default, as an API convention. So I think the existence of -1 here
makes sense, even though the knob is usually unused.
> If we do need the new value, then are we 100% sure that we're not also
> going to need "use min mtu for unicast, but not for multicast" (the
> 4th possible case). I know that one seems crazy, but are we so certain
> that it will never be needed that it shouldn't be provided? If we
> assume that apps don't send unicast & multicast out the same socket,
> then clearly it isn't needed (but nor is the ability to set -1). If
> we assume that apps never send multicast other than min mtu, then it
> isn't needed - but then IPV6_USE_MIN_MTU could simply be defined as
> unicast only. And we already know that apps want to use min mtu for
> unicast packets (that's why the thing exists in the first place).
> So, from this, it seems to be, that if -1 exists (as a value that can
> be set), -2 (or something) needs to exist as well...
As I said above, there *are* applications that use a single socket for
both unicast and multicast applications. However, through my
experiences, all such applications do not care about the path MTU;
they are just happy with the default. Meanwhile, if a multicast
application ever wanted to enable path MTU discovery for multicast,
I'm quite sure that the application would use a dedicated socket for
multicast only. Thus, from a practical point of view, I believe we do
not need the 4th argument.
As a consequence, I don't see a need to change the current proposal.
However, I guess we could add an explicit note that:
- enabling path MTU discovery for multicast application is basically
not recommended.
- if an application really wants to enable it, the application
should use a dedicated socket for multicast.
Does this make sense?
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
