February 1998 - Test - lists.nanog.org

HEllo to any on NM
by Alex Rubenstein 08 Feb '98

08 Feb '98

This is absolutely, no way in any way, shape, or form, and operational issue. Anything going on this afternoon in Albequerque?

1 0

Re: MTU of the Internet?
by Paul A Vixie 08 Feb '98

08 Feb '98

this was sent to me personally but seems generally relevant. > There is at least one case where multiple connections will > be faster, and I suspect there are actually several. tcp without congestion avoidance is always faster than tcp with congestion avoidance. whether you take away congestion avoidance by running lots of short lived connections in parallel, or whether you actually dyke out the code that avoids congestion, the result is the same: other tcp's will back off and give you more of the channel. this is another example of a cooperative protocol suite trying to survive in a competitive world. that tcp only behaves well if all other tcp's behave well, where "behaves well" means "shares paths fairly" creates an automatic incentive on the part of some designers to not "behave well" so they can get more than their fair share. this feeds directly into arguments about flat rate, peering, open smtp relays, checking of source addresses on egress gateways, and the rest of the usual nanog chatter. > [there is a] paper on TCP performance over satellite links > (really any long-fat-pipe), and [there is] a lot about TCP performace > I would have never expected. One of the simpler ideas is the > "TCP speed limit". You must have buffer space that is greater than the > bandwidth * delay product to keep the pipe full. yes. this is why we have a window scale tcp option now. and this buffer requirement is per end-host, whether there are multiple tcp sessions or just one. > On very high delay > links (satellite) or very high bandwidth (OC-3/OC-12 to the desktop) > current workstations don't allocate enough buffers, either system > wide or per-connection. at least one satellite ip provider is evaluating transparent caching as a way to obviate these effects by aggregating dumb-client connections into something smarter for the sky link. > So, if you have a system with per-connection bufffering, and > that hits a "speed limit" of 512 kbits/sec over your satellite T1, > you can raise the speed up to the full T1 by opening 3 streams. Thus > more connections == faster downloads. it's still the same amount of buffering per end host though. > ... The same group ... did some satellite testing, trying > a parallel FTP client they had. They benchmarked 1, 2, 4, 8, and 16 > streams between two SunOS 4 boxes over a T1 satellite (500ms RTT). > Maximum performance (shortest transfer time) was achieved with 4 > TCP streams. that's got more to say about the sunos tcp implementation than about tcp as a protocol. > I'll throw in one more subjective measure. When Netscape > first came out some of the CS people at Virginia Tech wondered about > the perception, and did some tests with willing college student > subjects using Mosaic (which at the time supported HTTP keepalives, > and used them to connect to the server once for all transfers) > and Netscape (multiple connections, no keepalives). > ... > On the more complex pages Mosaic downloaded and displayed the > page faster, in wall clock time, but the users always preferred > Netscape. The observation is that many people don't wait for > a full download, they click on picture links, for instance, > when they are half down....so having them all half down allows someone > to proceed with browsing, rather than having half fully there, and > half not visable. which means the server gets a lot of RSTs and a lot of data which is committed into the path ends up being thrown away. seems like if we wanted things to go faster, we would waste less bandwidth by sending only data which was useful and not creating a huge number of retrans- missions by effectively turning off tcp congestion avoidance. > ... - I would suspect that two connections > with keepalives would be optimum....you get multiple stream advantages, > minimize load on the server, and can drive those two connections > fast (past slow-start) as they are long lived. i agree. too bad the browser manufacturers are driven by competition rather than cooperation. of course, human nature has in this case created a product opportunity in transparent caching.

2 1

real video xmission of NANOG
by Sean M. Doran 08 Feb '98

08 Feb '98

Hi Bill et al - Have I missed the promised details of the Real Video transmission of the NANOG conference? Also, is there any chance you could also provide a recorded copy for download for those people who are time-zone or work-load impaired? Sean.

1 0

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

08 Feb '98

I won't touch the other stuff in the message, although there are some errors. This leapt out and is related to a couple of private conversations. Marc Slemko <marcs(a)znep.com> writes: > > Like maybe a lack of buffer space in terminal server? > > I doubt it. Personally, aside from a gain for interactive work over a > loaded low bandwidth connection, especially with some sort of priority > queueing used, I find no gain from a smaller MTU on a dialup link. Yes. The problem is not the lack of buffer space but a surplus of it. TCP will always find the choke point in a path and attempt to fill the queue directly in front of it. The congestion window will tend to stabilize on the amount of buffer space available to it at that point plus any additional propagation delay times the bandwidth at the choke point. With a tail-drop queueing "discipline", a TCP flow may have a sizeable amount of buffering available to it before a tail drop occurs; unless this is moderated by something like RED, several seconds of queueing delay should be expected. Moreover, unless, as you note, there is some sort of priority queueing, this means that a new burst of traffic will be delayed by the length of the queue, i.e., several seconds. Not so fun. Note that using small MTUs does not alter this; once TCP has discovered the amount of buffer space in front of the choke point, as long as it keeps transmitting constantly, modulo drops elsewhere, no matter what the MTU size is, the same amount of buffer space will be occupied. In fact, given that the congestion window is measured in bytes and not segments, with a smaller MTU and path MTU discovery (or fragmentation before the choke point) you will have a *longer* queueing delay thanks to the additional header bytes, assuming the queue is "slotted" with N buffers rather than just a linear array of bytes. The appropriate solution is to use RED to moderate the amount of space that any given TCP flow can occupy in a queue to a small number. This allows a flow in equilibrium to adjust to transient congestion due to other traffic through the congestion point, and also allows that other traffic through with potentially much shorter delays, without causing the choke point to become idle. Examining Floyd & Jacobson's work at ftp.ee.lbl.gov is well worthwile, btw. Sean.

1 0

mae-east problems...
by Rich Fulton 08 Feb '98

08 Feb '98

Anyone else seeing odd packet loss through mae-east? // Rich Fulton // Sr. Network Engineer/Systems Admin. // ClarkNet - A Verio Affiliate

6 7

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

07 Feb '98

Ron Fitzherbert <ron(a)penguin.net> writes: > What I would like to know is: is there a MTU that is best to use IN > GENERAL, or should we all just trust discovery and live with it? MTUs should reflect the largest datagram size transport media can carry, period. Small MTUs, whether by design or configuration, limit the flexibility of end systems in choosing to send appropriately large datagrams without introducing IP fragmentation. Sean.

1 0

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

07 Feb '98

Eric Osborne <osborne(a)notcom.com> writes: > We all know that there's good reasons for all sorts of > different MTUs, mainly because of the different types of > traffic you could have - there's always going to be a > tradeoff between efficient transfer of large blocks of > data and immediaecy (sp?) of response time. I know no such thing. My understanding of MTU is that the Maximum Transmission Unit indicates the largest IP datagram a logical transport medium is able to carry without fragmentation. There are, however, reasons why one might choose to send a datagram (which may contain a TCP segment or some other traffic) at smaller sizes than the transport medium or media may support. Sean.

1 0

NANOG 12 Network/Internet Information
by jmbrown＠ihighway.net 07 Feb '98

07 Feb '98

Here is some of the information people have been requesting. CIDR Block is 206.29.134.0 /24 206.29.135.0 /24 Default routers: 206.29.134.1 /24 206.29.135.1 /24 nanog-rtr-01.ihighway.net nanog-rtr-02.ihighway.net DNS Servers 206.29.134.10 /24 Both Forwards and IN-ADDRS 206.29.135.10 /24 ns1.nanog.ihighway.net ns2.nanog.ihighway.net All IN-ADDRS will be of the form 206-29-13{4|5}-xx.nanog.ihighway.net SMTP (For sending mail) 206.29.134.11 /24 smtp.nanog.ihighway.net This machine will NOT ALLOW relays from outside. It will be monitored. NO SPAM! Shell Account: 206.29.134.12 /24 shell.nanog.ihighway.net USER: Nanog Password: Nanog If you hack it and crash it, I'll delete it! :) Net Trek Server: 206.29.134.13 /24 netrek.nanog.ihighway.net NANOG Traffic Stats: http://mrtg.nanog.ihighway.net:80 There will be a DHCP server installed and operational. This machine will issue leases for about 100 addresses. In addition __STATIC__ addresses will be self-assigned by going to the terminal room and getting a slip of paper from a Clip-Board. If you have the paper, you have the address. This sheet will also tell you the default router, DNS, SMTP and SHELL account addresses. In addition there will be a Net Trek server, for those of us that want to play in the evenings! :) It will be avail 3x24. --------------- We will have over 350 Cat 5 10baseT ethernet drops available in the main hall. Please bring your LAPTOP. You might want to bring a power strip as well. This is a BYOPC event! Bring Your Own Patch Cord (25 feet min) See ya in Albuquerque jmbrown(a)ihighway.net

2 1

RE: MTU of the Internet?
by Tony Hain 07 Feb '98

07 Feb '98

This thread has drifted all over the place and the only conclusions I can see are: The core infrastructure MTU is >= 1500 People are telling clients to set their Win95 MTU to 576 PMTU is randomly broken by clueless filtering Some dial-access devices are buffer limited A small MTU (53 byte?) would increase perceived response at the expense of performance I have been an advocate of the bigger defaults is better camp, but there is a real concern that the wrong values could actually cause more damage than their gain is worth. If the above list is incorrect or incomplete it would be useful for people to constructively tell Peter that now.

3 2

Re: FDDI or 100Mb Ethernet
by Lewis Eatherton 07 Feb '98

07 Feb '98

FDDI would be my last choice. 100MB ethernet can be run full duplex, is less expensive, and far easier to troubleshoot. At 07:42 PM 2/5/98 -0500, Charles Sprickman wrote: >Hi, > >We colocate with our upstream, so we (thankfully) don't have to deal with >Bell Atlantic for our main Internet connection. We are currently running >a 10Mb ethernet link to our provider, but our contract allows for more >than that should we ever need it. Since the Bay ASN we now use will soon >be history and will be replaced by a shiny new(?) Cisco, I'm thinking of >upgrading the link now rather than later. > >We have a choice of FDDI or 100Mb ethernet. I'm thinking FDDI is better, >and not too much more expensive for our side. Are there any negatives >with FDDI? How does the 4000(?) Byte MTU affect things? All of our >outgoing links, T1 and ether are all 1500. Does the work of fragmenting >the packets down to 1500 amount to anything? All this talk about MTUs has >got me wondering. > >Thanks, > >Charles > >~~~~~~~~~ ~~~~~~~~~~~ >Charles Sprickman Internet Channel >INCH System Administration Team (212)243-5200 >spork(a)inch.com access(a)inch.com > > > Lewis Eatherton Network Architect SegaSoft, Inc 650.654.2318

9 9