From owner-Big-Internet@munnari.OZ.AU Tue Aug 6 10:16:34 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id AA09251; Tue, 6 Aug 1996 10:16:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA09405; Tue, 6 Aug 1996 10:14:44 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA09388; Tue, 6 Aug 1996 10:09:02 +1000 Received: from burnout.cts.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id AA02848; Tue, 6 Aug 1996 10:08:50 +1000 (from kwe@6SigmaNets.com) Received: from netguru.cts.com (netguru.cts.com [204.94.77.43]) by burnout.cts.com (8.6.12/8.6.9) with SMTP id RAA02023 for ; Mon, 5 Aug 1996 17:08:33 -0700 Message-Id: <2.2.32.19960806000836.00d194b8@mail.cts.com> X-Sender: kwe@mail.cts.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 05 Aug 1996 17:08:36 -0700 To: big-internet@munnari.OZ.AU From: "Kent W. England" Subject: Comparing an old flow snapshot with some packet size data Precedence: bulk Folks; I did a little traffic comparison to see what I could glean from comparing Sean Doran's flow stats posted last January with an unpublished analysis of a snippet of FIX West data, collected by Kim Claffy at NLANR and analysed by Jerry Scharf of the CIX. Back in January, Sean Doran and Dorian Kim posted some cisco IP flow stats to this list. I haven't seen any since, but my big-internet mail delivery seems spotty so I may have missed some messages. I'd be interested in seeing some more flow stats, if Sean or Dorian or anyone has been collecting more data. Sean or Dorian, would you care to post some more flow stats? Kim Claffy collected 15 minutes of traffic data from FIX West on 12 Feb 96 and Jerry Scharf analyzed the packet size distribution of that sample. I used this data in a paper I recently finished on WAN protocol overhead. Here's a portion of the packet size histogram from this data. Only packet sizes that exceed 1% of the total traffic over this fifteen minute period are listed, although Jerry's data contains counts of all the traffic that Kim collected. IP Payload Per cent of Packets 40 30.55% 41 1.51% 44 3.04% 72 4.10% 185 2.72% 296 1.48% 552 22.29% 576 3.59% 1500 1.51% All other packet sizes are less than 1% of the total, but as you can see that adds up to about 29% of the traffic. There were almost no packets larger than 1500 bytes. And the 29% of other traffic was scattered over the interval up to 1500 bytes. Jerry has a perl script that does a "what if" calculation on what the WAN protocol overhead would be if all this traffic were HDLC or FR or ATM, but so far he hasn't published anything. The most interesting thing to me is that the most common traffic is probably file transfer (whether HTTP or FTP), since the 552 bytes corresponds to a TCP payload of 512 bytes, the largest power of two smaller than the IP default MTU of 576. 30% of the traffic is a zero byte TCP payload corresponding to all the connection setup and flow control traffic for all those file transfers going on. To recall what Sean originally posted in January: -------------------begin------- This is from a fairly small-traffic router (sl-kc-2.sprintlink.net),... Sean. - -- IP Flow Switching Cache, 29999 active, 2769 inactive, 58411388 added 1418487 lru, 22352334 timeout, 20923593 tcp fin, 2633568 invalidates 5253815 dns, 5799592 resent syn, 0 counter wrap statistics cleared 141949 seconds ago Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec) -------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow TCP-Telnet 267034 1.8 233 75 439.3 182.6 36.5 TCP-FTP 1030837 7.2 10 78 76.6 22.6 43.7 TCP-FTPD 554967 3.9 164 345 641.3 52.7 15.7 TCP-WWW 32107858 226.2 15 247 3610.6 13.5 28.1 TCP-SMTP 3526231 24.8 13 159 323.1 10.2 23.6 TCP-X 9600 0.0 121 129 8.2 148.2 55.1 TCP-BGP 111096 0.7 14 77 11.5 229.2 61.1 TCP-other 5729172 40.3 70 220 2858.1 71.0 41.3 UDP-TFTP 2398 0.0 3 62 0.0 13.4 69.5 UDP-DNS 12875077 90.7 2 110 195.4 5.4 43.6 UDP-other 1489072 10.4 30 293 321.8 28.5 68.7 ICMP 665771 4.6 13 259 62.8 75.5 66.8 IGMP 5144 0.0 18 278 0.6 82.4 64.3 IPINIP 4450 0.0 933 377 29.2 166.7 61.0 IP-other 2693 0.0 11 136 0.2 80.8 65.7 Total: 58381400 411.3 20 227 8579.4 0.0 0.0 ------------------------end-------- I would say that these two different sets of statistics are roughly consistent. (Note that neither one represents a lot of data. The FIX West data is only over 15 minutes and Sean's was over the major part of a day.) Note the small number of packets per flow for WWW and FTP in Sean's data, from 10 to 15 for each flow. I don't understand the 78 bytes/pkt for FTP, but the WWW bytes/pkt of 247 is roughly consistent with the packet distribution of 30% at 40 bytes and 22% at 552. If I average 40 and 552 I get 296, near to 247. It's rough, but sensible. With all appropriate caveats about the limited sample size, the majority of the TCP flows are WWW or FTP file transfers with a data payload of about 512 bytes (from the Claffy/Scharf data) and a total number of packets about 15 (from Sean's data). If I assume it takes 2 empty packets to open the connection, 6 packets of data, 5 ACKs back, and 2 more empty packets to close, then we have a file size of about 6*512 or 3100 bytes. [I could be off on those counts, but not by much.] Therefore, the average or most common Web/FTP file size transferred is about 3000 bytes. Simon Spero's trace analysis of an HTTP page load (available at the W3C web site) is remarkably similar. All in all, these three data sources (Claffy/Scharf, Doran, Spero) seem relatively consistent. An overwhelming amount of the flows in the Internet seem to be small file transfers, the TCP payload for this traffic is mostly <=512 bytes, when it could easily be <=1460 bytes. And slow start adds at least one extra RTT to each transfer that might be avoided if the payloads were 1460 instead of 512. Would there be any improvement if hosts used path MTU discovery, or would it add up to about the same thing? I'm not sure whether you can do path MTU discovery at the same time you are starting a TCP session or whether, as is more likely, it is a separate process and uses an RTT or more before starting the TCP session. Now, is there more data to bolster or refute these conclusions? I've done what I can with what I've found, but there just isn't much data to go on anymore. But I think it is pretty consistent with the view that a lot of the traffic is WWW TCP sessions of a few kilobytes. Would you agree? --Kent (Please note that as far as I know neither Kim nor Jerry have published anything from this data, so don't bug them for information or hold them responsible in any way for what I did with it.) From owner-Big-Internet@munnari.OZ.AU Tue Aug 6 11:35:10 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id BA03499; Tue, 6 Aug 1996 11:35:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA09499; Tue, 6 Aug 1996 11:34:44 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA09481; Tue, 6 Aug 1996 11:21:01 +1000 Received: from mailhost.ipsilon.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id BA05505; Tue, 6 Aug 1996 11:20:51 +1000 (from minshall@Ipsilon.COM) Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id SAA24092; Mon, 5 Aug 1996 18:20:28 -0700 Message-Id: <199608060120.SAA24092@mailhost.Ipsilon.COM> X-Mailer: exmh version 1.6.4 10/10/95 To: "Kent W. England" Cc: big-internet@munnari.OZ.AU Subject: Re: Comparing an old flow snapshot with some packet size data In-Reply-To: Your message of "Mon, 05 Aug 1996 17:08:36 PDT." <2.2.32.19960806000836.00d194b8@mail.cts.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Aug 1996 18:20:27 -0700 From: Greg Minshall Precedence: bulk Kent, Answering your questions/observations will take some thinking (which i will do), but pointing you at some earlier work is fairly easy. Try looking at http://www.nlanr.net/NA/Learn/packetsizes.html (You might also be interested in some analysis we've done locally; try looking at http://www.ipsilon.com/aboutipsilon/staffpages/pn/papers/interop96.ps.) Greg From owner-Big-Internet@munnari.OZ.AU Tue Aug 6 14:15:48 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id EA20892; Tue, 6 Aug 1996 14:15:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA09671; Tue, 6 Aug 1996 14:15:04 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA09656; Tue, 6 Aug 1996 14:07:53 +1000 Received: from nic.hq.cic.net by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id EA15353; Tue, 6 Aug 1996 14:07:38 +1000 (from dorian@cic.net) Received: from nic.hq.cic.net (nic.hq.cic.net [198.87.19.2]) by nic.hq.cic.net (8.7.5/CICNet) with SMTP id AAA19991; Tue, 6 Aug 1996 00:07:00 -0400 (EDT) Date: Tue, 6 Aug 1996 00:06:59 -0400 (EDT) From: "Dorian R. Kim" Sender: dorian@cic.net To: "Kent W. England" Cc: big-internet@munnari.OZ.AU Subject: Re: Comparing an old flow snapshot with some packet size data In-Reply-To: <2.2.32.19960806000836.00d194b8@mail.cts.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 5 Aug 1996, Kent W. England wrote: > Back in January, Sean Doran and Dorian Kim posted some cisco IP flow stats > to this list. I haven't seen any since, but my big-internet mail delivery > seems spotty so I may have missed some messages. I'd be interested in seeing > some more flow stats, if Sean or Dorian or anyone has been collecting more > data. Sean or Dorian, would you care to post some more flow stats? I have some stats that were collected by OSU off our router. I would need to get clearance from OSU to post that. I'm waiting for installation of an ultrasparc with lots of disc before I can go back to doing anything real with flow data. There is also a question as to where I can do what I'm doing with various Cisco bits and have flow info at the same time. Nevil Brownlee from NZ and Mark Fullmer from OSU are also doing some analysis with this data. I however don't think they've gotten very far yet.. I gather that things that pays their bills are taking majority of their time. ;) -dorian From owner-Big-Internet@munnari.OZ.AU Tue Aug 6 14:55:15 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id EA06889; Tue, 6 Aug 1996 14:55:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA09723; Tue, 6 Aug 1996 14:54:48 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA09719; Tue, 6 Aug 1996 14:45:49 +1000 Received: from poblano.near.net by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id EA05860; Tue, 6 Aug 1996 14:41:55 +1000 (from jhawk@bbnplanet.com) Subject: Re: Comparing an old flow snapshot with some packet size data To: "Kent W. England" Date: Tue, 6 Aug 1996 00:41:41 -0400 (EDT) From: John Hawkinson Cc: big-internet@munnari.OZ.AU In-Reply-To: <2.2.32.19960806000836.00d194b8@mail.cts.com> from "Kent W. England" at Aug 5, 96 05:08:36 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3816 Message-Id: <9608060041.aa02539@poblano.bbnplanet.com> Precedence: bulk > From: "Kent W. England" > Subject: Comparing an old flow snapshot with some packet size data > Back in January, Sean Doran and Dorian Kim posted some cisco IP flow stats > to this list. I haven't seen any since, but my big-internet mail delivery > seems spotty so I may have missed some messages. I'd be interested in seeing > some more flow stats, if Sean or Dorian or anyone has been collecting more > data. Sean or Dorian, would you care to post some more flow stats? Just to provide you with a lack of baselines for comparison (:-)), here are the top packet sizes one of our transit FDDI rings between 1200 and 1300 EDT today: Size %Packets %Bytes 40 36.4837 4.5397 552 19.2812 33.1087 576 9.56957 17.1468 1500 4.84203 22.5937 44 4.00251 0.547841 41 2.48799 0.317323 52 0.573903 0.0928349 60 0.505717 0.0943905 48 0.484214 0.0723015 72 0.467757 0.104766 56 0.435227 0.0758182 42 0.400778 0.0523627 296 0.340765 0.313773 84 0.326612 0.0853456 45 0.305438 0.0427568 43 0.297758 0.0398292 588 0.297319 0.543838 Binning to histograms of 10 bytes Size %Packets %Bytes 40-50 45.020109 5.693618 550-560 19.326785 33.187304 570-580 9.604513 17.209135 1500-1510 4.842249 22.594727 50-60 2.133512 0.362158 60-70 1.659997 0.326584 70-80 1.633336 0.374121 80-90 1.030689 0.269704 290-300 0.555307 0.510068 140-150 0.522942 0.234360 > Would there be any improvement if hosts used path MTU discovery, or would it > add up to about the same thing? I'm not sure whether you can do path MTU > discovery at the same time you are starting a TCP session or whether, as is > more likely, it is a separate process and uses an RTT or more before > starting the TCP session. There would be QUITE A LOT of improvement if everyone used Path MTU Discovery. There would be quite a lot of improvement if everyone changed the TCP default MSS on their unix boxes to 1460 instead of 576. In the former case, most inplementations assume that the interface MTU - ip header is the maximum length, and will send that as the MSS when they open a TCP connection. They will send any data up-to that size in a single packet with the DF bit set, and will only fragment if they get back an indication that such is necessary. There are relatively few links in the Internet that don't support a 1500-byte MTU that it's well worth the extra RTT. Further, those hosts that don't have 1500-byte MTUs tend to be behind slow links (i.e. dialup links) where an extra RTT is probably not all that significant. This is the standard way of implementing PMD, and it's how it works in Solaris, for instance. There is no intial-RTT cost for setup in the general (non-fragemented case). If you don't have PMD and just up the max segmenet size, you do the same thing except you don't set Dont Fragment on your packets. This may actually be more efficient because it causes fragmentation to happen at the places in the network where low-MTU links exist. If you assume that those are few and far -between, and are special cases who should be willing to bear the cost of doing fragmentation themselves, this is a good thing. It doesn't work so well if your host is FDDI-connected, because many Internet links can't support the FDDI MSS. But you can set your FDDI link to the Ethernet MSS and still see a good improvement. Of course, this methodology doesn't work for IPv6, but PMD is required there, anyhow. --jhawk John Hawkinson From owner-Big-Internet@munnari.OZ.AU Tue Aug 6 14:58:31 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id EA22884; Tue, 6 Aug 1996 14:58:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA09758; Tue, 6 Aug 1996 14:57:46 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA09716; Tue, 6 Aug 1996 14:44:20 +1000 Received: from poblano.near.net by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id EA05164; Tue, 6 Aug 1996 14:44:15 +1000 (from jhawk@bbnplanet.com) Subject: Re: Comparing an old flow snapshot with some packet size data To: "Kent W. England" Date: Tue, 6 Aug 1996 00:41:41 -0400 (EDT) From: John Hawkinson Cc: big-internet@munnari.OZ.AU In-Reply-To: <2.2.32.19960806000836.00d194b8@mail.cts.com> from "Kent W. England" at Aug 5, 96 05:08:36 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3816 Message-Id: <9608060041.aa02539@poblano.bbnplanet.com> Precedence: bulk > From: "Kent W. England" > Subject: Comparing an old flow snapshot with some packet size data > Back in January, Sean Doran and Dorian Kim posted some cisco IP flow stats > to this list. I haven't seen any since, but my big-internet mail delivery > seems spotty so I may have missed some messages. I'd be interested in seeing > some more flow stats, if Sean or Dorian or anyone has been collecting more > data. Sean or Dorian, would you care to post some more flow stats? Just to provide you with a lack of baselines for comparison (:-)), here are the top packet sizes one of our transit FDDI rings between 1200 and 1300 EDT today: Size %Packets %Bytes 40 36.4837 4.5397 552 19.2812 33.1087 576 9.56957 17.1468 1500 4.84203 22.5937 44 4.00251 0.547841 41 2.48799 0.317323 52 0.573903 0.0928349 60 0.505717 0.0943905 48 0.484214 0.0723015 72 0.467757 0.104766 56 0.435227 0.0758182 42 0.400778 0.0523627 296 0.340765 0.313773 84 0.326612 0.0853456 45 0.305438 0.0427568 43 0.297758 0.0398292 588 0.297319 0.543838 Binning to histograms of 10 bytes Size %Packets %Bytes 40-50 45.020109 5.693618 550-560 19.326785 33.187304 570-580 9.604513 17.209135 1500-1510 4.842249 22.594727 50-60 2.133512 0.362158 60-70 1.659997 0.326584 70-80 1.633336 0.374121 80-90 1.030689 0.269704 290-300 0.555307 0.510068 140-150 0.522942 0.234360 > Would there be any improvement if hosts used path MTU discovery, or would it > add up to about the same thing? I'm not sure whether you can do path MTU > discovery at the same time you are starting a TCP session or whether, as is > more likely, it is a separate process and uses an RTT or more before > starting the TCP session. There would be QUITE A LOT of improvement if everyone used Path MTU Discovery. There would be quite a lot of improvement if everyone changed the TCP default MSS on their unix boxes to 1460 instead of 576. In the former case, most inplementations assume that the interface MTU - ip header is the maximum length, and will send that as the MSS when they open a TCP connection. They will send any data up-to that size in a single packet with the DF bit set, and will only fragment if they get back an indication that such is necessary. There are relatively few links in the Internet that don't support a 1500-byte MTU that it's well worth the extra RTT. Further, those hosts that don't have 1500-byte MTUs tend to be behind slow links (i.e. dialup links) where an extra RTT is probably not all that significant. This is the standard way of implementing PMD, and it's how it works in Solaris, for instance. There is no intial-RTT cost for setup in the general (non-fragemented case). If you don't have PMD and just up the max segmenet size, you do the same thing except you don't set Dont Fragment on your packets. This may actually be more efficient because it causes fragmentation to happen at the places in the network where low-MTU links exist. If you assume that those are few and far -between, and are special cases who should be willing to bear the cost of doing fragmentation themselves, this is a good thing. It doesn't work so well if your host is FDDI-connected, because many Internet links can't support the FDDI MSS. But you can set your FDDI link to the Ethernet MSS and still see a good improvement. Of course, this methodology doesn't work for IPv6, but PMD is required there, anyhow. --jhawk John Hawkinson From owner-Big-Internet@munnari.OZ.AU Wed Aug 7 03:55:11 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id RA19217; Wed, 7 Aug 1996 03:55:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA10535; Wed, 7 Aug 1996 03:54:56 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA10529; Wed, 7 Aug 1996 03:53:18 +1000 Received: from BBN.COM by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id RA06951; Wed, 7 Aug 1996 03:53:08 +1000 (from MAP=Bounce@BBN.COM) Received: by BBN.COM id ae09946; 6 Aug 96 13:47 EDT Received: from BART.BBN.COM by BBN.COM id aa09585; 6 Aug 96 13:37 EDT Date: Tue, 6 Aug 1996 13:36:55 EDT Message-Id: To: kwe@6sigmanets.com Cc: big-internet@munnari.OZ.AU In-Reply-To: <2.2.32.19960806000836.00d194b8@mail.cts.com> (kwe@6sigmanets.com) Subject: Re: Comparing an old flow snapshot with some packet size data From: "Michael A. Patton" Reply-To: "Michael A. Patton, Big-Internet mail" Precedence: bulk Date: Mon, 05 Aug 1996 17:08:36 -0700 From: "Kent W. England" ... I don't understand the 78 bytes/pkt for FTP, [in Sean's sample] Note that this is on the FTP control port. The actual data is on other ports and can't easily be recognized... I'm not sure how to interpret that as it's less than I would expect (the FTP control connection should have both IP and TCP overhead on every packet, and I would expect more than half the packets to have either an FTP command or response in them, this makes 78 seem too small to me on first thought). but the WWW bytes/pkt of 247 is roughly consistent with the packet distribution of 30% at 40 bytes and 22% at 552. If I average 40 and 552 I get 296, near to 247. It's rough, but sensible. Or to do a pro-rated average (probably a little better, although still only an estimate): (30*40+22*552)/(30+22) => 256 (even closer to 247 and an interesting number in it's own right :-). -MAP From owner-Big-Internet@munnari.OZ.AU Wed Aug 7 05:55:09 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA07861; Wed, 7 Aug 1996 05:55:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA10673; Wed, 7 Aug 1996 05:54:58 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA10667; Wed, 7 Aug 1996 05:53:55 +1000 Received: from mailhost.ipsilon.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA14228; Wed, 7 Aug 1996 05:53:54 +1000 (from minshall@Ipsilon.COM) Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id MAA27842; Tue, 6 Aug 1996 12:53:52 -0700 Message-Id: <199608061953.MAA27842@mailhost.Ipsilon.COM> X-Mailer: exmh version 1.6.4 10/10/95 To: "Kent W. England" Cc: big-internet@munnari.OZ.AU Subject: Re: Comparing an old flow snapshot with some packet size data In-Reply-To: Your message of "Mon, 05 Aug 1996 17:08:36 PDT." <2.2.32.19960806000836.00d194b8@mail.cts.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Aug 1996 12:53:51 -0700 From: Greg Minshall Precedence: bulk Kent, Having cogitated a bit... > All in all, these three data sources (Claffy/Scharf, Doran, Spero) seem > relatively consistent. An overwhelming amount of the flows in the Internet > seem to be small file transfers, the TCP payload for this traffic is mostly > <=512 bytes, when it could easily be <=1460 bytes. And slow start adds at > least one extra RTT to each transfer that might be avoided if the payloads > were 1460 instead of 512. I think you are saying that if TCP sent 1460 bytes in the first [data] packet, then lots of transfers would only have one data packet, but that since it is using 512 bytes, transfers take 3 (say) data packets, so slow start kicks in and it takes 2 RTTs to transfer that data. I think that is probably true, though if transfer sizes are, say, 3000 bytes (which you mentioned), then even with 1460, "slow start" imposes a 2.x RTT "penalty". On the other hand, that "penalty" is there, of course, to keep the net alive. > Would there be any improvement if hosts used path MTU discovery, or would it > add up to about the same thing? I'm not sure whether you can do path MTU > discovery at the same time you are starting a TCP session or whether, as is > more likely, it is a separate process and uses an RTT or more before > starting the TCP session. (I guess i'm not totally sure what "constituency" you represent in this, in the sense of i.e., PPP users at the end of 28.8 links, or network providers trying to figure out how to provision, or corporate intXXnet builders, etc. For example, when you say "improvement", improvement for *whom*?) You can do path MTU "at the same time" you are starting a TCP session. *I* think it would help. Systems are also free [encouraged! -- see http://info.internet.isi.edu:80/in-no tes/rfc/files/rfc1191.txt] to "remember" previous path MTU values to various destinations to try to "optimize" the path MTU start up time; so, it would be much better if each of the web pages downloads for images from a given site didn't have to individually "learn" the path MTU, but could "share" that knowledge from the first download. Unfortunately, this involves a bit of thinking and coding (neither of which i've done!), and so isn't totally straightforward. Greg From owner-Big-Internet@munnari.OZ.AU Wed Aug 7 07:55:20 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id VA17348; Wed, 7 Aug 1996 07:55:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA10805; Wed, 7 Aug 1996 07:54:59 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA10798; Wed, 7 Aug 1996 07:40:14 +1000 Received: from burnout.cts.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id VA30748; Wed, 7 Aug 1996 07:40:12 +1000 (from kwe@6SigmaNets.com) Received: from netguru.cts.com (kent-england.pbi.net [206.13.1.58]) by burnout.cts.com (8.6.12/8.6.9) with SMTP id OAA29055; Tue, 6 Aug 1996 14:40:09 -0700 Message-Id: <2.2.32.19960806214515.006ffa20@mail.cts.com> X-Sender: kwe@mail.cts.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 06 Aug 1996 14:45:15 -0700 To: Greg Minshall , "Kent W. England" From: "Kent W. England" Subject: Re: Comparing an old flow snapshot with some packet size data Cc: big-internet@munnari.OZ.AU Precedence: bulk At 12:53 PM 8/6/96 -0700, Greg Minshall wrote: >Kent, > >Having cogitated a bit... > My thanks. > >I think you are saying that if TCP sent 1460 bytes in the first [data] packet, >then lots of transfers would only have one data packet, but that since it is >using 512 bytes, transfers take 3 (say) data packets, so slow start kicks in >and it takes 2 RTTs to transfer that data. Yes, but to be fair this is what Simon Spero first said in his paper on HTTP. < http://sunsite.unc.edu/mdma-release/http-prob.html > > >I think that is probably true, though if transfer sizes are, say, 3000 bytes >(which you mentioned), then even with 1460, "slow start" imposes a 2.x RTT >"penalty". On the other hand, that "penalty" is there, of course, to keep the >net alive. > >> Would there be any improvement if hosts used path MTU discovery, or would it >> add up to about the same thing? I'm not sure whether you can do path MTU >> discovery at the same time you are starting a TCP session or whether, as is >> more likely, it is a separate process and uses an RTT or more before >> starting the TCP session. > >(I guess i'm not totally sure what "constituency" you represent in this, in >the sense of i.e., PPP users at the end of 28.8 links, or network providers >trying to figure out how to provision, or corporate intXXnet builders, etc. >For example, when you say "improvement", improvement for *whom*?) > I was only thinking of "users", whoever they are (including me). But the GOP convention is happening in my hometown next week and if anyone on this list would be my constituency, I'll put myself down against ol' Bob as the candidate! A vote for me is a vote for path MTU! :-) Seriously, if RTTs are the problem then this issue holds for 28.8 PPP users as well as corporate users. In fact, this problem came home to me in spades when I upgraded my residential access from 28.8 to 112.5 (hardware, you know) ISDN and found little performance improvement on many pages. >You can do path MTU "at the same time" you are starting a TCP session. *I* >think it would help. > >Systems are also free [encouraged! -- see http://info.internet.isi.edu:80/in-no >tes/rfc/files/rfc1191.txt] to "remember" previous path MTU values to various >destinations to try to "optimize" the path MTU start up time; so, it would be >much better if each of the web pages downloads for images from a given site >didn't have to individually "learn" the path MTU, but could "share" that >knowledge from the first download. Unfortunately, this involves a bit of >thinking and coding (neither of which i've done!), and so isn't totally >straightforward. > >Greg > > Of course this is also addressed by HTTPng. Can we hold our breath that long? See < http://www.w3.org/pub/WWW/Protocols/HTTP-NG/Overview.html > --Kent From owner-Big-Internet@munnari.OZ.AU Wed Aug 7 12:36:10 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id CA00812; Wed, 7 Aug 1996 12:36:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA11091; Wed, 7 Aug 1996 12:35:02 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA11076; Wed, 7 Aug 1996 12:23:51 +1000 Received: from lint.cisco.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id CA09003; Wed, 7 Aug 1996 12:23:46 +1000 (from pferguso@cisco.com) Received: from pferguso-pc.cisco.com (c1robo8.cisco.com [171.68.13.8]) by lint.cisco.com (8.6.12/CISCO.SERVER.1.1) with SMTP id TAA05610; Tue, 6 Aug 1996 19:24:44 -0700 Message-Id: <199608070224.TAA05610@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 06 Aug 1996 22:23:33 -0400 To: John Hawkinson From: Paul Ferguson Subject: Re: Comparing an old flow snapshot with some packet size data Cc: "Kent W. England" , big-internet@munnari.OZ.AU Precedence: bulk Not that this isn't interesting data (it is), but it would even be more valuable if there were a painless mechanism to derive the arrival sequence of the various packet sizes in a timeline relationship to the distributions we've seen thus far. Food for thought. - paul At 12:41 AM 8/6/96 -0400, John Hawkinson wrote: > >Just to provide you with a lack of baselines for comparison (:-)), here >are the top packet sizes one of our transit FDDI rings between >1200 and 1300 EDT today: > >Size %Packets %Bytes >40 36.4837 4.5397 >552 19.2812 33.1087 >576 9.56957 17.1468 >1500 4.84203 22.5937 >44 4.00251 0.547841 >41 2.48799 0.317323 >52 0.573903 0.0928349 >60 0.505717 0.0943905 >48 0.484214 0.0723015 >72 0.467757 0.104766 >56 0.435227 0.0758182 >42 0.400778 0.0523627 >296 0.340765 0.313773 >84 0.326612 0.0853456 >45 0.305438 0.0427568 >43 0.297758 0.0398292 >588 0.297319 0.543838 > >Binning to histograms of 10 bytes > >Size %Packets %Bytes >40-50 45.020109 5.693618 >550-560 19.326785 33.187304 >570-580 9.604513 17.209135 >1500-1510 4.842249 22.594727 >50-60 2.133512 0.362158 >60-70 1.659997 0.326584 >70-80 1.633336 0.374121 >80-90 1.030689 0.269704 >290-300 0.555307 0.510068 >140-150 0.522942 0.234360 > >> Would there be any improvement if hosts used path MTU discovery, or would it >> add up to about the same thing? I'm not sure whether you can do path MTU >> discovery at the same time you are starting a TCP session or whether, as is >> more likely, it is a separate process and uses an RTT or more before >> starting the TCP session. > >There would be QUITE A LOT of improvement if everyone used Path MTU >Discovery. There would be quite a lot of improvement if everyone >changed the TCP default MSS on their unix boxes to 1460 instead of >576. > >In the former case, most inplementations assume that the interface >MTU - ip header is the maximum length, and will send that as the MSS >when they open a TCP connection. They will send any data up-to that >size in a single packet with the DF bit set, and will only fragment >if they get back an indication that such is necessary. There are >relatively few links in the Internet that don't support a 1500-byte >MTU that it's well worth the extra RTT. Further, those hosts that >don't have 1500-byte MTUs tend to be behind slow links (i.e. dialup >links) where an extra RTT is probably not all that significant. This >is the standard way of implementing PMD, and it's how it works >in Solaris, for instance. There is no intial-RTT cost for setup in the >general (non-fragemented case). > >If you don't have PMD and just up the max segmenet size, you do the >same thing except you don't set Dont Fragment on your packets. This >may actually be more efficient because it causes fragmentation >to happen at the places in the network where low-MTU links exist. >If you assume that those are few and far -between, and are special >cases who should be willing to bear the cost of doing fragmentation >themselves, this is a good thing. It doesn't work so well if your >host is FDDI-connected, because many Internet links can't support >the FDDI MSS. But you can set your FDDI link to the Ethernet MSS >and still see a good improvement. Of course, this methodology doesn't >work for IPv6, but PMD is required there, anyhow. > >--jhawk > John Hawkinson > From owner-Big-Internet@munnari.OZ.AU Fri Aug 9 06:16:17 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id UA09394; Fri, 9 Aug 1996 06:16:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA13356; Fri, 9 Aug 1996 06:15:30 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA13339; Fri, 9 Aug 1996 05:58:58 +1000 Received: from home.partan.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA31071; Fri, 9 Aug 1996 05:58:55 +1000 (from asp@partan.com) Received: (from asp@localhost) by home.partan.com (8.6.12/8.6.12) id PAA01711; Thu, 8 Aug 1996 15:58:00 -0400 From: Andrew Partan Message-Id: <199608081958.PAA01711@home.partan.com> Subject: Re: Comparing an old flow snapshot with some packet size data To: pferguso@cisco.com (Paul Ferguson) Date: Thu, 8 Aug 1996 15:58:00 -0400 (EDT) Cc: jhawk@bbnplanet.com, kwe@6sigmanets.com, big-internet@munnari.OZ.AU In-Reply-To: <199608070224.TAA05610@lint.cisco.com> from "Paul Ferguson" at Aug 6, 96 10:23:33 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 448 Precedence: bulk This is all interesting stuff. One question that I have been trying to figure out is What size MTU should an ISP support on its backbone? If we view the future where lots of hosts are connected via ethernet and fast ethernet & the like, then a MTU of 1500 would be 'correct'. If we think that the future will have lots of hosts connected via Fddi or similar, then a MTU of 4470 would be 'better'. Any ideas? --asp@partan.com (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Fri Aug 9 06:35:44 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id UA08047; Fri, 9 Aug 1996 06:35:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA13396; Fri, 9 Aug 1996 06:35:29 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA13387; Fri, 9 Aug 1996 06:27:50 +1000 Received: from lint.cisco.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id UA26539; Fri, 9 Aug 1996 06:27:48 +1000 (from pferguso@cisco.com) Received: from pferguso-pc.cisco.com (c1robo14.cisco.com [171.68.13.14]) by lint.cisco.com (8.6.12/CISCO.SERVER.1.1) with SMTP id NAA12772; Thu, 8 Aug 1996 13:27:33 -0700 Message-Id: <199608082027.NAA12772@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 08 Aug 1996 16:26:22 -0400 To: Andrew Partan From: Paul Ferguson Subject: Re: Comparing an old flow snapshot with some packet size data Cc: jhawk@bbnplanet.com, kwe@6sigmanets.com, big-internet@munnari.OZ.AU Precedence: bulk Well, one would think that the answer hinges on the life-expectancy of FDDI, as opposed to higher-speed media (giagbit-ethernet?).... - paul At 03:58 PM 8/8/96 -0400, Andrew Partan wrote: >This is all interesting stuff. > >One question that I have been trying to figure out is > What size MTU should an ISP support on its backbone? > >If we view the future where lots of hosts are connected via ethernet >and fast ethernet & the like, then a MTU of 1500 would be 'correct'. > >If we think that the future will have lots of hosts connected via >Fddi or similar, then a MTU of 4470 would be 'better'. > >Any ideas? > --asp@partan.com (Andrew Partan) > From owner-Big-Internet@munnari.OZ.AU Fri Aug 9 06:37:20 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id UA14398; Fri, 9 Aug 1996 06:37:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA13418; Fri, 9 Aug 1996 06:37:05 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA13390; Fri, 9 Aug 1996 06:32:52 +1000 Received: from mailhost.ipsilon.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id UA02403; Fri, 9 Aug 1996 06:32:50 +1000 (from minshall@Ipsilon.COM) Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id NAA07558; Thu, 8 Aug 1996 13:31:37 -0700 Message-Id: <199608082031.NAA07558@mailhost.Ipsilon.COM> X-Mailer: exmh version 1.6.4 10/10/95 To: Andrew Partan Cc: pferguso@cisco.com (Paul Ferguson), jhawk@bbnplanet.com, kwe@6sigmanets.com, big-internet@munnari.OZ.AU Subject: Re: Comparing an old flow snapshot with some packet size data In-Reply-To: Your message of "Thu, 08 Aug 1996 15:58:00 EDT." <199608081958.PAA01711@home.partan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 08 Aug 1996 13:31:37 -0700 From: Greg Minshall Precedence: bulk Andrew, > If we view the future where lots of hosts are connected via ethernet > and fast ethernet & the like, then a MTU of 1500 would be 'correct'. > > If we think that the future will have lots of hosts connected via > Fddi or similar, then a MTU of 4470 would be 'better'. Personally, i can't imagine anything except ethernet, ethernet, and more ethernet into the future. Circa 1970, Djikstra (i believe) said something like "I don't know what the major scientific programming language 20 years from now will *look* like, but it will be *called* Fortran." He wasn't all wrong. Similarly, i don't know what the data link ten years from now will *look* like, but it will probably be *called* ethernet. (Note that gigabit ethernet *looks* an awful lot like fibre channel, or so i am told.) Greg Minshall From owner-Big-Internet@munnari.OZ.AU Fri Aug 9 06:55:47 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id UA03497; Fri, 9 Aug 1996 06:55:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA13464; Fri, 9 Aug 1996 06:55:29 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA13449; Fri, 9 Aug 1996 06:44:45 +1000 Received: from Kitten.mcs.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id UA25820; Fri, 9 Aug 1996 06:44:39 +1000 (from karl@mcs.com) Received: from venus.mcs.com (root@Venus.mcs.com [192.160.127.92]) by Kitten.mcs.com (8.7.5/8.7.5) with SMTP id PAA11379; Thu, 8 Aug 1996 15:41:22 -0500 (CDT) Received: by venus.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Thu, 8 Aug 96 15:41 CDT Message-Id: Subject: Re: Comparing an old flow snapshot with some packet size data To: asp@partan.com (Andrew Partan) Date: Thu, 8 Aug 1996 15:41:21 -0500 (CDT) From: "Karl Denninger, MCSNet" Cc: pferguso@cisco.com, jhawk@bbnplanet.com, kwe@6SigmaNets.com, big-internet@munnari.OZ.AU In-Reply-To: <199608081958.PAA01711@home.partan.com> from "Andrew Partan" at Aug 8, 96 03:58:00 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Precedence: bulk > > This is all interesting stuff. > > One question that I have been trying to figure out is > What size MTU should an ISP support on its backbone? > > If we view the future where lots of hosts are connected via ethernet > and fast ethernet & the like, then a MTU of 1500 would be 'correct'. > > If we think that the future will have lots of hosts connected via > Fddi or similar, then a MTU of 4470 would be 'better'. > > Any ideas? > --asp@partan.com (Andrew Partan) Well, 4470 is the common FDDI and HSSI MTU, and so that's a pretty common one for high-speed links... The trade-off IMHO has to do with the technology changes. Cram 4470 into 53-byte cells for ATM, and you end up needing 85 of them for each segment! I suspect that some of the buffering problems we've seen with things like Netedge boxes can be traced to that kind of encapsulation change problem... Cut that MTU to 1500 and now you only need 29 cells for a segment. Much less likely to run into trouble. The bigger problem is that some hardware out there can't hope to keep up at DS-3 rates and above with very small segment sizes. I don't know how much of a problem this is in the real high-end hardware, but I do know that it shows up instantly for those people trying to do the "cheap router in a PC box" solutions. Reports from the field are that a "100Mbps" network on which a PCI Pentium is sourcing or sinking traffic can not really expect to see more than about 50Mbps due to the packet processing overhead in this environment with a 1500 byte MTU -- but that number rises to nearly 85Mbps with a 4470 MTU. Its not moving the data that is killing the throughput -- its handling the encapsulation overhead. I don't know how many people are stressing their backbone hardware far enough in a restricted-MTU environment (intentionally) to know if this is really a problem out there or not in the real world on the core. Can a CISCO 7513, for example, handle near-theoretical throughput on a FDDI ring if you change the MTU size to 1500 from 4470? Or does its routing performance suffer? -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1 from $600 monthly; speeds to DS-3 available | 23 Chicagoland Prefixes, 13 ISDN, much more Voice: [+1 312 803-MCS1] | Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | Home of Chicago's only FULL Clarinet feed! From owner-Big-Internet@munnari.OZ.AU Fri Aug 9 07:15:43 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id VA05499; Fri, 9 Aug 1996 07:15:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA13503; Fri, 9 Aug 1996 07:15:31 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA13478; Fri, 9 Aug 1996 06:56:42 +1000 Received: from sabine.us.dell.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id UA32190; Fri, 9 Aug 1996 06:56:16 +1000 (from evanw@sabine.us.dell.com) Received: from localhost (evanw@localhost) by sabine.us.dell.com (8.6.5/8.6.5) id PAA03507; Thu, 8 Aug 1996 15:54:35 -0500 From: Evan Wetstone Message-Id: <199608082054.PAA03507@sabine.us.dell.com> Subject: Re: Comparing an old flow snapshot with some packet size data To: asp@partan.com (Andrew Partan) Date: Thu, 8 Aug 1996 15:54:35 -0500 (CDT) Cc: pferguso@cisco.com, jhawk@bbnplanet.com, kwe@6sigmanets.com, big-internet@munnari.OZ.AU In-Reply-To: <199608081958.PAA01711@home.partan.com> from "Andrew Partan" at Aug 8, 96 03:58:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 914 Precedence: bulk > > This is all interesting stuff. > > One question that I have been trying to figure out is > What size MTU should an ISP support on its backbone? > > If we view the future where lots of hosts are connected via ethernet > and fast ethernet & the like, then a MTU of 1500 would be 'correct'. > > If we think that the future will have lots of hosts connected via > Fddi or similar, then a MTU of 4470 would be 'better'. > > Any ideas? I certainly envision networks of ethernet, fast ethernet, and eventually gigabit ethernet as opposed to FDDI or the like. The interfaces are generally cheaper, and I think people are more comfortable with ethernet and ethernet-like technology than they are with FDDI, etc. The networks we build here are entirely ethernet and fast ethernet based. > --asp@partan.com (Andrew Partan) > -- Evan Wetstone evanw@dell.com From owner-Big-Internet@munnari.OZ.AU Fri Aug 9 10:36:21 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id AA19833; Fri, 9 Aug 1996 10:36:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA13686; Fri, 9 Aug 1996 10:35:32 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA13677; Fri, 9 Aug 1996 10:34:12 +1000 Received: from burnout.cts.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id AA26567; Fri, 9 Aug 1996 10:34:09 +1000 (from kwe@6SigmaNets.com) Received: from netguru.cts.com (netguru.cts.com [204.94.77.43]) by burnout.cts.com (8.6.12/8.6.9) with SMTP id RAA27545; Thu, 8 Aug 1996 17:33:43 -0700 Message-Id: <2.2.32.19960809003355.00703fe4@mail.cts.com> X-Sender: kwe@mail.cts.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 08 Aug 1996 17:33:55 -0700 To: Andrew Partan , pferguso@cisco.com (Paul Ferguson) From: "Kent W. England" Subject: Re: Comparing an old flow snapshot with some packet size data Cc: jhawk@bbnplanet.com, big-internet@munnari.OZ.AU Precedence: bulk At 03:58 PM 8/8/96 -0400, Andrew Partan wrote: >This is all interesting stuff. > >One question that I have been trying to figure out is > What size MTU should an ISP support on its backbone? > Is there any performance reason, such as buffer memory, that is constrained to the point where a 10k MTU couldn't be supported? After all, if the hosts don't support 1500, you'll still see 576 or 552 byte sizes along with the 40 byte signals. Why not go to 9180? --Kent From owner-Big-Internet@munnari.OZ.AU Fri Aug 9 10:40:39 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id AA14473; Fri, 9 Aug 1996 10:40:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA13719; Fri, 9 Aug 1996 10:40:19 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA13680; Fri, 9 Aug 1996 10:34:46 +1000 Received: from burnout.cts.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id AA32269; Fri, 9 Aug 1996 10:34:44 +1000 (from kwe@6SigmaNets.com) Received: from netguru.cts.com (netguru.cts.com [204.94.77.43]) by burnout.cts.com (8.6.12/8.6.9) with SMTP id RAA27548; Thu, 8 Aug 1996 17:33:46 -0700 Message-Id: <2.2.32.19960809003359.0073ab6c@mail.cts.com> X-Sender: kwe@mail.cts.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 08 Aug 1996 17:33:59 -0700 To: "Karl Denninger, MCSNet" , asp@partan.com (Andrew Partan) From: "Kent W. England" Subject: Re: Comparing an old flow snapshot with some packet size data Cc: pferguso@cisco.com, jhawk@bbnplanet.com, big-internet@munnari.OZ.AU Precedence: bulk At 03:41 PM 8/8/96 -0500, Karl Denninger, MCSNet wrote: > >The trade-off IMHO has to do with the technology changes. Cram 4470 into >53-byte cells for ATM, and you end up needing 85 of them for each segment! >I suspect that some of the buffering problems we've seen with things like >Netedge boxes can be traced to that kind of encapsulation change problem... > >Cut that MTU to 1500 and now you only need 29 cells for a segment. Much >less likely to run into trouble. My experience with the PacBell NAP has led me to conclude that ATM performance is best optimized with very large packets. It's better, in my opinion, to operate with large packets over a zero cell loss ATM network than to pay the extra 2 or 3% that smaller frame sizes cost on the padding overhead. The Stratacom switches have plenty of buffer space and large frame sizes are more efficient if you have large ATM buffers, explicit flow control and zero cell loss. (Now, technically, we aren't talking zero cell loss but practically speaking as near to zero as one can get.) I'm sure that other ATM switches with large buffers and flow control work as well, but those that don't, well, they don't quite cut it. So, since routers work better with larger frame sizes and so do ATM switches, then it's safe to say that increasing the MTU is a good thing. > >The bigger problem is that some hardware out there can't hope to keep up at >DS-3 rates and above with very small segment sizes. I don't know how much >of a problem this is in the real high-end hardware, but I do know that it >shows up instantly for those people trying to do the "cheap router in a PC >box" solutions. Reports from the field are that a "100Mbps" network >on which a PCI Pentium is sourcing or sinking traffic can not really expect >to see more than about 50Mbps due to the packet processing overhead in >this environment with a 1500 byte MTU -- but that number rises to nearly >85Mbps with a 4470 MTU. Its not moving the data that is killing the >throughput -- its handling the encapsulation overhead. > The situation is a bit different if you can assume fixed size packets. Right now, the only ones who can claim the prize for very high speed are the cell switch makers. Perhaps by the end of the year, there will be a new router that can compete with the best fixed length cell switch. If not, then certainly some other folks will have a shot next year. But right now the ATM switch makers have a clear path to OC-12 and beyond and the router folks aren't there. If we could just get the cell size up a bit to, say, 1500 bytes. :-) --Kent From owner-Big-Internet@munnari.OZ.AU Fri Aug 9 11:35:55 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id BA21580; Fri, 9 Aug 1996 11:35:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA13783; Fri, 9 Aug 1996 11:35:33 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA13766; Fri, 9 Aug 1996 11:24:33 +1000 Received: from [204.157.153.2] by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id BA09690; Fri, 9 Aug 1996 11:24:30 +1000 (from jerry@freeside.fc.net) Received: from freeside.fc.net (localhost.fc.net [127.0.0.1]) by freeside.fc.net (8.6.12/8.6.6) with ESMTP id UAA06782; Thu, 8 Aug 1996 20:24:04 -0500 Message-Id: <199608090124.UAA06782@freeside.fc.net> To: Andrew Partan Cc: pferguso@cisco.com (Paul Ferguson), jhawk@bbnplanet.com, kwe@6sigmanets.com, big-internet@munnari.OZ.AU Subject: Re: Comparing an old flow snapshot with some packet size data In-Reply-To: Your message of "Thu, 08 Aug 1996 15:58:00 EDT." <199608081958.PAA01711@home.partan.com> Date: Thu, 08 Aug 1996 20:24:03 -0500 From: Jeremy Porter Precedence: bulk I remember arguing this about 6-9 months ago. Except from an exchange point point of view. Based on current traffic patterns I ended up recommend switched full duplex ethernet as the most cost effective and least complex protocol to run. FDDI has as lot of unneeded overhead. So unless you expect to see FDDI deployment to exceed X% of total LANs then total FDDI MTUs will be less than X%. (Assuming relativlity equal data volumes from ethernet and FDDI (which may not be true due to larger pipes at FDDI sites)). However some straight forward market research should be possible to determin relative sizes. And unless people start scrapping all that old technology we are going to have to design for lots of smaller packets rather than fewer large MTU packets. I would prefere to have fast packet switches and routers, than having to fragment packets inside my network. But that depends on the cost between packet fragmentation v. carrying more packets. Someone really should just design a larger MTU for 100BaseTX, i.e. 100BaseTX-BIG. With a MTU of 4470 say. In message <199608081958.PAA01711@home.partan.com>, Andrew Partan writes: >This is all interesting stuff. > >One question that I have been trying to figure out is > What size MTU should an ISP support on its backbone? > >If we view the future where lots of hosts are connected via ethernet >and fast ethernet & the like, then a MTU of 1500 would be 'correct'. > >If we think that the future will have lots of hosts connected via >Fddi or similar, then a MTU of 4470 would be 'better'. > >Any ideas? > --asp@partan.com (Andrew Partan) --- Jeremy Porter, Freeside Communications, Inc. jerry@fc.net PO BOX 80315 Austin, Tx 78708 | 1-800-968-8750 | 512-458-9816 http://www.fc.net From owner-Big-Internet@munnari.OZ.AU Fri Aug 9 11:55:57 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id BA07185; Fri, 9 Aug 1996 11:55:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA13831; Fri, 9 Aug 1996 11:55:33 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA13814; Fri, 9 Aug 1996 11:44:55 +1000 Received: from nic.hq.cic.net by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id BA07002; Fri, 9 Aug 1996 11:44:50 +1000 (from dorian@cic.net) Received: from nic.hq.cic.net (nic.hq.cic.net [198.87.19.2]) by nic.hq.cic.net (8.7.5/CICNet) with SMTP id VAA04609; Thu, 8 Aug 1996 21:44:41 -0400 (EDT) Date: Thu, 8 Aug 1996 21:44:40 -0400 (EDT) From: "Dorian R. Kim" Sender: dorian@cic.net Reply-To: "Dorian R. Kim" To: "Kent W. England" Cc: big-internet@munnari.OZ.AU Subject: Re: Comparing an old flow snapshot with some packet size data In-Reply-To: <2.2.32.19960806000836.00d194b8@mail.cts.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Darren Kerr of Cisco pointed out the fact that flows are not bi-directional, i.e. a TCP session is two flows, and that meaningful FTP data is FTPD, which stand for FTP Data, so it throws off some of the hypotheses discussed here. Some more itsy bitsy data until I have real stuff to play with: This is from a customer aggregation box. dgd#sh ip ca flow IP packet size distribution (3992M total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .005 .489 .058 .016 .013 .008 .009 .012 .011 .015 .004 .005 .002 .002 .002 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .005 .003 .142 .000 .114 .075 .000 .000 .000 .000 .000 IP Flow Switching Cache, 10539 active, 54997 inactive, 257164236 added 0 flows exported, 0 not exported, 0 export msgs sent 3 cur max hash, 257 worst max hash, 11801 valid buckets 0 flow alloc failures statistics cleared 1423044 seconds ago Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec) -------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow TCP-Telnet 1566034 1.1 129 70 142.2 115.3 44.4 TCP-FTP 5836648 4.1 6 91 26.3 12.4 45.7 TCP-FTPD 3560889 2.5 86 464 216.5 49.2 45.7 TCP-WWW 139280025 97.8 11 319 1137.3 8.2 45.9 TCP-SMTP 22840124 16.0 10 160 166.6 9.8 45.9 TCP-X 58694 0.0 127 176 5.2 106.0 44.3 TCP-BGP 1339769 0.9 2 50 2.6 9.2 44.5 TCP-Frag 123389 0.0 9 306 0.7 17.6 45.3 TCP-other 20351999 14.3 70 354 1008.7 61.2 45.2 UDP-DNS 39827050 27.9 3 103 96.7 6.7 45.8 UDP-NTP 5321916 3.7 2 76 7.6 0.8 45.9 UDP-TFTP 106 0.0 4 94 0.0 22.2 44.2 UDP-Frag 1829 0.0 59 296 0.0 69.3 45.1 UDP-other 7809191 5.4 19 142 108.4 27.6 45.3 ICMP 9140968 6.4 3 154 24.5 7.7 45.8 IGMP 39621 0.0 37 422 1.0 44.5 44.9 IPINIP 44911 0.0 626 282 19.7 104.2 43.7 GRE 12545 0.0 2233 272 19.6 208.4 42.6 IP-other 587 0.0 34 525 0.0 18.2 46.2 Total: 257156295 180.7 16 302 2984.5 14.1 45.8 -dorian From owner-Big-Internet@munnari.OZ.AU Fri Aug 9 15:57:18 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id FA06834; Fri, 9 Aug 1996 15:57:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA14047; Fri, 9 Aug 1996 15:55:35 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA14019; Fri, 9 Aug 1996 15:39:55 +1000 Received: from uucp13.netcom.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id FA15785; Fri, 9 Aug 1996 15:39:45 +1000 (from vjs@calcite.rhyolite.com) Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id WAA03237; Thu, 8 Aug 1996 22:10:27 -0700 Received: (from vjs@localhost) by calcite.rhyolite.com (8.7.3/8.7.3) id WAA29105 for Big-Internet@munnari.OZ.AU; Thu, 8 Aug 1996 22:35:35 -0600 (MDT) Date: Thu, 8 Aug 1996 22:35:35 -0600 (MDT) From: Vernon Schryver Message-Id: <199608090435.WAA29105@calcite.rhyolite.com> To: Big-Internet@munnari.OZ.AU Subject: FDDI MTU Precedence: bulk > Well, 4470 is the common FDDI and HSSI MTU, and so that's a pretty common > one for high-speed links... See RFC 1390 and its predecessors to discover that the IP MTU for FDDI has been 4352 for a long time. I can't guess the source of 4470, since the maximum total frame FDDI size is about 4500 bytes. ("about" because of the indicators after the FCS). > box" solutions. Reports from the field are that a "100Mbps" network > on which a PCI Pentium is sourcing or sinking traffic can not really expect > to see more than about 50Mbps due to the packet processing overhead in > this environment with a 1500 byte MTU -- but that number rises to nearly > 85Mbps with a 4470 MTU. That is not consistent with the 80 Mbit/sec netperf number (http://www.cup.hp.com/netperf/NetperfPage.html) for 100BASE-T for a "Noname Pentium 1". (Of course, 100BASE-T uses an MTU of 1500.) Vernon Schryver vjs@rhyolite.com From owner-Big-Internet@munnari.OZ.AU Fri Aug 9 18:56:23 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id IA08021; Fri, 9 Aug 1996 18:56:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA14216; Fri, 9 Aug 1996 18:55:42 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA14199; Fri, 9 Aug 1996 18:42:04 +1000 Received: from dxmint.cern.ch by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id IA11499; Fri, 9 Aug 1996 18:42:02 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id KAA09065; Fri, 9 Aug 1996 10:41:20 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA04143; Fri, 9 Aug 1996 10:40:48 +0200 Message-Id: <9608090840.AA04143@dxcoms.cern.ch> Subject: Re: Comparing an old flow snapshot with some packet size data To: asp@partan.com (Andrew Partan) Date: Fri, 9 Aug 1996 10:40:48 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: pferguso@Cisco.COM, jhawk@bbnplanet.com, kwe@6sigmanets.com, big-internet@munnari.OZ.AU In-Reply-To: <199608081958.PAA01711@home.partan.com> from "Andrew Partan" at Aug 8, 96 03:58:00 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk Andrew, > One question that I have been trying to figure out is > What size MTU should an ISP support on its backbone? > "Therefore, the default IP MTU for use with ATM AAL5 shall be 9180 octets. All implementations compliant and conformant with this specification shall support at least the default IP MTU value for use over ATM AAL5." - RFC 1626 It seems "obvious" that the ISPs should if possible support at least the largest default MTU likely to be found on user sites... but... (1) it is largely irrelevant until we get rid of http 1.0 (2) Van has good arguments why larger MTUs may be a clear loser on multi-hop TCP paths (3) since MTU discovery is still not by any means universal, there is a strong risk of inducing fragmentation at Internet exchanges. Can you imagine the impact of going through the Ethernet part of MAE East with 4k or 9k packets? So I'd hazard a guess that it is not time to think of going above 1500. Brian Carpenter From owner-Big-Internet@munnari.OZ.AU Sat Aug 10 14:22:31 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id EA02410; Sat, 10 Aug 1996 14:22:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA15313; Sat, 10 Aug 1996 14:20:30 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA15293; Sat, 10 Aug 1996 14:03:32 +1000 Received: from [202.146.255.3] by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id EA14284; Sat, 10 Aug 1996 14:03:19 +1000 (from bizan@centrin.net.id) Received: from [202.146.255.206] by jupiter.centrin.net.id; (5.65v3.2/1.1.8.2/11Jul96-0523PM) id AA16112; Sat, 10 Aug 1996 10:57:30 GMT Date: Sat, 10 Aug 1996 10:57:30 GMT Message-Id: <9608101057.AA16112@jupiter.centrin.net.id> X-Sender: bizan@centrin.net.id (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: sgi-mail@rz.tu-ilmenau.de From: Zaki Alex Subject: I wanna be your member... Cc: maillist@pia.com, al@internetMCI.com, djgpp@delorie.com, djgpp@sun.soe.clarkson.edu, amiga@molle3.mollehem.se, big-internet@munnari.OZ.AU, meta-fw-list@tc.cornell.edu, f-costume-request@lunch.asd.sgi.com, wrdmk03@harrier.sasknet.sk.ca, Frank.derop@ping.be Precedence: bulk Hello.... >My name is Alex.I'm Indonesian, live in Jakarta.I'm college students, study electronic at TRISAKTI University. I want to be your penfriends, if you want so...please mail me to : (cyberza@hotmail.com) >BETTER NOT MAIL TO (bizan@centrin.net.id), because that's my corporate mailbox. >I'll be waiting you my friends.... > From owner-Big-Internet@munnari.OZ.AU Sat Aug 10 14:41:29 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id EA28470; Sat, 10 Aug 1996 14:41:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA15371; Sat, 10 Aug 1996 14:40:12 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA15323; Sat, 10 Aug 1996 14:23:29 +1000 Received: from home.partan.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id EA15448; Sat, 10 Aug 1996 14:23:27 +1000 (from asp@partan.com) Received: (from asp@localhost) by home.partan.com (8.6.12/8.6.12) id AAA11136; Sat, 10 Aug 1996 00:23:19 -0400 From: Andrew Partan Message-Id: <199608100423.AAA11136@home.partan.com> Subject: Re: Comparing an old flow snapshot with some packet size data To: kwe@6SigmaNets.com (Kent W. England) Date: Sat, 10 Aug 1996 00:23:19 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <2.2.32.19960809003355.00703fe4@mail.cts.com> from "Kent W. England" at Aug 8, 96 05:33:55 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 394 Precedence: bulk > Is there any performance reason, such as buffer memory, that is > constrained to the point where a 10k MTU couldn't be supported? The router folks can probably speak better to this than I can, but with a limited amout of memory in the routers, you probably want a larger number of smaller buffers than a fewer number of larger buffers - thus a smaller MTU. --asp@partan.com (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Sat Aug 10 14:44:14 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id EA22551; Sat, 10 Aug 1996 14:44:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA15407; Sat, 10 Aug 1996 14:43:05 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA15315; Sat, 10 Aug 1996 14:21:04 +1000 Received: from home.partan.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id EA06646; Sat, 10 Aug 1996 14:20:57 +1000 (from asp@partan.com) Received: (from asp@localhost) by home.partan.com (8.6.12/8.6.12) id AAA11116; Sat, 10 Aug 1996 00:20:47 -0400 From: Andrew Partan Message-Id: <199608100420.AAA11116@home.partan.com> Subject: Re: Comparing an old flow snapshot with some packet size data To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Sat, 10 Aug 1996 00:20:47 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9608090840.AA04143@dxcoms.cern.ch> from "Brian Carpenter CERN-CN" at Aug 9, 96 10:40:48 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 680 Precedence: bulk > So I'd hazard a guess that it is not time to think of going > above 1500. Most large backbones today are probably already running at 4470 - with FDDI for the interexchanges and hub LANs, and T3/Hssi for their point-to-point links. The question is, if you were designing a backbone today, what would you use for your hub LANs? Fddi? Or 100baseT? 100baseT is probably going to be a lot cheaper (it looks like there is going to be a *lot* of it made), but its MTU is 1500. Can you get by with this? Or do you really need to invest in LANs that do 4470? Any high performance internet folks out there? What would you do (or want us to do)? --asp@partan.com (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Sat Aug 10 15:41:25 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id FA13137; Sat, 10 Aug 1996 15:41:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA15520; Sat, 10 Aug 1996 15:40:13 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA15503; Sat, 10 Aug 1996 15:31:08 +1000 Received: from nic.hq.cic.net by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id FA08465; Sat, 10 Aug 1996 15:31:03 +1000 (from dorian@cic.net) Received: from nic.hq.cic.net (nic.hq.cic.net [198.87.19.2]) by nic.hq.cic.net (8.7.5/CICNet) with SMTP id BAA24701; Sat, 10 Aug 1996 01:28:29 -0400 (EDT) Date: Sat, 10 Aug 1996 01:28:28 -0400 (EDT) From: "Dorian R. Kim" Sender: dorian@cic.net Reply-To: "Dorian R. Kim" To: Andrew Partan Cc: Brian Carpenter CERN-CN , big-internet@munnari.OZ.AU Subject: Re: Comparing an old flow snapshot with some packet size data In-Reply-To: <199608100420.AAA11116@home.partan.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 10 Aug 1996, Andrew Partan wrote: > The question is, if you were designing a backbone today, what would > you use for your hub LANs? Fddi? Or 100baseT? 100baseT is probably > going to be a lot cheaper (it looks like there is going to be a > *lot* of it made), but its MTU is 1500. Neither, I would think. Neither FDDI nor 100baseT is fast enough to be useful in interconnecting backbone routers. If it's a question of interconnecting customer aggregation boxes to backbone routers, I'd rather go with FDDI rather than 100baseT as FDDI degrades more gracefully under load. Given that full duplex FDDI is now a possibility, the only disadvantage of FDDI is cost. (well... there is more overhead to, but..) > Can you get by with this? Or do you really need to invest in LANs > that do 4470? I think that today is a particularly bad time to think about this issue in operational terms as point to point connection speeds have made all exisiting and widely deployed multi-access technologies inadequate, and next generation technologies that promises order of magnitude improvements are not here yet. Any solution arrived at, FDDI, switched FDDI, switched full duplex FDDI, 100baseT, switched 100baseT and ATM are all stop gap measures at best. > Any high performance internet folks out there? What would you do > (or want us to do)? I would think that the problem of just simply going faster and the problem of making massively aggregated flows flow through bigger pipes are not quite the same thing. Not that this is much of an answer. :) -dorian From owner-Big-Internet@munnari.OZ.AU Mon Aug 12 11:02:10 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id BA11420; Mon, 12 Aug 1996 11:02:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA17810; Mon, 12 Aug 1996 11:00:30 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA17790; Mon, 12 Aug 1996 10:49:41 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id AA21920; Mon, 12 Aug 1996 10:49:31 +1000 (from lekash@nas.nasa.gov) Received: from wilbur.nas.nasa.gov by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50) id AA26700; Mon, 12 Aug 1996 10:49:21 +1000 (from lekash@nas.nasa.gov) Received: (from lekash@localhost) by wilbur.nas.nasa.gov (8.6.12/NAS.6.1) id RAA23218; Sun, 11 Aug 1996 17:42:56 -0700 Date: Sun, 11 Aug 1996 17:42:56 -0700 From: lekash@nas.nasa.gov (John Lekashman) Message-Id: <199608120042.RAA23218@wilbur.nas.nasa.gov> To: asp@partan.com Cc: brian@dxcoms.cern.ch, dorian@cic.net, big-internet@munnari.OZ.AU In-Reply-To: <199608100420.AAA11116@home.partan.com> (message from Andrew Partan on Sat, 10 Aug 1996 00:20:47 -0400 (EDT)) Subject: Re: Comparing an old flow snapshot with some packet size data Precedence: bulk From: Andrew Partan Any high performance internet folks out there? What would you do (or want us to do)? What we do: We use HIPPI and FDDI switches, 100baseT, collapsed backbones inside routers and hubs, and whatever other tools we can find or fund the creation thereof, from all sorts of vendors. Then there's this small matter of engineering with the tools one has, for a given problem. What we want you to do: Engineer things well. Figure out what your target is, and build to it. That's a somewhat pithy and annoying answer, but its what you have to do. And its a lot of work to do well. From: "Dorian R. Kim" I would think that the problem of just simply going faster and the problem of making massively aggregated flows flow through bigger pipes are not quite the same thing. Yes, moving tons of small packets is different from moving tons of data. Different optimizations can occur, depending on your target. john remember. simple is really, really hard. lekash@nas.nasa.gov From owner-Big-Internet@munnari.OZ.AU Wed Aug 14 20:43:01 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id KA23832; Wed, 14 Aug 1996 20:43:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA20766; Wed, 14 Aug 1996 20:41:14 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA20749; Wed, 14 Aug 1996 20:34:13 +1000 From: Dorisn@cris.com Received: from franklin.cris.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id KA27144; Wed, 14 Aug 1996 20:34:07 +1000 (from Dorisn@cris.com) Received: from voyager.cris.com (voyager [199.3.12.37]) by franklin.cris.com (8.7.5/(96/06/11 2.45)) id GAA12405; Wed, 14 Aug 1996 06:33:50 -0400 (EDT) [1-800-745-2747 The Concentric Network] Errors-To: Dorisn@cris.com Received: by voyager.cris.com (4.1) id AA20239; Wed, 14 Aug 96 06:32:06 EDT Date: Wed, 14 Aug 96 06:32:06 EDT Message-Id: <9608141032.AA20239@voyager.cris.com> To: big-internet@munnari.OZ.AU Subject: Send FAX from your country to USA for US$0.075!! Precedence: bulk SEND FAX from your country to USA for US$0.075!!! Dear friends: We are very excited to tell you the CHEAPEST way to send fax to anywhere in the world. You can send faxes right from your desktop, from your email. You don't even need fax machine to send faxes. Just take a look of the international fax rates below, and you will know why we are so excited to share the news with you. No matter where you are at, the rates are the same. Sending faxes from your country to the following countries: ---------------------------------------------------- To Country Rates per minute ---------------------------------------------------- USA US$0.15 Canada US$0.28 United Kingdom US$0.33 Germany/France US$0.43 Australia US$0.51 Japan US$0.51 Columbia US$0.60 Hong Kong US$0.54 Taiwan US$0.55 ---------------------------------------------------- Remember that a typical one page will be sent in less than one minute. For example, if your one page fax to the USA goes through within 30 seconds, then you pay as low as US$0.075 for a one page fax to the USA! Better yet, you don't need a fax machine. You send the fax from your Internet email account. It is called "email-to-fax", and the service is offered by "ITSG, Inc." How to sign up? Simple. Just fill out the on-line Order Form. (http://www.itsg.com/cgi-bin/form?handler=ordform.frm) Interested in being an Agent too? Check out their web site. ---------------------------------------------------------------- You can check out their web site -- http://www.itsg.com (They also offer "fax-to-fax via Internet" service) For free infomation -- send a blank email to "info@itsg.com" ---------------------------------------------------------------- If you like to order, just fill out the order form. Please fill in "10015" in the "agent" field of the order form. Thank you. Regards, Doris Newman From owner-Big-Internet@munnari.OZ.AU Thu Aug 15 16:42:54 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id GA14411; Thu, 15 Aug 1996 16:42:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA21851; Thu, 15 Aug 1996 16:41:37 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA21823; Thu, 15 Aug 1996 16:24:27 +1000 Received: from linus.socs.uts.EDU.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id GA23817; Thu, 15 Aug 1996 16:24:06 +1000 (from atanu@kant.socs.uts.EDU.AU) Received: from kant.socs.uts.EDU.AU (kant [138.25.8.74]) by linus.socs.uts.EDU.AU (8.7.5/8.7.3) with ESMTP id QAA11808; Thu, 15 Aug 1996 16:22:20 +1000 (EST) Received: from kant (localhost [127.0.0.1]) by kant.socs.uts.EDU.AU (8.7.3/8.7.3) with ESMTP id QAA22332; Thu, 15 Aug 1996 16:20:54 +1000 (EST) To: big-internet@munnari.OZ.AU Cc: Dorisn@cris.com Subject: Re: Send FAX from your country to USA for US$0.075!! In-Reply-To: Your message of "Wed, 14 Aug 1996 06:32:06 EDT." <9608141032.AA20239@voyager.cris.com> Reply-To: atanu@socs.uts.edu.au X-Organisation: School of Computing Sciences, University of Technology, Sydney. X-Phone: +61 2 9514 2353 X-Fax: +61 2 9514 1807 X-Url: X-Face: "vo>pjO=2{5vAaQnJ+eIGQq4rz!lK{fOOkT!sIsS^dxv90L}WQk).kC_,5^0!RxK HM7b=#=g#WZ;HFt9Nw%bCuz[kzFEY{YpW_CaxKfuK1=SvTf)WkGK?,8_RFzfuIP$G o9]]O,F40]rw79Arl'gB+gw`LgGId-D5S[J#4bWG^5]/Z62.Ka(81i.XMiU+y:Nf bf-]pyNeP1!K?L~H7.x+NC|Zi0=#B2"EIsV:FBH7N@XOQBH[DkxFW#/"u@SV'd-T1 DnGQC[QhB,tYS From: Atanu Ghosh Precedence: bulk I don't usually respond to spams, but, I thought that some people may not be aware of the remote printing service experiment which has been running for some years. rfc1528 rfc1529 rfc1530 As far as I can tell the two many differences between the two services: 1) The remote printing service is free to most parts of the world (excluding, Internet connection costs of course). 2) The remote printing service does not accept faxes as input. The remote printing service is only email to fax. Atanu. >>>>> "Dorisn" == Dorisn writes: Dorisn> SEND FAX from your country to USA for US$0.075!!! Dorisn> Dear friends: Dorisn> We are very excited to tell you the CHEAPEST way to send fax to Dorisn> anywhere in the world. You can send faxes right from your desktop, from Dorisn> your email. You don't even need fax machine to send faxes. Dorisn> Just take a look of the international fax rates below, and you will Dorisn> know why we are so excited to share the news with you. Dorisn> No matter where you are at, the rates are the same. Dorisn> Sending faxes from your country to the following countries: Dorisn> ---------------------------------------------------- Dorisn> To Country Rates per minute Dorisn> ---------------------------------------------------- Dorisn> USA US$0.15 Dorisn> Canada US$0.28 Dorisn> United Kingdom US$0.33 Dorisn> Germany/France US$0.43 Dorisn> Australia US$0.51 Dorisn> Japan US$0.51 Dorisn> Columbia US$0.60 Dorisn> Hong Kong US$0.54 Dorisn> Taiwan US$0.55 Dorisn> ---------------------------------------------------- Dorisn> Remember that a typical one page will be sent in less than one Dorisn> minute. For example, if your one page fax to the USA goes through Dorisn> within 30 seconds, then you pay as low as US$0.075 for a one page Dorisn> fax to the USA! Dorisn> Better yet, you don't need a fax machine. You send the fax from your Dorisn> Internet email account. It is called "email-to-fax", and the service Dorisn> is offered by "ITSG, Inc." Dorisn> How to sign up? Simple. Just fill out the on-line Order Form. Dorisn> (http://www.itsg.com/cgi-bin/form?handler=ordform.frm) Dorisn> Interested in being an Agent too? Check out their web site. Dorisn> ---------------------------------------------------------------- Dorisn> You can check out their web site -- http://www.itsg.com Dorisn> (They also offer "fax-to-fax via Internet" service) Dorisn> For free infomation -- send a blank email to "info@itsg.com" Dorisn> ---------------------------------------------------------------- Dorisn> If you like to order, just fill out the order form. Please fill in Dorisn> "10015" in the "agent" field of the order form. Dorisn> Thank you. Dorisn> Regards, Dorisn> Doris Newman From owner-Big-Internet@munnari.OZ.AU Sat Aug 17 04:23:08 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id SA31371; Sat, 17 Aug 1996 04:23:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA23720; Sat, 17 Aug 1996 04:22:19 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA23709; Sat, 17 Aug 1996 04:14:54 +1000 Received: from pilot.is.chrysler.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id SA14088; Sat, 17 Aug 1996 04:14:51 +1000 (from rgm3@chrysler.com) Received: by pilot.firewall.is.chrysler.com; id OAA00735; Fri, 16 Aug 1996 14:14:42 -0400 Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilot.is.chrysler.com via smap (g3.0.1) id sma000725; Fri, 16 Aug 96 14:14:16 -0400 Received: from rgm3 ([172.16.252.1]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id OAA23854; Fri, 16 Aug 1996 14:06:46 -0400 (EDT) Message-Id: <2.2.32.19960816181148.00be4e04@pop3hub.is.chrysler.com> X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Aug 1996 14:11:48 -0400 To: Andrew Partan , brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) From: Robert Moskowitz Subject: Re: Comparing an old flow snapshot with some packet size data Cc: big-internet@munnari.OZ.AU Precedence: bulk At 12:20 AM 8/10/96 -0400, Andrew Partan wrote: > >The question is, if you were designing a backbone today, what would >you use for your hub LANs? Fddi? Or 100baseT? 100baseT is probably >going to be a lot cheaper (it looks like there is going to be a >*lot* of it made), but its MTU is 1500. > >Can you get by with this? Or do you really need to invest in LANs >that do 4470? I want to know, even with HTTP 1.1, what percent of traffic benefits from the larger MTU? And if you allow the larger MTU, what does it do to those elephants versus all of the little mice? Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Thu Aug 22 04:25:22 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id SA15949; Thu, 22 Aug 1996 04:25:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA29883; Thu, 22 Aug 1996 04:24:23 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA29877; Thu, 22 Aug 1996 04:23:20 +1000 Received: from burnout.cts.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id SA09305; Thu, 22 Aug 1996 04:23:17 +1000 (from kwe@6SigmaNets.com) Received: from netguru.cts.com (ppp-206-170-122-217.sndg02.pacbell.net [206.170.122.217]) by burnout.cts.com (8.6.12/8.6.9) with SMTP id LAA15767; Wed, 21 Aug 1996 11:22:39 -0700 Message-Id: <2.2.32.19960821182334.00740718@mail.cts.com> X-Sender: kwe@mail.cts.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Aug 1996 11:23:34 -0700 To: Robert Moskowitz , Andrew Partan , brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) From: "Kent W. England" Subject: Re: Comparing an old flow snapshot with some packet size data Cc: big-internet@munnari.OZ.AU Precedence: bulk At 02:11 PM 8/16/96 -0400, Robert Moskowitz wrote: >I want to know, even with HTTP 1.1, what percent of traffic benefits from >the larger MTU? And if you allow the larger MTU, what does it do to those >elephants versus all of the little mice? > > >Robert Moskowitz >Chrysler Corporation >(810) 758-8212 > > > It seems there is some confusion about what clients should set the MTU to be (no more than what can be expected to work without fragmentation) versus what maximum MTU a backbone should support (the largest possible allowing for buffer memory efficiency). These are quite different. If a client sets too large an MTU, then it suffers fragmentation. If a backbone sets the MTU too large, then all that happens is some buffer memory might be wasted. No client applications are affected by a too large MTU on the backbone. (Technically, a backbone doesn't have an MTU except for traffic originated by the routers. What we are really talking about is "maximum packet size configured into the routers" and "host MTU", respectively.) What seems obvious to me is that 1500 bytes is a safe bet for an MTU today. By this I mean that a host can set the MTU to 1500 bytes and it will usually work off local subnet. Backbones must support at least 1500 bytes and should support up to 9180. The only difference is how the routers use memory for buffering. If each packet is allocated the router's MTU, then there is a lot of wasted buffer memory between 500 bytes typical and 9180. If a router vendor has a problem with that much memory wastage, then I'd say it was up to them to allocate, say, 1500 bytes per packet, and handle an exception for anything beyond that MTU. So let's see to it that the backbones can handle anything up to ATM 9180 and try to get hosts to use path MTU discovery or their interface MTU of at least 1500. --Kent From owner-Big-Internet@munnari.OZ.AU Thu Aug 22 05:04:30 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA00799; Thu, 22 Aug 1996 05:04:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA29948; Thu, 22 Aug 1996 05:04:20 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA29942; Thu, 22 Aug 1996 05:02:38 +1000 Received: from shark.mel.dit.CSIRO.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA02178; Thu, 22 Aug 1996 05:02:32 +1000 (from rgm3@chrysler.com) Received: from pilotx.firewall.is.chrysler.com (copilot.is.chrysler.com) by shark.mel.dit.csiro.au with SMTP id AA06737 (5.65c/IDA-1.4.4/DIT-1.3 for ); Thu, 22 Aug 1996 05:02:30 +1000 Received: by pilotx.firewall.is.chrysler.com; id OAA11801; Wed, 21 Aug 1996 14:52:00 -0400 Received: from mhbclpr2-le0.is.chrysler.com(172.29.128.206) by pilotx.is.chrysler.com via smap (g3.0.1) id sma011795; Wed, 21 Aug 96 14:51:42 -0400 Received: from rgm3 ([172.16.252.34]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id OAA02450; Wed, 21 Aug 1996 14:44:02 -0400 (EDT) Message-Id: <2.2.32.19960821185120.00c7ea1c@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Aug 1996 14:51:20 -0400 To: "Kent W. England" , Robert Moskowitz , Andrew Partan , brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) From: Robert Moskowitz Subject: Re: Comparing an old flow snapshot with some packet size data Cc: big-internet@munnari.OZ.AU Precedence: bulk At 11:23 AM 8/21/96 -0700, Kent W. England wrote: > >Backbones must support at least 1500 bytes and should support up to 9180. >The only difference is how the routers use memory for buffering. If each >packet is allocated the router's MTU, then there is a lot of wasted buffer >memory between 500 bytes typical and 9180. If a router vendor has a problem >with that much memory wastage, then I'd say it was up to them to allocate, >say, 1500 bytes per packet, and handle an exception for anything beyond that >MTU. If it does it wrong, it negatively impacts on congestion (buffer full). >So let's see to it that the backbones can handle anything up to ATM 9180 and >try to get hosts to use path MTU discovery or their interface MTU of at >least 1500. Thanks Kent. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Thu Aug 22 07:04:38 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id VA29135; Thu, 22 Aug 1996 07:04:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA00175; Thu, 22 Aug 1996 07:04:22 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA00158; Thu, 22 Aug 1996 06:52:10 +1000 Received: from poblano.near.net by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id UA30814; Thu, 22 Aug 1996 06:52:05 +1000 (from jhawk@bbnplanet.com) Subject: Re: Comparing an old flow snapshot with some packet size data To: "Kent W. England" Date: Wed, 21 Aug 1996 16:50:14 -0400 (EDT) From: John Hawkinson Cc: asp@partan.com, big-internet@munnari.OZ.AU In-Reply-To: <2.2.32.19960821182334.00740718@mail.cts.com> from "Kent W. England" at Aug 21, 96 11:23:34 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2149 Message-Id: <9608211651.aa03245@poblano.bbnplanet.com> Precedence: bulk > Backbones must support at least 1500 bytes and should support up to 9180. > The only difference is how the routers use memory for buffering. If each > packet is allocated the router's MTU, then there is a lot of wasted buffer > memory between 500 bytes typical and 9180. If a router vendor has a problem > with that much memory wastage, then I'd say it was up to them to allocate, > say, 1500 bytes per packet, and handle an exception for anything beyond that > MTU. Kent, I think you're slightly confused. Part of this is what defines "the mtu a backbone can support". There are two ways (at least!) to look at that: 1. The minimum MTU of all the interfaces in the backbone. 2. Various buffering considerations on all of the equipment involved in the backbone. Without the former, the latter seems kind of irrelevent, since path MTU discovery will never let you go above that minimum (and rightly so). If you say that "backbones should support up to 9180" then you've just disallowed most folks' DS3 interfaces and FDDI, and are mandating that folks should all go and use ATM. I think you're well aware there are a strong contingent of people who will not throw out their DS3 and FDDI infrastructure for ATM :-) I think the brunt of asp's question was really "Is it acceptable for a backbone service provider to provide a min mtu of 1500 instead of a min mtu of of 4352". What this really translates into is: Is it OK for a backbone service provider to use fast ethernet as a interconnect medium instead of FDDI. Answers seem varied, some folks may have contractual obligations to provide that 4k MTU, but most don't. Is that 4k MTU worth the trade-offs? It's certainly the case that the 1.5k MTU isn't very-well exploited right now, and it's difficult to see the 4k MTU being exploited well in the short term, though it may be that end-users who check the "4k MTU requirement" checkbox are actually folks who have lots of hosts with 4k MTUs on their interfaces who exchange significant amounts of traffic with others who have similarly-configured hosts and who implement path MTU discovery and "all that good stuff". --jhawk From owner-Big-Internet@munnari.OZ.AU Thu Aug 22 10:46:29 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id AA08333; Thu, 22 Aug 1996 10:46:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA00381; Thu, 22 Aug 1996 10:44:27 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA00364; Thu, 22 Aug 1996 10:32:10 +1000 Received: from nic.hq.cic.net by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id AA29530; Thu, 22 Aug 1996 10:30:44 +1000 (from dorian@cic.net) Received: from nic.hq.cic.net (nic.hq.cic.net [198.87.19.2]) by nic.hq.cic.net (8.7.5/CICNet) with SMTP id UAA24953; Wed, 21 Aug 1996 20:29:36 -0400 (EDT) Date: Wed, 21 Aug 1996 20:29:36 -0400 (EDT) From: "Dorian R. Kim" Sender: dorian@cic.net To: John Hawkinson Cc: "Kent W. England" , asp@partan.com, big-internet@munnari.OZ.AU Subject: Re: Comparing an old flow snapshot with some packet size data In-Reply-To: <9608211651.aa03245@poblano.bbnplanet.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Wed, 21 Aug 1996, John Hawkinson wrote: > If you say that "backbones should support up to 9180" then you've just > disallowed most folks' DS3 interfaces and FDDI, and are mandating that > folks should all go and use ATM. I think you're well aware there are a > strong contingent of people who will not throw out their DS3 and FDDI > infrastructure for ATM :-) Along with problematic buffering problems with certain vendor equipment for 9180 MTU. > I think the brunt of asp's question was really "Is it acceptable for > a backbone service provider to provide a min mtu of 1500 instead of > a min mtu of of 4352". What this really translates into is: > > Is it OK for a backbone service provider to use fast ethernet > as a interconnect medium instead of FDDI. > > Answers seem varied, some folks may have contractual obligations to > provide that 4k MTU, but most don't. > > Is that 4k MTU worth the trade-offs? It's certainly the case that the > 1.5k MTU isn't very-well exploited right now, and it's difficult to > see the 4k MTU being exploited well in the short term, though it > may be that end-users who check the "4k MTU requirement" checkbox > are actually folks who have lots of hosts with 4k MTUs on their > interfaces who exchange significant amounts of traffic with others > who have similarly-configured hosts and who implement path MTU > discovery and "all that good stuff". It seemed to me intuitively that anything above 1500 MTU doesn't buy one much, so I went to my routers and checked, just to be sure. dgb>sh ip ca flow IP packet size distribution (6502M total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .002 .513 .048 .017 .025 .007 .007 .010 .014 .014 .004 .005 .005 .002 .002 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .006 .006 .174 .000 .076 .052 .000 .000 .000 .000 .000 IP packet size distribution (6283M total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .002 .515 .049 .016 .024 .007 .007 .016 .011 .013 .007 .006 .007 .002 .002 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .005 .006 .160 .000 .081 .053 .000 .000 .000 .000 .000 dgd>sh ip ca flow IP packet size distribution (1182M total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .001 .480 .062 .015 .011 .008 .007 .012 .011 .014 .004 .009 .007 .003 .002 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .005 .004 .136 .000 .125 .074 .000 .000 .000 .000 .000 So unless my routers aren't telling the truth, there are significant amount of > 1500 byte packets floating in my network. I'm somewhat mystified as to where 2048 comes from, but they are there nonetheless, and in our application, it seems to me that 4K MTU is a good thing. -dorian From owner-Big-Internet@munnari.OZ.AU Wed Aug 28 19:47:25 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id JA06552; Wed, 28 Aug 1996 19:47:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA08103; Wed, 28 Aug 1996 19:46:10 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA08086; Wed, 28 Aug 1996 19:27:09 +1000 Received: from ksc8.th.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id JA20643; Wed, 28 Aug 1996 19:27:00 +1000 (from johned@ksc8.th.com) Received: by ksc8.th.com (5.x/SMI-SVR4) id AA28372; Wed, 28 Aug 1996 16:22:20 +0700 Date: Wed, 28 Aug 1996 16:22:20 +0700 (TST) From: MNI Subject: MET-NET INTERNATIONAL Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Apparently-To: Precedence: bulk ********************************************************************* ***** ***** ***** MET-NET INTERNATIONAL ***** ***** ***** ***** The FREE daily E-Mail publication for world-wide ***** ***** metal traders, producers and buyers ***** ***** ***** ********************************************************************* Scotneys Croft, Toppesfield Road, Great Yeldham, Essex CO9 4HG, UK. Fax:(44) 1787 238100 Tel:(44) 1787 238085 Email: metnet@netbox.com *********************************************************** This is your invitation to subscribe to the world's FIRST electronic metal trading publication, FREE OF CHARGE *********************************************************** The MET-NET is the FREE daily E-mail publication for professional suppliers and buyers of STAINLESS, ALLOY and CARBON STEELS, ALUMINIUM, NON FERROUS & SPECIALITY METALS. You can place all YOUR metal buying enquiries and sales offers in the MET-NET and also continuously receive the MET-NET by E-Mail, free of charge. Every day, the MET-NET is updated with specific details of ALL the semi-finished metals that our readers want to buy and sell. It is then sent FREE OF CHARGE by E-Mail & Fax to our rapidly growing subscription list of over 550 leading world-wide metal traders and producers. If you have received similar offers from our imitators please note that the MET-NET was the FIRST specialised metal trading publication on the Internet. We have the largest as well as the fastest growing readership base. The MET-NET is produced and managed by experienced international metal brokers with principal offices in the UK and South East Asia, and representative offices around the world. Placing Buying Enquiries in the MET-NET --------------------------------------- You can E-Mail your detailed buying enquiries direct to the MET-NET, straightaway. Please always remember to state full metal specifications, sizes and quantities required. Your enquiry will be entered in the MET-NET which is then transmitted to all our other readers. Once suitable offers have been received against your enquiry full details will then be sent to you. MET-MET traders will remain at your disposal to help with continued negotiations with your suppliers. There is NO CHARGE for this service. MET-NET will earn a small commission from the eventual seller once a deal has been successfully concluded. Placing Sales Offers in the MET-NET ----------------------------------- When you subscribe to the Met-Met, we will explain how you can also advertise your mill options, excess stock or other special offers in the MET-NET - again free of charge. Receiving the MET-NET --------------------- To start receiving the MET-NET simply complete the registration form below and then E-Mail it back to us. __________________________________________________________________ NET-NET REGISTRATION FORM __________________________________________________________________ [] YES! We wish to advertise in the MET-NET, free of charge. [] YES! Send us the MET-NET, free of charge. Your Name: Business Name: Email #: Fax #: Return this form to: METNET@NETBOX.COM -or- JOHNED@KSC8.TH.COM __________________________________________________________________ PLEASE DO NOT MISS OUT ON YOUR CHANCE TO SHARE WITH AND CONTRIBUTE TOWARDS THIS INNOVATIVE FREE SERVICE. SUBSCRIBE TODAY. __________________________________________________________________ From owner-Big-Internet@munnari.OZ.AU Fri Aug 30 16:09:04 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id GA26554; Fri, 30 Aug 1996 16:09:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA10417; Fri, 30 Aug 1996 16:06:56 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA10411; Fri, 30 Aug 1996 16:03:35 +1000 Received: from fh101.infi.net by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id GA26020; Fri, 30 Aug 1996 16:03:32 +1000 (from anguskit@lancnews.infi.net) Received: from pa1dsp19.lns.infi.net by mh101.infi.net with SMTP (Infinet-S-3.3) id CAA07960; Fri, 30 Aug 1996 02:02:47 -0400 (EDT) Message-Id: <3226A08A.A0E@lancnews.infi.net> Date: Fri, 30 Aug 1996 01:04:26 -0700 From: jacqueline sheeran Organization: InfiNet X-Mailer: Mozilla 2.02 (Win16; U) Mime-Version: 1.0 To: big-internet@munnari.OZ.AU Subject: need e-mail address X-Url: http://guide-p.infoseek.com//Titles?qt=internet+mail&col=EM&sv=N2&lk=noframes&x=36&y=10 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk I'm looking for the e-mail address of Keith Maurer out of Yorktown, VA. Could you please direct me as to how to send email to a person on another server. anguskit@lancnews.infi.net Thanks From owner-Big-Internet@munnari.OZ.AU Sat Aug 31 15:28:35 1996 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id FA31858; Sat, 31 Aug 1996 15:28:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA11628; Sat, 31 Aug 1996 15:27:24 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA11611; Sat, 31 Aug 1996 15:22:23 +1000 Received: from x9.boston.juno.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id FA14946; Sat, 31 Aug 1996 15:22:18 +1000 (from ed.catspaw@juno.com) Received: (from ed.catspaw@juno.com) by x9.boston.juno.com (queuemail) id BGY18768; Sat, 31 Aug 1996 01:13:07 EDT To: big-internet@munnari.OZ.AU Subject: Upgrading? Message-Id: <19960830.220142.4214.180.ed.catspaw@juno.com> X-Mailer: Juno 1.15 X-Juno-Line-Breaks: 0-45 From: ed.catspaw@juno.com (edward R lemus) Date: Sat, 31 Aug 1996 01:13:07 EDT Precedence: bulk Buy direct-save, do-it-yourself upgrades Hardware*Memory*Complete Systems IBM*Macintosh ******************************* Some Low Price Configurations: 5x86/133 AMD CPU 256K Cache 16MB Ram Memory 1.33 GB Hard Drive 1.44 Floppy Drive 1MB PCI SVGA Video Card 14" SVGA Monitor 4x CD-ROM 28.8 Hayes Modem 104 Win95 Keyboard (has a nice touch to it) 3 Button Mouse (very useful for windows applications) This system goes for $1184 System Upgrade Special (no Monitor) 5x86/133 AMD CPU 256K Cache 8MB Memory 850MB Hard Drive 1.44 Floppy 1MB PCI SVGA Card Mini Tower Case 104 Key Win95 Keyboard 3 Button Mouse The price for this system is $600 Both of these systems use AMI BIOS Prices of these systems may vary depending on the availability- Prices good for 8/96 Feel free to e-mail me for other custom configurations. Cat's Paw Computers Email- ed.catspaw@juno.com (If you do not wish any further e-mail sent to this address just send me a quick note back- thanks)