Erik, your thoughts are all valid, i just wonder to what degree an API
should try to predict all possible applicationr equirements when it's
just the question about wether or not to restrict the API alternatives
from all possible options down to what we today may consider to be likely
alternatives. I personally think it's better not to try to predict the
future and simply keep it flexible. You're just calling for a chance
later on to bang your head because you overlooked something coming up.
Cheers
Toerless
On Wed, Apr 17, 2002 at 08:28:58PM +0200, Erik Nordmark wrote:
>
> > This is probably not important - but is there any real need to allow
> > the value -1 to actually be set?
> >
> > 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" ?
>
> From an API design perspective it's odd if there are options that
> can be "set" but not "unset".
> In this particular case it would mean that an application which wants to
> revert back to the default behavior would need to close the socket and
> open a new one.
>
> > 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...
>
> I agree it sounds crazy...
>
> Looking at assumed applications that send both unicast and multicast out
> the same socket it seems like there is a scale of performance issues
> around whether to do PMTU discovery or not. I think this scale has
> three levels:
> - In some cases there are very few packets are sent to the same destination
> thus the overhead associated with getting the ICMP packet too big (and
> the data packet dropped) outweights the benefits of being able to send
> larger packets.
> - In other cases there might be several packets sent to a given destination
> but the multicast destinations have many widely spread members. Thus
> while the packet loss involved in the PMTU discovery is ok the ICMP
> 'too big' implosion would mean that you don't want to do PMTU discovery
> for multicast.
> - Finally the number of members in the multicast group is small enough
> so that the ICMP implosion is not a significant concern (and multiple
> packets are sent to each unicast and multicast destination to
> amortize the cost of the dropped packet and ICMP error) so
> that PMTU discovery makes sense for both unicast and multicast.
>
> I can't think of a place on this scale where it would make sense to
> use PMTU discovery for multicast destinations but not unicast destinations.
>
> Of course, one can envision applications where PMTU discovery makes sense
> to destination A (whether unicast or multicast) but not to destination B
> (whether unicast or multicast). Such applications either need to toggle the
> option between sending such packets on the same socket, or use different
> sockets for the two classes of destinations. But that level of
> flexibility seems to be orthogonal to unicast vs. multicast.
>
> So I think 3 values is what's needed - not 4.
>
> Erik
>
--
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]
--------------------------------------------------------------------
