Subject: new rfc2292bis draft

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 23 Apr 2002 01:51:41 +0900

As some of you have already noticed, I submitted a new version of the
advanced API (rfc2292bis) draft.

The only change (other than minor wording nits) is as follows:

-  Revised the "minimum MTU" section so that path MTU discovery would
   be disabled for multicast by default.  A new (default) value "-1" as
   an argument was introduced accordingly.
(from Change History section)

To be more accurate, I've attached the whole section at the end of
this message.

I believe the change was based on the consensus on the list and we
can proceed to the next step with this version, but if you see any
problems please let me know.

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

p.s. I've also implemented the change in the latest snapshot of our
implementation.

11.1.  Sending with the Minimum MTU

   Unicast applications should usually let the kernel 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 by default.  Applications
   sending multicast traffic should explicitly enable path MTU discovery
   only when they understand that the benefit of possibly larger MTU
   usage outweights the possible impact of MTU discovery for active
   sources across the delivery tree(s).  This default behavior is based
   on today's available MTU path discovery mechanism and may change in
   the future once better scalable mechanisms are sufficiently
   ubiquitously available.

   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

draft-ietf-ipngwg-rfc2292bis-07.txt                            [Page 45]

INTERNET-DRAFT        Advanced Sockets API for IPv6        Apr. 19, 2002

   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:

       -1: Perform path MTU discovery for unicast destinations but do
           not perform it for multicast destinations.  Packets to multicast
           destinations are therefore sent with the minimum MTU.
       0: always perform path MTU discovery.
       1: always disable path MTU discovery and send packets at the
          minimum MTU.

   The default value of this option is -1.  Values other than -1, 0, and
   1 are invalid, and an error EINVAL will be returned for those values.

   As an 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));

   Note that this API intentionally excludes the case where the
   application wants to perform path MTU discovery for multicast but to
   disable it for unicast.  This is because such usage is not feasible
   considering a scale of performance issues around whether to do path
   MTU discovery or not.  When path MTU discovery makes sense to a
   destination but not to a different destination, regardless of whether
   the destination is unicast or multicast, 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.

   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.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 26 Apr 2002 01:17:25 +0900

>>>>> On Tue, 23 Apr 2002 01:51:41 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> problems please let me know.

There has been no comment for 3 days.  I believe this means the change
is approved by the group, and would like to proceed to the next step.

However, I'm not sure if I need to take an explicit action for this.
Please tell me if I do something.

Thanks,

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 26 Apr 2002 01:18:22 +0900

>>>>> On Fri, 26 Apr 2002 01:17:25 +0900, 

> Please tell me if I do something.
                 ^^^^^^^^^^^^^^^^^oops, I meant "if I need to do
something".

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 26 Apr 2002 11:51:22 +0900

Hello, 

since the wg chairs suggested me to send the following note directly

> Please tell me if I need to do something.

Could you tell me what I should do for the rfc2292bis draft to proceed
to the next step?  Thanks,

					JINMEI, Tatuya

---

From: Thomas Narten <[email-masked]>
Date: Fri, 26 Apr 2002 06:37:41 -0400

> to the next step?  Thanks,

I'll take it from here. I need to finish reviewing it and then get it
in front of the IESG

Thomas