June 2000 - Test - lists.nanog.org

Re: PMTU-D: remember, your load balancer is broken
by Richard A. Steenbergen 16 Jun '00

16 Jun '00

On Wed, 14 Jun 2000 Valdis.Kletnieks(a)vt.edu wrote: > On Tue, 13 Jun 2000 22:36:08 MDT, Marc Slemko said: > > Except that, technically, you are not permitted to just blindly send > > segments of such size. Well, you can but systems in the middle don't > > have to handle them. No? > > Hmm.. either I did a bad job of explaining or I haven't had enough caffiene > to parse what you said. Given that you also suggest going to a 1460 MSS, > I suspect that we're actually violently in agreement here. > > Now if I can remember why I chose 1396 for a default MSS.... ;) > > > It is also a concern that, in my experience, many of the links with > > MTUs <1500 are also the links with greater packet loss, etc. so > > you really don't want fragmentation on them. > > The worst part here is that I suspect that most of these links (just on > sheer numbers of shipped product) are the aformentioned Win98 576-MTU. > > However, in this case, the fragmentation happens in a terminal server on > the last hop, and hopefully the case of a terminal server running out of > queueing buffers and having to drop one of the 2 remaining fragments of > a 1500->576 split after sending the first one is pretty rare.... > > I seem to remember that the *original* motivation for slow-start and > all that was Van Jacobson's observation that the most common cause of > a TCP retransmit was that an *entire* packet had been silently dropped > due to queueing congestion, and could thus be treated identical to > an ICMP Source Quench. > > Has this changed? Has "fragmentation" become a Great Evil, rather than > an annoyance that some links have to deal with? Anything not in the fast-path (fragmentation, IP options, etc) is a scourge to all that is good and rightous about networking. In other words, if it isn't an every day occurance people seem to forget that it needs to be cared about, checked for "issues", DoS potential, etc (I just heard about a DoS potential against a popular unix stack because of lack of bounds checking in the IP options this evening in fact). I'm hoping IPv6 will fix some of that for IP options, since they're a bit more usable and a bit more important, but I doubt anything will change the mentality. Fortunantly it seems that the backbone links are all running larger MTUs then the hosts (PoS, FDDI, jumbo frame support for gige, even if it isn't standard). As long as its the hosts shrinking the MTU and not the network in-between things are better, its just less then "optimal" thruput. Simple WFQ would be of more use to those poor bastard souls on dialup though. If you are a provider running the tunnel (not on an end host where MSS can be set), you would do well to keep the available MTU post-tunnel >= 1500 to keep everyone happy, if at all possible. Just a quick 5:30AM thought, but it seems like a better solution would be to have the hosts signal that fragmentation was encountered on the ACK, so if ICMP discovery is not possible the packets are not lost with no idea why (it can go right next to the ECN bit :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)

2 1

RE: Application versimilitude (was RE: PMTU-D: remember, your loa d balancer is broken )
by rdobbins＠netmore.net 16 Jun '00

16 Jun '00

-----Original Message----- From: Roeland Meyer (E-mail) [mailto:rmeyer@mhsc.com] Sent: Friday, June 16, 2000 12:28 AM To: rdobbins(a)netmore.net; ssprunk(a)cisco.com Cc: nanog(a)merit.edu Subject: RE: Application versimilitude (was RE: PMTU-D: remember, your load balancer is broken ) >snip< >Actually, this is simplistic. There are many cases where you have >either binary-only (as in the case of Oracle) or the code has >been thorugh the QA cycle and one is not allowed to touch it >(even if one is allowed, hopefully one would know better). Oh, I agree with that. In the binary-only or past-QA instances, one must do lots of sniffing and tweaking. I guess all this "let's go to big MTUs NOW" talk just struck me as a bit premature. ----------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice

1 0

Re: exchange point media (was: Re: MAE-EAST Moving? ...)
by Richard A. Steenbergen 16 Jun '00

16 Jun '00

On Thu, 15 Jun 2000, Simon Lockhart wrote: > > >The other question is what is the actual capability of the GigaE cards in > >a cisco box? I have been told (not played with GigaE on cisco yet and for > >that matter, neither has the person who told me) that it is limited to > >around 400Mb/s. > > On a 7xxx Cisco, yes, it's limited to 400Mb/s, due to limitations on the > interface to the backplane (or VIP2 in the 75xx). > > On the Cisco 12000, the backplane interface is 2.5Gb/s, so the GigE cards > can run at full speed. On 12008's and 12012's with older SFCs. The backplane on the 12016 supports 10Gbps each direction. Interestly, Cisco is doing 3 port gige cards which oversubscribe the older SFCs. Last I heard they were doing updated SFCs for the 12012 but not the 12008. At any rate, Cisco does support jumbo frames, which can be up to 9k (just set the mtu to 10240), but if I recall correctly jumbo frames were not standard in 802.3z? http://grouper.ieee.org/groups/802/3/ -- 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

Application versimilitude (was RE: PMTU-D: remember, your load ba lancer is broken )
by rdobbins＠netmore.net 16 Jun '00

16 Jun '00

>snip< >Without doing performance analysis on the actual running code, >there really isn't a lot else to look at. Shouldn't that be the first step in the optimization process? Finding out if the code and the server itself are are operating as efficiently as possible -prior to- mucking about with the network (this assumes a bit of thought and planning and maintenance have gone into the network beforehand, so that there're no glaring, generic things which ought to be fixed)? Knowing what your application(s) - or your customers' application(s) - look like on the wire can be an invaluable aid in the code-optimization process, in my experience. Of course, in a public environment, one's options are restricted by the limits of currently-deployed-and-accepted technology. ----------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice

2 1

Re: PMTU-D: remember, your load balancer is broken
by Steven M. Bellovin 16 Jun '00

16 Jun '00

In message <200006140333.e5E3XmL28888(a)black-ice.cc.vt.edu>, Valdis.Kletnieks@vt .edu writes: > >b) If you're a webserver or something else providing service Out >There to random users, just nail the MTU at 1500, which will >work for any Ethernet/PPP/SLIP out there. And if you're load >balancing to geographically disparate servers, then your users >are probably Out There, with an MTU almost guaranteed to be 1500. > >I assert that the chances of PMTU-D helping are in direct ratio to the >number of end users who have connections with MTU>1500 - it's almost >a sure thing that you probably won't have users with an MTU on their >last-hop that's bigger than their campus backbone and/or Internet >connection's MTU. > >Is anybody seeing any documentable wins by using PMTU-D? There are two places where it's very important. First, some server farms are on FDDI rings, so they have a higher MTU. Second -- and this one is growing in importance -- tunnels, for IPsec, PPTP, etc. -- generally have smaller MTUs. This very reply will travel over a tunnel with an MTU of, I believe, 1480. --Steve Bellovin

5 6

Are You In Debt ?
by flowers100＠uk2.net 16 Jun '00

16 Jun '00

1 0

Re: Summary: Bay Area Power (2000-06-14)
by Steven M. Bellovin 15 Jun '00

15 Jun '00

In message <200006152243.SAA24809(a)montu.connix.com>, gwright(a)thebiz.net writes: > >I was under the impression that these power shortages were the >result of less over-engineering on the part of power companies due >to deregulation but maybe this isn't such a new situation after all? > > There was an interesting article in the May 11 Wall Street Journal about how deregulation has led to this situation. I quote: Deregulation, now under way in 24 states, upsets that structure and allows new players -- some affiliated with utilities, some not -- to build power plants and sell electricity. Prices are set by competitive markets; risks are borne by investors, not ratepayers. At the same time, utilities are surrendering control of long-haul transmission lines to new nonprofit operators whose job it is to ensure fair access to the grid -- the multistate system of high-voltage lines. The result: a national electricity system that is vulnerable to disruptions caused by equipment breakdowns and human error as newly established regional grid operators assume responsibility for much larger areas than those formerly overseen by individual local utilities. For big energy users, who expected deregulation to bring lower prices, not lower reliability, it has been a worrisome experience. Briefly, established power companies were worried that decreasing prices would prevent them from earning money on their investment; new players held off until they could figure out what markets would be most profitable. The transmission system is in bad shape, too -- San Francisco is specifically identified as having poor connections to the larger power grid. There's a lot more in the article, including notes about how incomplete deregulation has contributed. If you subscribe, you can find it at http://interactive.wsj.com/archive/retrieve.cgi?id=SB957998459784551619.djm

1 0

Re: Summary: Bay Area Power (2000-06-14)
by Sean Donelan 15 Jun '00

15 Jun '00

Large power consumers can sign an interrupt able contract with a (deregulation) power company. Interruptible agreements give a discount in exchange for the promise the customer will voluntarily curtail their usage when asked. If they don't, they get socked with penalties. These agreements have existed for decades. On Thursday, PG&E asked its interruptible customers once again to curtail their usage. Involuntary curtailment is different. The prediction is involuntary curtailments and interruptions will become more commonplace as the market adjusts to deregulation. Hopefully, once deregulation is sorted out the proper incentives will exist to construct additional transmission and generation facilities. Some electrical customers disconnect from the grid anytime a potential exists for an unscheduled interruption. For example, some sensitive facilities switch to internal power anytime lightning strikes within five miles. They believe their internal power systems are better (albeit more expensive to operate) than the utility power. There is a different school of thought which believes transferring to an alternate power source is risky in and of itself, so its better to stay with the utility until it fails, because the utility may not fail but the transfer could. Finally, if you speak with the right people at the Edison Institute, they are very frank, there is always the potential for an unscheduled power interruption. Anyone who absolutely, positively can not risk any chance of an interruption should have an independent, standby power source. On Thu, 15 June 2000, gwright(a)thebiz.net wrote: > lucifer(a)lightbearer.com writes: > > At least one major data center disconnected from the grid and went to > > generator power, prior to the rolling blackouts. The motivation was not > > stated, but it seems likely that they were requested to do so as part of > > the voluntary interruption efforts. No interruption of service was seen. > > In a conversation with an MFS engineer today I mentioned the problems > in the Bay area. He previously worked for SNET (Southern New > England Telephone, now part of SBC) for many years and said it was > standard practice for them to disconnect COs from the grid and run > off generator power for hours or even a day or two during the > summer season. > > I was under the impression that these power shortages were the > result of less over-engineering on the part of power companies due > to deregulation but maybe this isn't such a new situation after all?

1 0

Re: Summary: Bay Area Power (2000-06-14)
by Danny McPherson 15 Jun '00

15 Jun '00

I believe they're more so the result of "brown outs" as the power companies attempt to "proactively" deal with extremely high loads. Given your message, I guess it does make sense for the power companies to first inconvenience business customers that 1) use a substantial amount of resources and 2) already have alternative method of supporting themselves. Of course, I'd guess there's considerable ground for objection to this model. -danny > In a conversation with an MFS engineer today I mentioned the problems > in the Bay area. He previously worked for SNET (Southern New > England Telephone, now part of SBC) for many years and said it was > standard practice for them to disconnect COs from the grid and run > off generator power for hours or even a day or two during the > summer season. > > I was under the impression that these power shortages were the > result of less over-engineering on the part of power companies due > to deregulation but maybe this isn't such a new situation after all? >

1 0

IGP Survey
by Danny McPherson 15 Jun '00

15 Jun '00

Could anyone that's every "deployed" an IGP take just a second to answer the following questions? Please reply in private, I'll send a summary to the list. Thanks in advance! -danny [snip] Included below are several questions regarding IGP use. If you don't have the time to complete the entire questionaire, answering the first three questions would still be of great benefit. Not answering specific question(s) is also fine (as you may have guessed). The information collected will be made generally available once complete. 1. Company Name (please provide so that multiple response for a single network are appropriately accounted for): 2. Do you wish to keep the company name confidential? 3. What IGP did you select: 1) OSPF 2) IS-IS 3) RIP 4) RIPv2 5) IGRP 6) EIGRP 7) Static 8) Other (please list) 3. Why did you select this IGP (list all that apply, in order of precedence)? 1) Scalability 2) Stability 3) Robustness 4) Vendor Support 5) Familiarity 6) Existing Deployment Base 7) Historical Reasons 8) Feature Set (i.e. Traffic Engineering) 9) Other (please list) 4. If you run a LS protocol, do you run the network (complete AS, or backbone) as a single area, or do you use multiple areas? 5. In case of OSPF, do you use stub, non-stub or NSSA? 6. In case of IS-IS, one level or multiple levels? 7. What do you believe is the primary advantage of this IGP? 8. What do you believe is the primary disadvantage of this IGP? 9. What notable features of the protocol do you use (i.e. OSPF NSSA)? 10. If applicable, what routes do you carry in your IGP in relation to BGP (i.e. customer and internal, internal only, etc..)? 11. How may prefixes do you carry in your IGP? 12. Do you use (or plan to use) your IGP for MPLS traffic engineering? 12a. If not, any particular reason why? 13. Do you use one IGP or multiple IGPs? 13a. As a result of: 1) Having two historical networks, and "redistribute" between them? 2) or maybe every BGP confederation sub-AS runs their own IGP? 3) one IGP (linkstate ?) in the middle, and another (RIP?) at the edges? 4) maybe overlap IGPs 5) maybe one IGP per continent (US vs Europe vs Asia) 6) Other (please list) 14. Do you tweak the protocol's configuration (like changing default timers)? 14a. What values do you feel need the most attention? 15. If you could change/enhance anything with this IGP what would it be? 16. How may routers were in the routing domain? 16. Do you have any additional comments you'd like to share?

1 0