- Test - lists.nanog.org

Re: MAE-EAST Moving? from Tysons corner to reston VA.
by Paul Vixie 18 Jun '00

18 Jun '00

mark(a)exodus.net (Mark Tripod) writes: > I'm not sure that I'd use AboveNet as the benchmark for the hosting > industry. I think I agree. Abovenet's ISX sites (while world class) are really just points of sale for the company's real product, which is connectivity. A fair number of Abovenet's customers purchase connectivity without also purchasing colocation -- and I can't think of any "hosting" company for which that would be true. (No "hosting" company of which I'm aware has its own global optical network.) -- Paul Vixie <vixie(a)mibh.net> SVP for Internet Services, MFNX M.I.B.H. Inc. is a subsidiary of Metromedia Fiber Network, Inc.

4 3

Re: MAE-EAST Moving? from Tysons corner to reston VA.
by Sean Donelan 17 Jun '00

17 Jun '00

I think you are making an argument by definition. No "hosting" company has a global optical backbone, because if it had a global optical backbone its not a hosting company. No tier 1 provider buys transit, because if it bought transit it wouldn't be a tier 1 provider. On Sat, 17 June 2000, Paul Vixie wrote: > sean(a)donelan.com (Sean Donelan) writes: > > I don't understand your distinction. Several companies sell both hosting > > services and network services. GlobalCenter/Crossing, Genuity/BBN and > > Worldcom/UUNET have large "global" optical networks and hosting divisions. > > Those companies also sell circuit-based services, i.e., services that do > not require hosting in order to accept delivery of them. Genuity's home > page mentions DSL, for example. These are fine companies, with fine > networks, but they are not "hosting" companies any more than making tanks > in WW2 made Chrysler into a weapons company or making keyboards and mice > makes Microsoft a hardware company. If it's just one thing they do, then > it doesn't make sense to label the company by it.

1 0

Re: MAE-EAST Moving? from Tysons corner to reston VA.
by Paul Vixie 17 Jun '00

17 Jun '00

sean(a)donelan.com (Sean Donelan) writes: > I don't understand your distinction. Several companies sell both hosting > services and network services. GlobalCenter/Crossing, Genuity/BBN and > Worldcom/UUNET have large "global" optical networks and hosting divisions. Those companies also sell circuit-based services, i.e., services that do not require hosting in order to accept delivery of them. Genuity's home page mentions DSL, for example. These are fine companies, with fine networks, but they are not "hosting" companies any more than making tanks in WW2 made Chrysler into a weapons company or making keyboards and mice makes Microsoft a hardware company. If it's just one thing they do, then it doesn't make sense to label the company by it. -- Paul Vixie <vixie(a)mibh.net> SVP for Internet Services, MFNX M.I.B.H. Inc. is a subsidiary of Metromedia Fiber Network, Inc.

2 1

Re: MAE-EAST Moving? from Tysons corner to reston VA.
by Sean Donelan 17 Jun '00

17 Jun '00

On Sat, 17 June 2000, Paul Vixie wrote: > (No "hosting" company of which I'm aware has its own global optical network.) I don't understand your distinction. Several companies sell both hosting services and network services. GlobalCenter/Crossing, Genuity/BBN and Worldcom/UUNET have large "global" optical networks and hosting divisions.

1 0

Re: MAE-EAST Moving? from Tysons corner to reston VA.
by Richard A. Steenbergen 17 Jun '00

17 Jun '00

On Fri, 16 Jun 2000, Ted Schroeder wrote: > As one of the early evangelists for jumbo frames I can say with > some amount of authority that the number we (Alteon WebSystems) > were/are pushing for is 9000 bytes. There are other numbers bandied > about, but 8940 was never one of them. 9216 was the other usual > candidate as it matches up with ATM. Come to think of it I can't see any good reason for 8940. FDDI is 4352, FDDI*2 is 8704. 9216 should behave nicely w/AAL5. > The IEEE will simply say, "only up to 1500 bytes". I've fought this > battle with very little success. Rich's book will only talk about 1500 > bytes. I've spoken to him about this a number of times and he's > personally opposed to anything other than 1500 bytes. I know there is a discussion of jumbo frames there, and its not terribly negative from what I can recall. > And, for those of you who think that things might get better in the future, > let me be an omen for even worse times to come. For 10 Gb Ethernet, > there are proposals on the table that will, for the first time, make frames > larger than 1522 bytes physically impossible. These proposals have to > do with speed matching between the WAN 10GE and the LAN 10GE > and minimum buffer sizes used to accomplish this speed matching. > > As one of the lone voices at the 802.3 meetings calling for longer frame > support, I've pretty much given up on ever seeing a longer MTU officially > supported by the IEEE. Perhaps if more people were going there that > weren't hardware vendors with an "obvious interest in only pushing > their products" the IEEE members would be more likely to listen. But > I wouldn't necessarily bet on it. There was a push early on during PAR > discussions of 10 GE to allow larger frames but it was clear that this > was a losing battle, so the push ended. Ugh, from an all around perspective I believe we need an MTU offically longer then 15??. Its better for applications, better for operating systems, better for anything that must be interrupted per frame/packet, better for anything which needs to work paged memory, and better for anything which needs to do routing per packet. 9000-range works well for server to server or backbone to backbone connections where you're aiming for NFS optimization or being able to support large packets without fragmentation across a NAP for example, but I would suggest you're aiming for trouble trying to take server-traffic past what is supported by FDDI/PoS, and 4k works well for many of the above problems. The standardization of a higher number is needed, or we are just going to see more of these problems as people seek to improve their networks in incompatible and confusion-introducing ways. PMTU-D has obvious problems. It would seem to me the cleanest course of action would be to put a fragmentation encountered flag somewhere along the line. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

2 1

Re: MAE-EAST Moving? from Tysons corner to reston VA.
by Richard A. Steenbergen 17 Jun '00

17 Jun '00

On 16 Jun 2000 michael.dillon(a)gtsip.net wrote: > On Fri, 16 June 2000, "Richard A. Steenbergen" wrote: > > >In a public exchange point where you're talking to multiple networks > >across a shared media it makes sense to do GigE, multiple GigE, 10GigE, > >etc, > > What is the largest MTU that you can use across a GigE fabric? I think this would be extremely foolhardy. The common number that all those using jumbo frames should support is 9000 bytes (not 9k aka 9216). This would probably need to be a condition of using GigE at the NAP, in order to achieve any kind of common support, and you're eliminating some vendor gige support (assuming their network can even carry the 9k packets TO the nap without requiring even more work and possible problems). Has anyone tested these maximium sized jumbo frames with 802.1q vlan tagging to see exactly how much (or how little) inter-vendor support really exists? -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

2 2

Re: MAE-EAST Moving? from Tysons corner to reston VA.
by Richard A. Steenbergen 17 Jun '00

17 Jun '00

On Fri, 16 Jun 2000, Mark Tripod wrote: > ----- Original Message ----- > From: "Richard A. Steenbergen" <ras(a)e-gerbil.net> > To: "ted hardie" <hardie(a)equinix.com> > Cc: "Wayne Bouchard" <web(a)typo.org>; <nanog(a)merit.edu> > Sent: Friday, June 16, 2000 1:49 AM > Subject: Re: MAE-EAST Moving? from Tysons corner to reston VA. > > > | I don't believe its nearly this bad. It seems to me that the VAST majority > | of backbone private peering is still happening at the OC3 level. In a > | public exchange point where you're talking to multiple networks across a > | shared media it makes sense to do GigE, multiple GigE, 10GigE, etc, with > | OC48 or > feeding it, but due to the nature of the beast (the fact that > | you're exchanging traffic in multiple locations with multiple networks), > | private peering is in no such immediate danger. > | > | Infact a lot of "backbone to backbone" peering is still done with DS3s > | (think of the content providers with little need to talk amongst eachother > | in bulk, GlobalCenter, Exodus, AboveNet, etc). The interesting traffic is > | where the data providers (like those mentioned above) meet the data > | suckers (@Home, AOL, etc), especially as streaming media takes off. > > You'd be surprised by how much bandwidth is required between hosting > companies. Companies that host at multiple locations and on different > providers networks require that the connectivity between those networks be > very robust so that they can transfer large amounts of data between their > server farms. http://stats.sjc.above.net/traffic/nyc/nyc-exodus.html http://stats.sjc.above.net/traffic/iad/iad-exodus.html http://stats.sjc.above.net/traffic/sjc2/sjc2-exodus.html http://stats.sjc.above.net/traffic/sjc/sjc-exodus.html http://stats.sjc.above.net/traffic/iad/iad-globalcenter.html Not nearly as much as one would thing, and if nothing else at least not mainly for that reason. Most of this bandwidth could probably be accounted for by the occational customer that doesn't fit the usual webhosting role and is pulling content from the "other" hosting companies. Though I'll be the first to agree that if they were serious about rhobust reliable service this would be more of the case. :P At any rate this is primarily burst traffic, and in the grand scheme of things it probably wouldn't account for a majority of traffic even if many more people were doing this. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

3 3

Re: MAE-EAST Moving? from Tysons corner to reston VA.
by Richard A. Steenbergen 17 Jun '00

17 Jun '00

On Wed, 14 Jun 2000 hardie(a)equinix.com wrote: > In either case, Mark's point about scaling interconnect > bandwidth is a key question. On one hand you have Tier-2 ISPs who > want fast ethernet based systems, because they don't really have an > immediate need to go for anything faster; on the other, you have > backbone-to-backbone traffic that is rapidly moving to the point where > the only thing that will make sense is to trade a lambda. It's hard > to have public exchange that it is a good entry point for a Tier-2 > that also meets the needs of the backbones. Using multiple different > exchange methods to handle the different needs is one way around > the problem, but it comes at a cost in gear, support, and network > engineering. The inertia in existing traffic exchange mechanisms > is also high enough that what tends to happen is that new connections > take new forms but the old mechanisms aren't taken out of service > at any speed--which again has a cost in gear, support, and network > engineering. I don't believe its nearly this bad. It seems to me that the VAST majority of backbone private peering is still happening at the OC3 level. In a public exchange point where you're talking to multiple networks across a shared media it makes sense to do GigE, multiple GigE, 10GigE, etc, with OC48 or > feeding it, but due to the nature of the beast (the fact that you're exchanging traffic in multiple locations with multiple networks), private peering is in no such immediate danger. Infact a lot of "backbone to backbone" peering is still done with DS3s (think of the content providers with little need to talk amongst eachother in bulk, GlobalCenter, Exodus, AboveNet, etc). The interesting traffic is where the data providers (like those mentioned above) meet the data suckers (@Home, AOL, etc), especially as streaming media takes off. If we had a few more PAIX's and Equinix's in strategic locations the internet would be a better place. :P -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

4 3

Re: MAE-EAST Moving? from Tysons corner to reston VA.
by Richard A. Steenbergen 17 Jun '00

17 Jun '00

On Fri, 16 Jun 2000, John Fraizer wrote: > If I'm not mistaken, 9000bytes is the max. > > >From acenic.c (By D.Becker of course) > > * To enable jumbo frames, simply specify an mtu between 1500 and 9000 > * bytes to ifconfig. Jumbo frames can be enabled or disabled at any time > * by running `ifconfig eth<X> mtu <MTU>' with <X> being the Ethernet > * interface number and <MTU> being the MTU value. > > On 16 Jun 2000 michael.dillon(a)gtsip.net wrote: > > > > > On Fri, 16 June 2000, "Richard A. Steenbergen" wrote: > > > > >In a public exchange point where you're talking to multiple networks > > >across a shared media it makes sense to do GigE, multiple GigE, 10GigE, > > >etc, > > > > What is the largest MTU that you can use across a GigE fabric? Jumbo frames are not part of the 802.3z standard. I believe the talk of a standardized length is 9000 bytes, but until then it should be understood that not every vendor will support it, or support the same number (and not every driver for every NIC will support it either). Cisco claims to support up to 10420 bytes, for example. For some of the other arguements about MTU size, take a look at: http://www.columbia.edu/acis/networks/advanced/jumbo/jumbo.html > "Jumbo frames" extends ethernet to 9000 bytes. Why 9000? First because > ethernet uses a 32 bit CRC that loses its effectiveness above about > 12000 bytes. And secondly, 9000 was large enough to carry an 8 KB > application datagram (e.g. NFS) plus packet header overhead. Is 9000 > bytes enough? It's a lot better than 1500, but for pure performance > reasons there is little reason to stop there, though at 64 KB we reach > the limit of an IPv4 datagram. The 32-bit CRC limit though is hard to > change, so for ethernet, don't expect to see frame sizes above 9000 > anytime soon. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Re: MAE-EAST Moving? from Tysons corner to reston VA.
by Steven M. Bellovin 16 Jun '00

16 Jun '00

In message <87256900.00780D04.00(a)d53mta03h.boulder.ibm.com>, trall(a)almaden.ibm. com writes: > > > >On 06/16/2000 at 11:10:55 AST, John Fraizer <nanog(a)EnterZone.Net> wrote: >> If I'm not mistaken, 9000bytes is the max. > >I don't understand how ethernets, at the MAC layer, can support frames >greater than 1500 bytes. Looking at the MAC frame format, we have: > >ethernet DIX V2 DA(16 bits), SA(16 bits), type (16 bits), data >IEEE 802.3 DA(16 bits), SA(16 bits), length (16 bits), LPDU (802.2) > >The traditional way to distinguish between the 2 formats depends on the >length value (in 802.3) being no greater than 1500, and on the type value >(in DIX) being greater than 0x05dc (1500 decimal). > >Assuming you're still going to allow both formats on the same lan, how does >it work if the length is greater than 1500? See http://search.ietf.org/internet-drafts/draft-kaplan-isis-ext-eth-02.txt for one proposal. --Steve Bellovin

1 0