If we would change the default for applications that don't explicitly
configure any value of IPV6_USE_MIN_MTU to now be the value of "-1",
then this extension would give us something, otherwise not (the
main incentive is to change the default behavior for multicast packets).
Even with -1 as a default i think that i would prefer a cleaner API and quite
frankly i don't think that we are so short into the life of IPv6 that it
doesn't really make too much sense to obfuscate such rather exotic
API pieces for the sake of backward compatibility (i.e.: there's so little
application already written using that API compared to what we in the
future want to see being written but using a clean API).
For this reason i proposed to add a new API call that would allow to
set the MTU behavior of unicast and multicast individually or together
and simply consider IPV6_USE_MIN_MTU to only apply to unicast - after all,
it's quite obvious that multicast wasn't really much thought off when that
API call was designed, so going along this path not only gives us a clean
new API call, but also allows us to keep backward compatibility of
IPV6_USE_MIN_MTU for that scope of applications (unicast) that were
obviously only considered for it in the first place - i.e.: sufficient
backward compatiblity AND a clean new API call (API call along the lines
of the last emails proposal i sent).
Cheers
Toerless
On Wed, Apr 10, 2002 at 03:42:29AM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote:
> >>>>> On Mon, 08 Apr 2002 23:56:32 +0900,
> >>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said:
>
> >> Well, i've just seen bad and worse ip multicast applications over the
> >> last 10 years, programmers have been ignorant about the issues at hand
> >> and people who deploy the applications have been ignorant about the
> >> network issues they cause.
>
> > Out of curiosity, do you have concrete examples of the bad
> > applications? I tend to agree with you, but I'm still not fully
> > convinced that application programmers are that silly and we need to
> > add the complicated intelligence to the kernel.
>
> I've got an example from a private message, and I now agree that we
> need some changes on the current API spec.
>
> Considering the tradeoff between the advantage of safe API
> specification and the disadvantage of the loss of compatibility and/or
> the complexity of the additional API knobs, I'd like to propose the
> following approach:
>
> allow IPV6_USE_MIN_MTU 3 arguments, -1, 0, and 1. the semantics of
> the 3 values are as follows:
> -1: if the destination is unicast, regard the path MTU and perform
> path MTU discovery if necessary. if the destination is
> multicast, fragment the packet at the minimum MTU (and disable
> path MTU discovery as a result)
> ***This is the default value of the option, including the case
> where the application does not explicitly specify this option***
> 0: always regard the path MTU, regardless of the destination
> (unicast or multicast).
> 1: always fragment packets at the minimum MTU, regardless of the
> destination.
>
> This way the default behavior will be optimal while keeping
> compatibility to existing implementations that use IPV6_USE_MIN_MTU
> and avoiding additional socket options.
>
> This may still be regarded as an ad-hoc solution, but I believe this
> is practically the best way.
>
> Is this change acceptable?
>
> JINMEI, Tatuya
> Communication Platform Lab.
> Corporate R&D Center, Toshiba Corp.
> [EMAIL PROTECTED]
--
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]
--------------------------------------------------------------------
