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