- Test - lists.nanog.org

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 08 Feb '98

08 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 08 Feb '98

08 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

RE: MTU of the Internet?
by Peter Ford 07 Feb '98

07 Feb '98

There are other techniques such as split-TCP and Snoop that can be applied in place of a POP based Web cache. On the other hand, RAS/NAS servers that are under-buffered are not part of the solution space. trenchingly yours, peter > -----Original Message----- > From: Phil Howard [SMTP:phil@charon.milepost.com] > Sent: Friday, February 06, 1998 7:32 PM > To: ltd(a)interlink.com.au > Cc: nanog(a)merit.edu > Subject: Re: MTU of the Internet? > > > perhaps this is one of the not-so-obvious benefits of running a web > > proxy cache such as squid. the greater internet can have larger > > packets floating around, and the local proxy of the ISP can deal with > > horrible tcp stacks, retransmissions and client machine with small > > receive buffer sizes. > > And imagine having 2 interfaces on this machine, one with MTU=1500 and > one with MTU=576. > > -- > Phil Howard | no33ads4(a)dumb5ads.org ads6suck(a)dumb2ads.org > stop3it7(a)spammer9.com > phil | no0way72(a)lame7ads.net die8spam(a)no99ads1.net > eat7this(a)anyplace.com > at | w5x8y4z5(a)anyplace.com stop2it1(a)spammer0.com > a9b0c8d8(a)noplace4.com > milepost | die6spam(a)noplace8.com end6it79(a)no2place.com > a5b0c5d3(a)s0p8a2m1.edu > dot | crash053(a)anyplace.org crash981(a)spam6mer.com > end8it77(a)dumbads7.org > com | no20ads6(a)anyplace.org stop6221(a)dumb3ads.com > ads9suck(a)no7place.net

2 1

RE: MTU of the Internet?
by Joe Provo - Network Architect 07 Feb '98

07 Feb '98

tonyhain(a)microsoft.com wrote: > 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 > You missed: HTTP is a painful protocol. jzp

2 1

Re: Quality of Service by Ferguson and Huston
by Matt Magri 07 Feb '98

07 Feb '98

Hank Nussbacher <hank(a)ibm.net.il> wrote: >At 03:39 PM 2/4/98 -0500, Gordon Cook wrote: >>For ordering data on the book see: >>http://www.wiley.com/compbooks/catalog/24358-2.htm > >Or go to www.amazon.com and save 20% on Wiley's price (ISBN0471243582). It was even lower at www.bookpool.com when I checked there (searched for "Quality of Service"). They probably won't send you as many ads as Amazon, tho... ;-) Matt -- Matt Magri Netmeg Internet

1 0