- Test - lists.nanog.org

Re: Real audio broadcast
by dgraves＠netreach.net 09 Feb '98

09 Feb '98

The real feeds don't appear to be up, as of yet... is this a known bug ?

3 2

Re: Real audio broadcast
by Dax Kelson 09 Feb '98

09 Feb '98

RealAudio is working, RealVideo is not. Dax Kelson Internet Connect, Inc. -----Original Message----- From: David Graves <dgraves(a)netreach.net> To: srh(a)merit.edu <srh(a)merit.edu> Cc: nanog(a)merit.edu <nanog(a)merit.edu> Date: Monday, February 09, 1998 10:30 AM Subject: Re: Real audio broadcast > >The real feeds don't appear to be up, as of yet... is this a known >bug ? >

1 0

Is NANOG on the MBONE?
by Michael A. Duckett 09 Feb '98

09 Feb '98

The audio session is not transmitting.. Michael Duckett Architecture (770) 522-4042 mduckett(a)bellsouth.net public key: http://home-world.eng.bellsouth.net/mduckett.asc

1 0

Real audio broadcast
by Susan R. Harris 09 Feb '98

09 Feb '98

Greetings - here are details about today's and tomorrow's RealAudio broadcasts of the main NANOG presentations. (We may also be carrying video - keep an eye on the Web page below for details.) - The broadcasts begin at 9am Mountain time. - The Real Broacast Network will archive both days and make the streams available for later playback. - MBone-connected users will automatically utilize IP-multicast -- everyone without MBone connectivity will utilize an appropriate unicast mode. - To jump to the live streams, users should first hit the NANOG agenda page at http://www.nanog.org/mtg-9802/update.html . Many thanks to Jeff Payne and Pat Combes from Real Broadcast for helping us set this up.

1 0

Re: MTU of the Internet?
by Sean M. Doran 09 Feb '98

09 Feb '98

Paul A Vixie <paul(a)vix.com> writes: > the fratricide thing someone else mentioned earlier today. That would be Frank Kastenholz, who I am pleased to discover slumming here. > this hurts our benchmark numbers but helps the backbones (where i came from) > and the origin servers (where some of my friends are). quite the dilemma. Frankly, the backbones could care less these days. Heavily decorated micropackets are becoming less and less toxic; at least one implementation is known to smile and ask for more at OC12 rates, another has hardware that can probably do this too. Magic flow-based switching schemes that open VCs and so forth might be happier, but I don't know of any actually deployed in a "backbone" per se. Tli was just pointing out n messages ago that no matter how well you do in terms of aggregating data traffic into bigger chunks, you still will see an enormous number of small packets around (ACKs). You have to be prepared to switch those at line rate; engineering for some statistical mix of big and small packets is asking for a disaster when someone suddenly goes simplex. There is, however, the spectre of there being so many SYNs flying around that they alone might cause congestion collapse. I dunno if I should be frightened of that or not, but I am not one of your origin server friends. --:) Finally, could your explain the "benchmark" comment a bit? Sean.

3 3

Canadians in Albuqueuque
by Phillip Vandry 09 Feb '98

09 Feb '98

We have notice quite a few Canadians on the attendee list, and we thought a BOF of Canadian issues might be a good idea. But Monday night seems to be booked pretty solid, with 4 BOFs already and a tutorial, so we haven't quite decided what to do yet. Anyway, stay tuned, we'll surely have more to say tomorrow. -Phil

2 1

cacheable HTTP?
by sully＠mail.usinternet.com 09 Feb '98

09 Feb '98

I've considered the pro's and con's of caching HTTP, and was wondering what, if any, software or hardware solutions you've implemented..and the success or failure you've experienced. Any response is much appreciated!

1 0

How not to use NANOG -- FastEther vs. FDDI
by John Hawkinson 09 Feb '98

09 Feb '98

So, as an exercise in self-flagellation, I went through the messages in the thread that began with: Date: Thu, 5 Feb 1998 19:42:02 -0500 (EST) From: Charles Sprickman <spork(a)inch.com> To: nanog(a)merit.edu Subject: FDDI or 100Mb Ethernet My principal observation was that collectively, we did a pretty poor job of utilizing the resources of this list. The original question asked seems relatively reasonable (though it's really related to LAN design/engineering and not the operational internet per se, but it's at least a question a number of small operators are asking, and is even similar to some that a number of big operators may be asking themselves). Our first response, from Kent, less-than-helpfully notes the existance of gigabit ethernet (way outside the bounds of the initial question) and suggests that the concurrent thread about MTUs is not to be payed attention to. Failure to address the initial query and failure to say *WHY* the MTU thread isn't worth listening to make this a poor response. Next, we get a reply from the oringal querrant, indicating he received 30 replies in favor of Fast Ethernet, and one in favor of FDDI, and thanking the list. While summarization to the list is appreciated, this level of summary is *NOT* useful. As should be grossly apparent to anyone who reads this list for even a short period of time, the quantity of a response has no discernable relationship to it's quality. If you ask a question and get a significant number of personal replies, summarization to the list is always good. But what's important to summarize is THE THINGS THAT PEOPLE HAVE SAID, not how many people have said them. The reasons why people indicated that Fast Ethernet might be preferable to FDDI in this particular scenario are what is important, not the number of people who may have had the Right Answer for the Wrong Reasons, or the Wrong Answer for the Right Reasons (or even those rare minority with the Right Answer for the Right Reasons)! Then we have a few replies that attempt to provide answers and provide small technical reasons why one of the choices is better. These are ok, except it seems likely these people didn't read the message from the original querrant indicating he'd already gotten "his answer". Either that, or they somehow felt that the answers he'd come up with, or the reasons given, were inadequate. Not that anyone bothered to say that, of course. I have difficulty seeing how the "Beowulf Project"'s choice of a LAN medium has much to do with the question at hand, or even closely related ones. But of course, I didn't slog through the entire web page that was cited. I skimmed it briefly. Presumably if one is going to cite a web page that's not directly relevent to the question asked, one should bother to be specific about what one is referring to and the relevence, if it's not completely obvious. Most service providers aren't building hypercubes... Not to mention that most web pages are ephermeral and the nanog mail archive is not, so a quotation rather than a citation is always nice. Some more commentary that fits the above classifications, and then a short anecdote about the nature of cascading layer two hardware in an enterprise network environment. Surely irrelevent to NANOG, but probably amusing to some. Personally I think it worsens the signal-to-noise ratio, especially when a thread has gone to pieces like this one has. But perhaps my sense of humor was removed at too early an age. Oh yes, then we have Paul and Sean off talking about migration paths, with cisco BFRs and OC3 connections. Proabably not very relevent to the initial query, but I suppose someone is curious, so why not re-iterate a discussion that everyone could find in the archives. But wait, then a segue into MPLS, the favored nanog discussion topic of the year, I'm sure. All-in-all, certainly not the worst thread we've had in a while. But well-managed, structured, something we can point to as a community and say "Yeah, we did a good job answering this question and producing thought-provoking discussion"? I think not. I suppose my cynicism must have reached new heights if this is what I'm bothering to waste my time on. Still, perhaps this missive will make people think just a little bit harder about the things they're going to say; if so, even if it wounds characters, it will have served its purpose. --jhawk

1 0

Re: MTU of the Internet?
by Sean M. Doran 09 Feb '98

09 Feb '98

"William Allen Simpson" <wsimpson(a)greendragon.com> writes: > This is supposedly an operations list. So, everyone, when are you > configuring it in _YOUR_ Cisco? Ebone will be deploying code that does RED in CEF in approximately nine hours. I expect BC and I will be playing with RED most of this week, seeing how the Cisco implementation does on congested high-speed and sometimes high-delay interfaces where traffic is very heavily aggregated. I am not sure anybody else has done this yet (jhawk?) although there is some positive experience with RED on slow interfaces. Sean. - -- Sean Doran <smd(a)ebone.net> Development Manager, Ebone Inc., Copenhagen Denmark

2 1

Re: MTU of the Internet?
by William Allen Simpson 09 Feb '98

09 Feb '98

I hate to extend this thread any, but there is too much misinformation to let slide.... > From: Stephen Sprunk <stephen(a)sprunk.org> > Does anyone have data to show if any terminal servers or client stacks > will honor TOS bits and/or known interactive port numbers when > ordering packets for transmission across slow links? > Well, actually, every NAS for every vendor that I've ever worked with honors the TOS bits (usually in numeric order) and gives precedence to interactive traffic on outbound links, even fast ones, when there is a queue. Telebit, NEC, Rockwell, for examples. Heck, that was even true for the stack in a cellular phone (Qualcomm). In response to the speculation that some bytes are forwarded without determining TOS or packet size, I doubt that anybody is doing cut-thru routing for 28.8 Kbps to 10 Mbps or vice versa. Pretty silly idea. No gain. An entire packet is sent at 10 Mbps in the time that it takes for 4 bytes to show up at 28.8 Kbps. FYI, a larger number of these smaller MTU packets will actually cause _more_ loss due to memory congestion. Modern stacks do not allocate packets on a byte by byte basis. They allocate a buffer the size of the largest allowable incoming packet on an interface (often called p-bufs). So, a 40 byte packet takes the same memory as a 1500 byte packet. You don't get 3 times as many packets at 576. There's no gain in trimming the packet down after it comes in, the whole thing is just going to be returned to the memory pool in milliseconds anyway. As to the proposal that the big packets could be sliced and diced to allow a smaller interactive packet thru -- well, the PPP fragmentation header has been out there for years, but nobody really implements it, even for multi-link. Too much pain, not enough gain. Same problems as ATM. The real problem is that too many OSes do not implement RFC-1123 Host Requirements, even after 8 years. As I remember the words of one clueless product manager a year or so ago, listed in his byline as a renowned Internet expert, complaining that (paraphrased) Simpson believes that only those who have steeped in moldy RFCs should be allowed to write network stacks. It was pretty clear that he had not bothered with reading too many of them on his way to becoming a self-described expert, and very clear that his staff was none too familiar with them, either. And MicroSoft apparently has even more problems than Apple. The real answer for ISPs is to never ship Explorer on your configuration CD, since it is impossible to make well-behaved. Preconfigure Navigator to 2 streams. And even better, set Auto-Load Images Off. There is a nice big Images button to load the images on a page on those rare occasions that you actually want to see them.... You will find that your users will be much happier with their networking experience, and you will have fewer support calls. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

3 2