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 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. > 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...
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
