- NANOG - lists.nanog.org

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

Just how big a load are UDP broadcasts?
by Dick St.Peters 06 Aug '96

06 Aug '96

I run a small network of small sites, including a couple in the Adirondacks with 56k feeds. When a user of one of these sites uses one of the UDP audio or video services it drives the 56k to 100% saturation (load 255/255) and makes the site unusable for everyone else. Recently I "solved" this problem by blocking this traffic at the entry port for my T1 feed. To my surprise, both the average and peak traffic on the T1 dropped by a factor of 3, although less than 2% of my users complained. Traffic on my T1 wasn't the issue, but this has me wondering: how much of the Internet congestion my users do complain about is due to UDP audio/video services? In my very limited view of the world, UDP is a very poor network citizen among protocols. Am I wrong in that view? -- Dick St.Peters, Gatekeeper, Pearly Gateway, Ballston Spa, NY stpeters(a)NetHeaven.com Owner, NetHeaven 518-885-1295/800-910-6671 Internet for Albany/Saratoga, Glens Falls, North Creek, & Lake Placid First Internet service based in the 518 area code

8 13

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

06 Aug '96

At 05:53 PM 8/5/96 -0700, Michael Dillon wrote: > >Maybe we could get an RFC that requires screensaver type applications to >have a standalone mode that works with stored data and require user >overrides in order to initiate video or other data feeds. Maybe it could >also require that video and data feeds automatically shut down if there is >no user interaction within a specified time period. Kind of a higher level >view of the smae kind of timing specs that make TCP work. > Hey, don't mess with my Pointcast! ;-) Sorry to name specific products here (lots of folks specifically point out cisco, so what the hell), but in the specific case of Pointcast, there *is* a knob which controls the time-frame between updates. This is, in my opinion, the Right Thing to do. Once they get the compression stuff working and make it available, it will help lessen the impact of thousands of these clients clogging the network getting update data. In any event, I like getting my stock quotes if I'm away from my machine for a few hours. Sure, there are ways to make it more efficiently (such as geographically dispersed servers, compression, et al), but I don't believe this is an example of a misbehaving application. Perhaps an FYI RFC on application behavior is not such a Bad Thing, but it would certainly be a controversial document. - paul

2 1

Survey on Continuing Education for Network Computing Professionals
by feedback＠decisive.com 06 Aug '96

06 Aug '96

This survey is on behalf of an education center dedicated to the needs of network computing professionals. We are asking your input to help us create better education/training programs for you and your company. Your responses will be completely confidential. If we receive your completed survey by Monday, August 12, 1996, we'll automatically enter you in a contest for a prize of $1,000; one winner will be chosen from among those who complete the survey. Thank you in advance for your help. (Authentication marker -- ~3%e%INTCADX%8%1%1342%5CTJVlfE%25596& -- do not remove.) To respond, create a reply e-mail message that contains the survey. Some e-mail systems require you to manually copy and paste the survey into your reply. Make sure the reply contains the *entire* authentication marker, including what looks like garbage. To answer a question, type an x between the brackets, like this: [ x ]. For fill-in-the-blanks, type between the brackets like this: [ your response ]. Please make no other changes to this survey. 1. If for any reason you do NOT want to be contacted in the future via e-mail, please indicate after the first question by placing an "x" within the brackets. You will be omitted from future e-mail surveys. [ ] a) Please omit me from future e-mail surveys. 2. What is your company's PRIMARY industry or business? Choose one: [ ] a) Aerospace [ ] b) Communications carrier (telco, broadband, internet) [ ] c) Financial services [ ] d) Healthcare [ ] e) Manufacturing: computer/software [ ] f) Manufacturing: non-computer [ ] g) Government/military [ ] h) Publishing/media/advertising/public relations [ ] i) Transportation/utilities [ ] j) Wholesale/retail: non-computer [ ] k) Education [ ] l) Entertainment [ ] m) Computer reseller/retailer/VAR [ ] n) Systems integration/consulting [ ] o) Other, please specify... [ ] 3. What is your job function? Choose one: [ ] a) IS/MIS/Data processing [ ] b) LAN/network systems [ ] c) Internet/Web [ ] d) Intranet (in-TRA-net) [ ] e) Data communications/telecommunications [ ] f) PC/microcomputer/information center [ ] g) Systems analyst/applications development [ ] h) Systems engineer/integration [ ] i) Other computer-related, please specify... [ ] [ ] j) Executive/corporate office [ ] k) Financial/accounting [ ] l) Engineering/R&D [ ] m) Sales/marketing [ ] n) Other administrative, please specify... [ ] [ ] o) Consulting (computer related) [ ] p) Training/education [ ] q) Other professional, please specify... [ ] 4. Please check the statements below that describe your involvement with networks. Choose all that apply: [ ] a) I manage networks. [ ] b) I design networks. [ ] c) I install networks. [ ] d) I troubleshoot/fix networks. [ ] e) I train or support network users. [ ] f) I initiate the evaluation of new network technologies. [ ] g) I evaluate or specify brands of network products. [ ] h) I ensure that networks meet specific business or organizational objectives. 5. What is the scope of your involvement with networking in your organization? Choose one: [ ] a) Entire organization or enterprise [ ] b) Entire work location [ ] c) Multiple departments at more than one location [ ] d) For a single department only [ ] e) Other 6. How many servers do you have installed in your organization? Choose one: [ ] a) Over 50 [ ] b) 10 to 49 [ ] c) 1 to 9 [ ] d) None 7. How many LANS do you have installed in your organization? Choose one: [ ] a) Over 25 [ ] b) 5 to 24 [ ] c) 1 to 4 [ ] d) None 8. How many microcomputers/workstations are connected to LANS in your organization? Choose one: [ ] a) 500 or more [ ] b) 25 to 499 [ ] c) 1 to 24 [ ] d) None 9. How many employees do you supervise? Choose one: [ ] a) Up to 3 people [ ] b) 4 to 10 people [ ] c) More than 10 people [ ] d) None 10. Do you yourself have responsibility for networking education/training provided to employees in your company? Choose one: [ ] a) Yes [ ] b) No [ ] c) Don't know 11. What is the annual budget for education/training for yourself and those you supervise? Please enter the amount within the following brackets. [ ] 12. During the last 12 months, where did you or those you supervise receive education/training for networking? Choose all that apply: [ ] a) In-house [ ] b) University/college [ ] c) Seminars [ ] d) Internet [ ] e) Other [ ] f) No education/training on networking was received NOW WE WANT YOUR OPINIONS ABOUT A POSSIBLE EDUCATION CURRICULUM ON NETWORKING TECHNOLOGIES. For each of the following 10 course descriptions, please indicate your level of interest. 13. A Network Technologies course covering circuits and fibers; modulation and modems; LANs; WANs; frames; cell switching; wireless; satellites; connection-oriented and connectionless service; characteristics of each technology; addressing; media access; comparisons. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 14. A Network Interconnection and Internetworking course covering interconnection technologies; repeaters, bridges, and routers; internet addressing; address binding; datagram forwarding; techniques to accomodate heterogeneity (e.g. encapsulation and fragmentation). Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 15. A Network Protocols and Protocol Design course covering protocol layering; problems protocols solve; loss, reordering, corruption, congestion, duplication, and replay; techniques such as framing, checksumming, sliding window, and retransmission; focus on the transport layer, but cover other layers. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 16. A Routing and Routing Protocols course covering packet forwarding; route propagation; vector-distance and link-state algorithms; spanning tree. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 17. A Distributed Programming and Applications course covering client-server paradigm; socket API; middleware (e.g. RPC and CORBA); building a server; multithread server execution; protection and authorization; example applications. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 18. A Network and Protocol Performance Evaluation course covering throughput and delay; measuring and tuning protocols; instrumentation of protocol stacks; traffic analysis; self-similar behavior. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 19. A Networking and Protocol Support for Multimedia Applications course covering high-speed networks; resource allocation and performance guarantees; protocols for audio and video; techniques such as compression and delayed playback. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 20. An Advanced Server Design and Implementation course covering implementation of concurrent, parallel servers; large-scale designs; proxy servers (e.g., SLIRP); techniques such as buffering, replication, caching, and application gateways. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 21. An Advanced Routing course covering policy-based routing; multicast; mobility; inter- and intra-layer encapsulation; longest prefix forwarding table lookup algorithms; virtual LANS. Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 22. An Advanced Network Applications course covering EDI; electronic commerce; advanced Web techniques (e.g. Java). Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting 23. What would your level of interest be in taking a group of these courses as a coordinated curriculum? Choose one: [ ] a) Very interesting [ ] b) Moderately interesting [ ] c) Somewhat interesting [ ] d) Not at all interesting THINKING ABOUT THE CHARACTERISTICS AND BENEFITS OF DIFFERENT TYPES OF EDUCATION PROGRAMS that could be made available for networking technologies, please indicate which of the following would be important to you. 24. A course curriculum leads to an advanced college degree. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 25. Each course generates a document of professional certification. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 26. Course curriculum leads to an overall certification. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 27. Course is available at your place of work. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 28. Course is available at a local university or college campus. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 29. Courses available at an industry event you already attend. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 30. Courses conducted by an advanced educational institute staffed by networking experts. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 31. A core curriculum of a specified number of courses that would follow a building educational sequence. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 32. A concentrated face-to-face education program conducted over consecutive days. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 33. Ability to take class lessons, labs and tests over the Internet from your desktop. Choose one: [ ] a) Very important [ ] b) Somewhat important [ ] c) Not very important [ ] d) Not at all important [ ] e) No opinion 34. What other thoughts do you have concerning what could be done to improve educational or training programs on networking technologies? Please write within the brackets. [ ] 35. How many years have you been professionally involved in computing? Choose one: [ ] a) Less than 2 years [ ] b) 2 to 4 years [ ] c) 5 to 10 years [ ] d) More than 10 years 36. Which of the following ranges includes your age? Choose one: [ ] a) 18 to 34 [ ] b) 35 to 44 [ ] c) 45 to 54 [ ] d) 55 and older 37. Which of the following represents your highest level of education? Choose one: [ ] a) Attended high school [ ] b) Graduated high school [ ] c) Attended college [ ] d) Bachelor's degree [ ] e) Master's degree [ ] f) Doctorate degree 38. What do you estimate your total household income was last year? (Please estimate total income for everyone in your household, including salaries, wages, bonuses, interest, dividends, etc.) Choose one: [ ] a) Less than $15,000 [ ] b) $15,000 to $24,999 [ ] c) $25,000 to $34,999 [ ] d) $35,000 to $49,999 [ ] e) $50,000 to $74,999 [ ] f) $75,000 to $99,999 [ ] g) $100,000 to $149,999 [ ] h) $150,000 or more [ ] i) Don't know Thank you for participating in this survey.

1 0

totd
by Kelly J. Cooper 04 Aug '96

04 Aug '96

Traceroute of the day: traceroute to styx.ios.com (198.4.75.44), 30 hops max, 40 byte packets 1 cambridge1-cr1.bbnplanet.net (192.52.71.11) 3 ms 7 ms 8 ms 2 cambridge2-cr2.bbnplanet.net (192.233.149.202) 3 ms 3 ms 2 ms 3 alternet.bbnplanet.net (192.233.33.8) 4 ms 3 ms 3 ms 4 Hssi4-0.Boston3.MA.Alter.Net (137.39.100.97) 4 ms 3 ms 3 ms 5 Fddi0-0.Boston6.MA.Alter.Net (137.39.99.10) 5 ms 4 ms 4 ms 6 Hssi2-0.CR1.BOS1.Alter.Net (137.39.101.166) 130 ms 196 ms 11 ms 7 103.Hssi4-0.CR2.SCL1.Alter.Net (137.39.58.133) 93 ms 93 ms 94 ms 8 137.39.19.36 (137.39.19.36) 97 ms 93 ms 93 ms 9 137.39.63.35 (137.39.63.35) 99 ms 138 ms 96 ms 10 arpanet^255.255.2 (10.255.255.2) 178 ms 228 ms 234 ms 11 eth-0.gw-7.hck.idt.net (169.132.34.246) 297 ms 204 ms 249 ms 12 206.20.143.34 (206.20.143.34) 273 ms 230 ms 263 ms 13 styx.ios.com (198.4.75.44) 239 ms 288 ms 321 ms -- Kelly J. Cooper Network Analyst BBN Planet Corporation phone 800-632-7638 150 Cambridge Park Drive fax 617-873-6351 Cambridge, MA 02140 http://www.bbnplanet.com

8 8

What to do?
by jprovo 04 Aug '96

04 Aug '96

What would one do if they tripped across Net 10 [or other private nets] used & routed by an organization on the Greater Net? This isn't a case of waltzing through someone's firewall, either... Joe Provo Network Operations Center UltraNet Communications, Inc.

2 1