- Test - lists.nanog.org

Re: audio/video again
by Paul Ferguson 08 Aug '96

08 Aug '96

At 08:15 PM 8/5/96 -0700, Michael Dillon wrote: > >How would you feel if Pointcast slowly backed off and increased the time >period between updates, but at the touch of a key or movement of the mouse >it would go back to the "knob" setting? Obviously a low volume data feed >like Pointcast may not be that big a load on the net but the heuristics >(which do involve human factors) could probably be applied to a lot of >other things like video feeds that will be bigger bandwidth consumers. > I think this sounds fine, but I don't think you need an RFC to dictate it. This would be a competitive advantage for an application, methinks. - paul

6 6

None
by Paul Ferguson 08 Aug '96

08 Aug '96

Has anyone heard of this before or provide more detailed pointers? - paul [snip] HERNDON, Va.--(BUSINESS WIRE) via Individual Inc. -- Network Solutions Inc., recognized globally as the manager of Internet Protocol (IP) addresses and domain names on the Internet, and Quadritek Systems Inc. today announced a partnership to provide automated and concise management of enterprise IP address space. This alliance will integrate Network Solutions' TCP/IP skills, technology and proven processes and Quadritek's unique software tools into a seamless offering. Central to this offering is the Quadritek Internet Protocol Management System (QIP) with its unique capabilities and graphical interface. Corporations will be able to reengineer the addressing of Intranets rapidly, with less effort and virtually no human error. They will be able to raise their networks to the standards required for Internet access, and maintain them at low cost through the inevitable configuration changes. [snip]

2 1

Re: Network Solutions Inc. (NSI) and Quadritek Systems Inc. partnership announced
by Mark T. Regan 08 Aug '96

08 Aug '96

On Thu, 08 Aug 1996 08:06:26 -0400, Paul Ferguson wrote: >Has anyone heard of this before or provide more detailed pointers? > >- paul > >[snip] > >HERNDON, Va.--(BUSINESS WIRE) via Individual Inc. -- Network Solutions >Inc., recognized globally as the manager of Internet Protocol (IP) >addresses and domain names on the Internet, and Quadritek Systems Inc. >today announced a partnership to provide automated and concise >management of enterprise IP address space. > [snip] I haven't heard about it, but I'm in the process of starting to evaluate QIP, once I get it loaded on a Sparc here. Anyone have any comments (good or bad) on the Quadritek products? Thanks. ----- Mark T. Regan <reganm(a)nationwide.com> Nationwide Insurance Enterprise Network Software Specialist One Nationwide Plaza, M.S. 3-9-4 EIPS-Telecommunications Dept. Columbus, OH 43215-2220 Voice: (614) 249-5390 Fax: (614) 249-5890 <http://www.nationwide.com>

1 0

Re: Quadritek & Network Solutions
by Mark Borchers 08 Aug '96

08 Aug '96

The documentation with release 2.2 states that classless addressing is fully supported. I believe they've recently rolled out version 3.0. Again, I stress that I haven't installed the software yet - mainly because I'm going to have to make it work with Revision Control System, as all my domains are RCS-controlled. > > Last time I looked at this package, it was classful and not CIDR such > that any ip allocation made with say a Class C block must all have the > same subnet mask. > > If this has changed, please let me know as it looked like a reasonable > package otherwise. > > - Mark > > -- > Spoken: Mark A. Schleifer, Manager, Router I&M > Domain: marks(a)digex.net Phone: +1-301-847-5099 > USPS: DIGEX, 6800 Virginia Manor Rd, Beltsville MD 20705-4212 > > Mark Borchers InfiNet Network Engineering NOC: (757) 624-2295 ext. 3007

1 0

Re: Quadritek & Network Solutions
by Mark Borchers 08 Aug '96

08 Aug '96

I have the software sitting on a shelf. The documentation looks pretty good and I'll probably start using it soon. They are on the WWW at www.qtek.com. > Has anyone heard of this before or provide more detailed pointers? > > - paul > > HERNDON, Va.--(BUSINESS WIRE) via Individual Inc. -- Network Solutions > Inc., recognized globally as the manager of Internet Protocol (IP) > addresses and domain names on the Internet, and Quadritek Systems Inc. > today announced a partnership to provide automated and concise > management of enterprise IP address space. > > This alliance will integrate Network Solutions' TCP/IP skills, technology > and proven processes and Quadritek's unique software tools into a seamless > offering. Central to this offering is the Quadritek Internet Protocol > Management System (QIP) with its unique capabilities and graphical > interface. Mark Borchers InfiNet Network Engineering NOC: (757) 624-2295 ext. 3007

1 0

RE: Comparing an old flow snapshot with some packet size data
by Barry Raveendran Greene 08 Aug '96

08 Aug '96

>Caches are a big win too. If more clickers pointed HTTP proxy >somewhere we'd be a lot better off. Persistent connections between >cahces is the only thing that makes any sense at all. And we're about to see just how far proxy/caches will scale. On Sept 15, everyone in Singapore will be routed through proxy/caches. That's about 60K customers though SingNet/STIX caches (see http://www.singnet.com.sg/cache) Barry

1 0

Comparing an old flow snapshot with some packet size data
by Kent W. England 08 Aug '96

08 Aug '96

NANOG Folks; [Cross posted to big-internet list in a separate message.] I'm hoping to get some comment and perhaps some more cisco flow stats or sniffer stats from participants on this list on the state of flows on the WAN Internet. I did a little traffic comparison to see what I could glean from comparing Sean Doran's flow stats posted last January to big-internet 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 the big-internet 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 anyone has been collecting more data. 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, [Robert Elz points out I'm looking at the FTP control channel. duh.] but the WWW bytes/pkt of 247 [and the FTPD bytes/pkt of 345] are 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? Would path MTU discovery help or could we all just informally set the Internet default MTU up to 1500 bytes [as John Hawkinson suggested on big-internet] and suffer a few fragmented slow speed links. Are most PPP MTUs set at the default 1500 or no? --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.)

3 2

Re: Comparing an old flow snapshot with some packet size data
by Daniel W. McRobb 08 Aug '96

08 Aug '96

> > In message <199608072217.AA02662(a)interlock.ans.net>, "Daniel W. McRobb" writes: > > > > > > Persistant connections is a prominant feature of HTTP 1.1, now in > > > draft. Maybe someone who follows that WG can comment on its progress. > > > If on average there are 2-3 inline images per page (reasonable > > > estimate IMO, though I have no data to back this up), then the average > > > transfer size will increase. I've heard (verbal at NANOG) that > > > Netscape has promised to support persistant connections, with the only > > > caveat that they will open one connection for the page itself and > > > another for all the inlines so they can start rendering the first > > > inline while a long page is being read. They can probably avoid this > > > for short pages. This could lead to a significant improvement in the > > > ability of the Internet traffic to respond to low levels of packet > > > drop and make good use of TCP congestion control, plus it will > > > significantly improve the speed of transfer on uncongested paths where > > > currently TCP never gets out of the initial slow start. > > > > > > Curtis > > > > I did some analysis of the FIX-West traces a while back and posted it to > > the nlanr mailing list. It's been so long that I don't remember what I > > posted, but I seem to recall trying to make a judgement as to how many > > packets we'd eliminate with a mass migration to HTTP 1.1 and/or HTTP > > with T/TCP. I recall a figure around 14%, but that's just from memory. > > It is not a question of eliminating packets it is a question of > whether TCP ever gets out of slow start and gets to a reasonable > window size. It takes 4 RTT to send 1+2+4+1 for 8 data segments, then > you need to go through FIN handshake and SYN. If you do three images > you start with a new window for each or try to do them all at one you > can have 3 * 8 segments you have 1+2+4+1 either in sequence or at the > same time or 1+2+4+8+9 if you have a persistent connection. If the > pipe is overfull it is much easier to TCP rate limit the latter case > so you need to drop much fewer packets to keep things under control. > > At 552, 8 segments is about 4K, which is about the average image size. > Of course it is one segment at FDDI MTU. Then it really pays to have > a persistant connection so you don't degrade to UDP characteristics. I'm not discounting the importance of letting TCP get out of slow start and to a reasonable window size. That's more important than the FIN/SYN traffic (for the network). I _think_ what I had done with the FIX-West traces was look at how many packets wouldn't be generated if HTTP used T/TCP (or persistent connections... I don't remember which I did). I did not try to account for what would happen due to a more reasonable window size (which should happen for many (most?) WWW pages w/ HTTP 1.1) and getting out of slow start. I only looked at how many of the packets were setup/teardown traffic that wouldn't exist if T/TCP was used or persistent connections. Of course, from what I've seen, there are some broken TCP implementations out there, some with bizarre, nonsensical initial window advertisements, some with overly-aggressive SYN retransmission, etc. :-( There also seem to be a decent number of clients with a low advertised MSS (256), probably due to being at the end of a SLIP or PPP connection with an MTU of 296. This of course begs the question: just how much of a difference will HTTP 1.1 make? I'm a tiny bit leery to answer that, since I keep seeing stats indicating broken TCP implementations. :-( I've even heard that some PC WWW browsers allow the user to set the MSS and initial window advertisement. I (for some reason) think it's unlikely that much of the point-click crowd understands the implications. :-( Daniel ~~~~~~

1 0

Re: Comparing an old flow snapshot with some packet size data
by Curtis Villamizar 08 Aug '96

08 Aug '96

In message <199608072217.AA02662(a)interlock.ans.net>, "Daniel W. McRobb" writes: > > > > Persistant connections is a prominant feature of HTTP 1.1, now in > > draft. Maybe someone who follows that WG can comment on its progress. > > If on average there are 2-3 inline images per page (reasonable > > estimate IMO, though I have no data to back this up), then the average > > transfer size will increase. I've heard (verbal at NANOG) that > > Netscape has promised to support persistant connections, with the only > > caveat that they will open one connection for the page itself and > > another for all the inlines so they can start rendering the first > > inline while a long page is being read. They can probably avoid this > > for short pages. This could lead to a significant improvement in the > > ability of the Internet traffic to respond to low levels of packet > > drop and make good use of TCP congestion control, plus it will > > significantly improve the speed of transfer on uncongested paths where > > currently TCP never gets out of the initial slow start. > > > > Curtis > > I did some analysis of the FIX-West traces a while back and posted it to > the nlanr mailing list. It's been so long that I don't remember what I > posted, but I seem to recall trying to make a judgement as to how many > packets we'd eliminate with a mass migration to HTTP 1.1 and/or HTTP > with T/TCP. I recall a figure around 14%, but that's just from memory. It is not a question of eliminating packets it is a question of whether TCP ever gets out of slow start and gets to a reasonable window size. It takes 4 RTT to send 1+2+4+1 for 8 data segments, then you need to go through FIN handshake and SYN. If you do three images you start with a new window for each or try to do them all at one you can have 3 * 8 segments you have 1+2+4+1 either in sequence or at the same time or 1+2+4+8+9 if you have a persistent connection. If the pipe is overfull it is much easier to TCP rate limit the latter case so you need to drop much fewer packets to keep things under control. At 552, 8 segments is about 4K, which is about the average image size. Of course it is one segment at FDDI MTU. Then it really pays to have a persistant connection so you don't degrade to UDP characteristics. > At any rate, in our case, a significant reduction in HTTP traffic (by > caches, HTTP 1.1, T/TCP, whatever) would be nice since HTTP represents a > large chunk of our backbone traffic. Caches are a big win too. If more clickers pointed HTTP proxy somewhere we'd be a lot better off. Persistent connections between cahces is the only thing that makes any sense at all. Curtis

1 0

Re: Comparing an old flow snapshot with some packet size data
by Daniel W. McRobb 07 Aug '96

07 Aug '96

> > In message <2.2.32.19960806173812.00711b8c(a)mail.cts.com>, "Kent W. England" wri > tes: > > NANOG Folks; > > > [ ... > > > > 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? Would path > > MTU discovery help or could we all just informally set the Internet default > > MTU up to 1500 bytes [as John Hawkinson suggested on big-internet] and > > suffer a few fragmented slow speed links. Are most PPP MTUs set at the > > default 1500 or no? > > > > --Kent > > > Hi there Kent, > > Persistant connections is a prominant feature of HTTP 1.1, now in > draft. Maybe someone who follows that WG can comment on its progress. > If on average there are 2-3 inline images per page (reasonable > estimate IMO, though I have no data to back this up), then the average > transfer size will increase. I've heard (verbal at NANOG) that > Netscape has promised to support persistant connections, with the only > caveat that they will open one connection for the page itself and > another for all the inlines so they can start rendering the first > inline while a long page is being read. They can probably avoid this > for short pages. This could lead to a significant improvement in the > ability of the Internet traffic to respond to low levels of packet > drop and make good use of TCP congestion control, plus it will > significantly improve the speed of transfer on uncongested paths where > currently TCP never gets out of the initial slow start. > > Curtis I did some analysis of the FIX-West traces a while back and posted it to the nlanr mailing list. It's been so long that I don't remember what I posted, but I seem to recall trying to make a judgement as to how many packets we'd eliminate with a mass migration to HTTP 1.1 and/or HTTP with T/TCP. I recall a figure around 14%, but that's just from memory. I just looked at the ARTS data for July 1996 for traffic we're receiving at the Sprint NAP, and the average packet size for WWW traffic was 231 bytes. Also, HTTP accounts for about 73% of the traffic we receive from peers at the Sprint NAP. I generated an incomplete plot of HTTP traffic growth (as a percentage of total packet traffic) for the ISMA workshop, and it's on the nlanr WWW site at the bottom of: http://www.nlanr.net/NA/Learn/daily.html I've been meaning to give a more recent plot to kc to place there, but haven't gotten around to it yet. The zero values for 05/95 and 08/95 are just due to me not having time to pull those months from tape. At any rate, in our case, a significant reduction in HTTP traffic (by caches, HTTP 1.1, T/TCP, whatever) would be nice since HTTP represents a large chunk of our backbone traffic. Daniel ~~~~~~

1 0