Hi Fred, > -----Original Message----- > From: Fred Baker [mailto:[email protected]] > Sent: Thursday, November 29, 2018 10:55 AM > To: Templin (US), Fred L <[email protected]> > Cc: Ron Bonica <[email protected]>; Joe Touch <[email protected]>; > Stewart Bryant <[email protected]>; int-area > <[email protected]>; [email protected] > Subject: Re: [Int-area] draft-ietf-intarea-frag-fragile-03 > > I agree that this was true 30 years ago. 30 years ago, I was working on what > we would today call a variation on an Ethernet Switch, and > DEC complained bitterly about the fact that it wouldn't run at line rate. By > that, they meant that if they streamed Ethernet packets at it > at 10 MBPS back to back, it would invariably lose some - it couldn't handle a > 96 bit inter-frame gap as specified in the Ethernet II > specification. The issue was that, at the time, there were only three or four > commodity chipsets for Ethernet interfaces, and none of > them could receive and store Ethernet traffic at 10 MBPS back to back. > > I'm not worried about 10 MBPS Ethernet in 2018, nor would I expect anyone to > worry about DELQA cards in Vaxes. Unless the > comment is specifically tagged as a historical example, I would hope that we > could discuss current issues if we're writing current > advice.
The comment was specifically tagged as historical. > The only current issue that comes quickly to mind is that you use a > test/diagnostic tool that uses fragmentation to artificially generate > a high data rate, which becomes an issue on some interfaces. I recognize that > the tool exists and has the limitation, but that doesn't > seem to me to rise to the level of general Internet advice. If you are referring to iperf3, that is exactly what it does (uses fragmentation to generate a high data rate), but I would not call it "artificial" - fragmentation is a real Internet service. Thanks - Fred > > On Nov 29, 2018, at 10:39 AM, Templin (US), Fred L > > <[email protected]> wrote: > > > > Hi Ron, > > > > Sun could not get the performance they wanted with smaller than 8KB > > NFS/UDP datagrams – that is why they wrote it into the spec: > > > > “For efficient > > operation over a local network, 8192 bytes of data are normally used. > > This may result in lower-level fragmentation (such as at the IP > > level). Since some network interfaces may not allow such packets, > > for operation over slower-speed networks or hosts, or through > > gateways, transfer sizes of 512 or 1024 bytes often provide better > > results.” > > > > In the final sentence in the above, they were referring to the DELQA. > > > > Fred > > > > From: Ron Bonica [mailto:[email protected]] > > Sent: Thursday, November 29, 2018 10:27 AM > > To: Templin (US), Fred L <[email protected]>; Joe Touch > > <[email protected]>; Stewart Bryant > <[email protected]> > > Cc: int-area <[email protected]>; [email protected] > > Subject: RE: [Int-area] draft-ietf-intarea-frag-fragile-03 > > > > Fred, > > > > Without being too abrupt, there were then , and are now, much better ways > > to solve this problem. > > > > A better approach would have been to fragment / reassemble at a higher > > layer. That is the whole point of this document. > > > > Ron > > > > > > > > From: Templin (US), Fred L <[email protected]> > > Sent: Thursday, November 29, 2018 1:08 PM > > To: Joe Touch <[email protected]>; Stewart Bryant > > <[email protected]> > > Cc: Ron Bonica <[email protected]>; int-area <[email protected]>; > > [email protected] > > Subject: RE: [Int-area] draft-ietf-intarea-frag-fragile-03 > > > > Hi, regardless of how old and obsolete NFSv2 is, the text in RFC1094 > > perfectly > > addresses the point. I was working for Digital Equipment Corporation in the > > late 1980’s when Sun Microsystems first came out with NFS. The two companies > > tried to form an agreement where DEC would provide VAXen as NFS servers for > > Sun clients, but many DEC VAX systems used an Ethernet line card called the > > DELQA that was too slow to keep up with 10Mbps Ethernet line rates (!). > > > > When the VAX received a burst of IP fragments of an 8KB NFS/UDP datagram, > > it would drop one or more fragments and print “qerestart” in the system log. > > The DELQA would then reset itself and the network would be out of service > > until the restart completed. This rendered VAXen with DELQAs useless as an > > NFS server, so DEC had to qualify which of the VAX product line could > > actually > > support NFS. And, all because of IP fragmentation. > > > > So, I think there is value in keeping the citation. > > > > Thanks - Fred > > > > From: Int-area [mailto:[email protected]] On Behalf Of Joe Touch > > Sent: Thursday, November 29, 2018 8:41 AM > > To: Stewart Bryant <[email protected]> > > Cc: Ron Bonica <[email protected]>; int-area <[email protected]>; > > [email protected] > > Subject: Re: [Int-area] draft-ietf-intarea-frag-fragile-03 > > > > I would hope it would be evident from context, but sure. > > > > Joe > > > > On Nov 29, 2018, at 8:37 AM, Stewart Bryant <[email protected]> > > wrote: > > > > > > Either way it is useful to give the reviewer a heads up as to nits giving > > errors and this being OK. > > > > S > > > > On 29/11/2018 14:42, Joe Touch wrote: > > They don’t need to be deleted if you include them deliberately. There is no > > prohibition on citing such RFCs for your own documents > historical background. > > > > Joe > > > > On Nov 29, 2018, at 4:06 AM, Stewart Bryant <[email protected]> > > wrote: > > > > But, always worth including a "do be deleted" note to the reviewers to stop > > then all sending in feedback about the nits failure. > > > > Stewart > > > > > > On 27/11/2018 20:42, Joe Touch wrote: > > FWIW: > > > > > > > > > > On 2018-11-27 12:22, Ron Bonica wrote: > > > > Fred, > > > > If the NFSv2 and iPERF issues are not blocking, I would like to omit them. > > The following are rational: > > > > ... > > - Mechanically, it is difficult to reference an RFC that has been obsoleted > > in an internet draft. The NIT checker complains bitterly. > > > > Those complaints are warnings only to help those who cite such documents > > inadvertently; you can simply ignore them. (I do all the > time - esp. for historical discussions that cite early versions of newer RFCs > or historical standards). > > > > Joe > > > > > > _______________________________________________ > > Int-area mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/int-area > > > > > > _______________________________________________ > > Int-area mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/int-area > > -------------------------------------------------------------------------------- > The fact that there is a highway to hell and a stairway to heaven is an > interesting comment on projected traffic volume... _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
