<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 25 Mar 2021, at 23:36, Paul Vixie <<a href="mailto:paul@redbarn.org" class="">paul@redbarn.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Wed, Mar 24, 2021 at 11:25:48PM +0100, Florian Weimer wrote:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">...<br class=""></blockquote><br class="">Proactive fragmentation irrespective of path MTU is required for<br class="">stateless IPv6 UDP services. Unlike IPv4, the network does not<br class="">fragment packets. So a UDP service has to conservatively fragment<br class="">around 1200 or so bytes (to account for tunnel overhead). ...<br class=""></blockquote><br class="">1280 subtracts several hundred bytes from 1500 to allow for tunnel<br class="">overhead.</div></div></blockquote><div><br class=""></div>Actually it doesn’t. The IETF arrived at this number from the other side (small values for MTU). See mail at bottom to see just what assumptions went into the parameters (1280=1025+256 because IPv4 was 512+64 and IPv6 needed to reduce the header overhead below that of IPv4. please…, 9600bps...)</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> 1232 subtracts dozens more to allow for IP and UDP headers<br class="">and options.<br class=""></div></div></blockquote><div><br class=""></div>That is does, unnecessarily. There is, and has been for a while, data out there showing bigger numbers are OK (for instance, Google published how they got to the size they use on QUIC packets based on traffic they observed arriving at their network, a fairly decent piece of data).</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">please, nobody, subtract even more. if everyone subtracts a fudge<br class="">factor, forever, we'll eventually run out of payload space, or worse,<br class="">go negative.<br class=""></div></div></blockquote><div><br class=""></div>:)</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">-- <br class="">Paul Vixie<br class="">_______________________________________________<br class="">dns-operations mailing list<br class=""><a href="mailto:dns-operations@lists.dns-oarc.net" class="">dns-operations@lists.dns-oarc.net</a><br class="">https://lists.dns-oarc.net/mailman/listinfo/dns-operations<br class=""></div></div></blockquote></div><br class=""><div class=""><br class=""></div><div class="">From <a href="mailto:owner-ipng@sunroof.eng.sun.com" class="">owner-ipng@sunroof.eng.sun.com</a> Thu Nov 13 16:41:01 1997<br class="">Received: (from majordomo@localhost)<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>by <a href="http://sunroof.eng.sun.com" class="">sunroof.eng.sun.com</a> (8.8.8+Sun.Beta.0/8.8.8) id QAA14339<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>for ipng-dist; Thu, 13 Nov 1997 16:38:00 -0800 (PST)<br class="">Received: from <a href="http://Eng.Sun.COM" class="">Eng.Sun.COM</a> (engmail1 [129.146.1.13])<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>by <a href="http://sunroof.eng.sun.com" class="">sunroof.eng.sun.com</a> (8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA14332<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>for <ipng@sunroof>; Thu, 13 Nov 1997 16:37:51 -0800 (PST)<br class="">Received: from <a href="http://saturn.sun.com" class="">saturn.sun.com</a> (<a href="http://saturn.EBay.Sun.COM" class="">saturn.EBay.Sun.COM</a> [129.150.69.2])<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>by <a href="http://Eng.Sun.COM" class="">Eng.Sun.COM</a> (SMI-8.6/SMI-5.3) with SMTP id QAA28654<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>for <<a href="mailto:ipng@sunroof.Eng.Sun.COM" class="">ipng@sunroof.Eng.Sun.COM</a>>; Thu, 13 Nov 1997 16:37:48 -0800<br class="">Received: from <a href="http://postoffice.cisco.com" class="">postoffice.cisco.com</a> (<a href="http://postoffice.cisco.com" class="">postoffice.cisco.com</a> [171.69.200.88])<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>by <a href="http://saturn.sun.com" class="">saturn.sun.com</a> (8.8.8/8.8.8) with ESMTP id QAA28706<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>for <<a href="mailto:ipng@sunroof.Eng.Sun.COM" class="">ipng@sunroof.Eng.Sun.COM</a>>; Thu, 13 Nov 1997 16:37:49 -0800 (PST)<br class="">Received: from [171.69.199.124] (<a href="http://deering-mac.cisco.com" class="">deering-mac.cisco.com</a> [171.69.199.124]) by <a href="http://postoffice.cisco.com" class="">postoffice.cisco.com</a> (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA20862; Thu, 13 Nov 1997 16:37:48 -0800 (PST)<br class="">X-Sender: <a href="mailto:deering@postoffice.cisco.com" class="">deering@postoffice.cisco.com</a><br class="">Message-Id: <v03110702b0598e80008d@[171.69.199.124]><br class="">Mime-Version: 1.0<br class="">Content-Type: text/plain; charset="us-ascii"<br class="">Date: Thu, 13 Nov 1997 16:37:00 -0800<br class="">To: IPng Working Group <<a href="mailto:ipng@sunroof.eng.sun.com" class="">ipng@sunroof.eng.sun.com</a>><br class="">From: Steve Deering <<a href="mailto:deering@cisco.com" class="">deering@cisco.com</a>><br class="">Subject: (IPng 4802) increasing the IPv6 minimum MTU<br class="">Cc: <a href="mailto:hinden@ipsilon.com" class="">hinden@ipsilon.com</a><br class="">Sender: <a href="mailto:owner-ipng@eng.sun.com" class="">owner-ipng@eng.sun.com</a><br class="">Precedence: bulk<br class=""><br class="">In the ipngwg meeting in Munich, I proposed increasing the IPv6 minimum MTU<br class="">from 576 bytes to something closer to the Ethernet MTU of 1500 bytes, (i.e.,<br class="">1500 minus room for a couple layers of encapsulating headers, so that min-<br class="">MTU-size packets that are tunneled across 1500-byte-MTU paths won't be<br class="">subject to fragmentation/reassembly on ingress/egress from the tunnels,<br class="">in most cases).<br class=""><br class="">After the short discussion in the Munich meeting, I called for a show of<br class="">hands, and of those who raised their hands (about half the attendees, if<br class="">I recall correctly), the vast majority were in favor of this change --<br class="">there were only two or three people opposed. However, we recognized that<br class="">a fundamental change of this nature requires thoughtful discussion and<br class="">analysis on the mailing list, to allow those who were not at the meeting<br class="">and those who were there but who have since had second thoughts, to express<br class="">their opinions. A couple of people have already, in private conversation,<br class="">raised some concerns that were not identified in the discussion at the<br class="">meeting, which I report below. We would like to get this issue settled as<br class="">soon as possible, since this is the only thing holding up the publication<br class="">of the updated Proposed Standard IPv6 spec (the version we expect to advance<br class="">to Draft Standard), so let's see if we can come to a decision before the ID<br class="">deadline at the end of next week (hoping there isn't any conflict between<br class="">"thoughtful analysis" and "let's decide quickly" :-).<br class=""><br class="">The reason I would like to increase the minimum MTU is that there are some<br class="">applications for which Path MTU Discovery just won't work very well, and<br class="">which will therefore limit themselves to sending packets no larger than<br class="">the minimum MTU. Increasing the minimum MTU would improve the bandwidth<br class="">efficiency, i.e., reduce the header overhead (ratio of header bytes to<br class="">payload bytes), for those applications. Some examples of such applications<br class="">are:<br class=""><br class=""> (1) Large-fanout, high-volume multicast apps, such as multicast video<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>("Internet TV"), multicast netnews, and multicast software<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>distribution. I believe these applications will end up limiting<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>themselves to packets no large than the min MTU in order to avoid<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>the danger of incurring an "implosion" of ICMP Packet-Too-Big<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>messages in response. Even though we have specified that router<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>implementations must carefully rate-limit the emission of ICMP<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>error messages, I am nervous about how well this will work in<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>practice, especially once there is a lot of high-speed, bulk<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>multicasting happening. An appropriate choice of rate or<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>probability of emission of Packet-Too-Big responses to multicasts<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>really depends on the fan-out of the multicast trees and the MTUs of<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>all the branches in that tree, which is unknown and unknowable to<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>the routers. Being sensibly conservative by choosing a very low<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>rate could, in many cases, significantly increase the delay before<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>the multicast source learns the right MTU for the tree and, hence,<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>before receivers on smaller-MTU branches can start receiving the<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>data.<br class=""><br class=""> (2) DNS servers, or other similar apps that have the requirement of<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>sending a small amount of data (a few packets at most) to a very<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>large and transient set of clients. Such servers often reside on<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>links, such as Ethernet, that have an MTU bigger than the links on<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>which many of their clients may reside, such as dial-up links. If<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>those servers were to send many reply messages of the size of their<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>own links (as required by PMTU Discovery), they could incur very<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>many ICMP packet-too-big messages and consequent retransmissions of<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>the replies -- in the worse case, multiplying the total bandwidth<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>consumption (and delivery delay) by 2 or 3 times that of the<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>alternative approach of just using the min MTU always. Furthermore,<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>the use of PMTU Discovery could result in such servers filling up<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>lots of memory withed cached PMTU information that will never be<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>used again (at least, not before it gets garbage-collected).<br class=""><br class="">The number I propose for the new minimum MTU is 1280 bytes (1024 + 256,<br class="">as compared to the classic 576 value which is 512 + 64). That would<br class="">leave generous room for encapsulating/tunnel headers within the Ethernet<br class="">MTU of 1500, e.g., enough for two layers of secure tunneling including<br class="">both ESP and AUTH headers.<br class=""><br class="">For medium-to-high speed links, this change would reduce the IPv6 header<br class="">overhead for min MTU packets from 7% to 3% (a little less than the IPv4<br class="">header overhead for 576-byte IPv4 packets). For low-speed links such as<br class="">analog dial-up or low-speed wireless, I assume that header compression will<br class="">be employed, which compresses out the IPv6 header completely, so the IPv6<br class="">header overhead on such links is effectively zero in any case.<br class=""><br class="">Here is a list of *disadvantages* to increasing the IPv6 minimum MTU that<br class="">have been raised, either publically or privately:<br class=""><br class=""> (1) This change would require the specification of link-specific<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>fragmentation and reassembly protocols for those link-layers<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>that can support 576-byte packets but not 1280-byte packets,<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>e.g., AppleTalk. I think such a protocol could be very simple,<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>and I briefly sketch such a protocol in Appendix I of this<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>message, as an example.<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>Often, those links that have a small native MTU are also the ones<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>that have low bandwidth. On low-bandwidth links, it is often<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>desirable to locally fragment and reassemble IPv6 packets anyway<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>(even 576-byte ones) in order to avoid having small, interactive<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>packets (e.g., keystrokes, character echoes, or voice samples)<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>be delayed excessively behind bigger packets (e.g., file transfers);<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>the small packets can be interleaved with the fragments of the<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>big packets. Someone mentioned in the meeting in Munich that the<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>ISSLL WG was working on a PPP-specific fragmentation and<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>reassembly protocol for precisely this reason, so maybe the job<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>of specifying such a protocol is already being taken care of.<br class=""><br class=""> (2) Someone raised the concern that, if we make the minimum MTU close<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>to Ethernet size, implementors might never bother to implement PMTU<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>Discovery. That would be regrettable, especially if the Internet<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>evolves to much more widespread use of links with MTUs bigger<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>than Ethernet's, since IPv6 would then fail to take advantage of<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>the bandwidth efficiencies possible on larger MTU paths.<br class=""><br class=""> (3) Peter Curran pointed out to me that using a larger minimum MTU for<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>IPv6 may result in much greater reliance on *IPv4* fragmentation and<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>reassembly during the transition phase while much of the IPv6<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>traffic is being tunneled over IPv4. This could incur unfortunate<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>performance penalties for tunneled IPv6 traffic (disasterous<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>penalties if there is non-negligible loss of IPv4 fragments).<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>I have included Peter's message, describing his concern in more<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>detail, in Appendix II of this message.<br class=""><br class=""> (4) Someone expressed the opinion that the requirement for link-layer<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>fragmentation and reassembly of IPv6 over low-cost, low-MTU links<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>like Firewire, would doom the potential use of IPv6 in cheap<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>consumer devices in which minimizing code size is important --<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>implementors of cheap Firewire devices would choose IPv4 instead,<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>since it would not need a fragmenting "shim" layer. This may well<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>be true, though I suspect the code required for local frag/reasm<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>would be negligible compared to the code required for Neighbor<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>Discovery.<br class=""><br class="">Personally, I am not convinced by the above concerns that increasing the<br class="">minimum MTU would be a mistake, but I'd like to hear what the rest of the<br class="">WG thinks. Are there other problems that anyone can think of? As I<br class="">mentioned earlier, the clear consensus of the Munich attendees was to<br class="">increase the minimum MTU, so we need to find out if these newly-identified<br class="">problems are enough to swing the consensus in the other direction. Your<br class="">feedback is heartily requested.<br class=""><br class="">Steve<br class=""><br class="">----------<br class=""><br class="">Appendix I<br class=""><br class="">Here is a sketch of a fragmentation and reassembly protocol (call it FRP)<br class="">to be employed between the IP layer and the link layer of a link with native<br class="">(or configured) MTU less than 1280 bytes.<br class=""><br class="">Identify a Block Size, B, which is the lesser of (a) the native MTU of the<br class="">link or (b) a value related to the bandwidth of the link, chosen to bound<br class="">the latency that one block can impose on a subsequent block. For example,<br class="">to stay within a latency of 200 ms on a 9600 bps link, choose a block size<br class="">of .2 * 9600 = 2400 bits = 240 bytes.<br class=""><br class="">IPv6 packets of length <= B are transmitted directly on the link.<br class="">IPv6 packets of length > B are fragmented into blocks of size B<br class="">(the last block possibly being shorter than B), and those fragments<br class="">are transmitted on the link with an FRP header containing the following<br class="">fields:<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>[packet ID, block number, end flag]<br class=""><br class="">where:<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>packet ID is the same for all fragments of the same packet,<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>and is incremented for each new fragmented packet. The size of<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>the packet ID field limits how many packets can be in flight or<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>interleaved on the link at any one time.<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>block number identifies the blocks within a packet, starting at<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>block zero. The block number field must be large enough to<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>identify 1280/B blocks.<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>end flag is a one-bit flag which is used to mark the last block<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>of a packet.<br class=""><br class="">For example, on a 9600 bps serial link, one might use a block size of<br class="">240 bytes and an 8-bit FRP header of the following format:<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>4-bit packet ID, which allows interleaving of up to 16 packets.<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>3-bit block number, to identify blocks numbered 0 through 5.<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>1-bit end flag.<br class=""><br class="">On a 256 kpbs AppleTalk link, one might use the AppleTalk-imposed block<br class="">size of ~580 bytes and an 8-bit FRP header of the following format:<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>5-bit packet ID, which allows for up to 32 fragmented packets in<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span> flight from each source across the AppleTalk internet.<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>2-bit block number, to identify blocks numbered 0 through 2.<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>1-bit end flag.<br class=""><br class="">On a multi-access link, like AppleTalk, the receiver uses the link-level<br class="">source address as well as the packet ID to identify blocks belonging to<br class="">the same packet.<br class=""><br class="">If a receiver fails to receive all of the blocks of a packet by the time<br class="">the packet number wraps around, it discards the incompletely-reassembled<br class="">packet. Taking this approach, no timers should be needed at the receiver<br class="">to detect fragment loss. We expect the transport layer (e.g., TCP) checksum<br class="">at the final IPv6 destination to detect mis-assembly that might be caused by<br class="">extreme misordering/delay during transit across the link.<br class=""><br class="">On links on which IPv6 header compression is being used, compression is<br class="">performed before fragmentation, and reassembly is done before decompression.<br class=""><br class="">----------<br class=""><br class="">Appendix II<br class=""><br class="">From: Peter Curran <<a href="mailto:peter@gate.ticl.co.uk" class="">peter@gate.ticl.co.uk</a>><br class="">Subject: Re: IPv6 MTU issue<br class="">To: <a href="mailto:deering@cisco.com" class="">deering@cisco.com</a> (Steve Deering)<br class="">Date: Mon, 22 Sep 1997 11:50:34 +0100 (BST)<br class=""><br class="">Steve<br class=""><br class="">My problem was that moving the MTU close to 1500 would have an adverse<br class="">effect on the transition strategy. The current strategy assumes that the<br class="">typical Internet MTU is >576, and that sending an IPv6 packet close to the<br class="">minimum MTU will not require any IPv4 fragmentation to support the tunnel<br class="">transparently. The PMTU discovery mechanism will 'tune' IPv6 to use a<br class="">suitable MTU.<br class=""><br class="">If the IPv4 MTU is <= 576 then IPv4 fragmentation will be required to<br class="">provide a tunnel with a minimum MTU of 576 for IPv6. This clearly places<br class="">a significant strain on the tunnelling nodes - as these will normally be<br class="">routers then there will be a demand for memory (for reassembly buffers)<br class="">as well as CPU (for the frag/reassembly process) that will have an overall<br class="">impact on performance.<br class=""><br class="">This is an acceptable risk, as Internet MTU's of <= 576 are not too common.<br class=""><br class="">However, if the minimum MTU of IPv6 is increased to something of the order<br class="">of 1200-1500 octets then the likelihood of finding an IPv4 path with an<br class="">MTU lower than this value increases (I think significantly) and this will<br class="">have a performance impact on these devices.<br class=""><br class="">During the brief discussion of this matter in the IPNG session at Munich<br class="">you stated that MTU's less than 1500 where rare. I don't agree with this<br class="">completely - it seems to be pretty common practise for smaller 2nd and 3rd<br class="">tier ISP's in the UK to use an MTU of 576 for connection to their transit<br class="">provider. Their objective, I believe, is to 'normalize' the packet sizes<br class="">on relatively low bandwidth circuits (typically <1Mbps) to provide better<br class="">performance for interactive sessions compared to bulk-file transfer users.<br class=""><br class="">I think that before we go ahead and make a decision on an increased minimum<br class="">MTU for IPv6 then we should discuss the issues a little more.<br class=""><br class="">Incidentally, I am not convinced of the benefits of doing this anyway<br class="">(ignoring the issue raised above). With a properly setup stack the PMTU<br class="">discovery mechanism seems to be able to select a good MTU for use on the<br class="">path - at least that is my experience on our test network and the 6Bone.<br class=""><br class="">I appreciate that you are trying to address the issues of PMTU for multi-<br class="">casting but I don't see how raising the minumum MTU is going to help much.<br class="">PMTU discovery will still be required irrespective of the minimum MTU<br class="">adopted, unless we adopt a value that can be used on all link-layer technolo-<br class="">gies.<br class=""><br class="">I would welcome wider discussion of these issues before pressing ahead<br class="">with a change.<br class=""><br class="">Best regards<br class=""><br class="">Peter Curran<br class="">TICL<br class=""><br class=""><br class="">--------------------------------------------------------------------<br class="">IETF IPng Working Group Mailing List<br class="">IPng Home Page: <a href="http://playground.sun.com/ipng" class="">http://playground.sun.com/ipng</a><br class="">FTP archive: <a href="ftp://playground.sun.com/pub/ipng" class="">ftp://playground.sun.com/pub/ipng</a><br class="">Direct all administrative requests to <a href="mailto:majordomo@sunroof.eng.sun.com" class="">majordomo@sunroof.eng.sun.com</a><br class="">--------------------------------------------------------------------</div></body></html>