- Test - lists.nanog.org

Re: backbone routers' priority settings for ICMP & UDP
by Vern Paxson 04 Feb '98

04 Feb '98

> As is (reasonably) well known, TCP has its own congestion control built > in to an extent. This should be put much stronger - TCP's congestion control is *the* mechanism that keeps the network stable today. > Or is Source Quench really broken by design? Pretty much. It's flawed in at least two important ways: (1) it adds traffic to the network during times of congestion; and (2) if a source quench packet is dropped, then the intended target fails to receive the notification to slow down. Both of these lead to the wrong sort of feedback cycle when the network is heavily congested - a cycle that can make congestion self-sustaining, i.e., congestion collapse. Vern (There may be a niche for source quench, though, in environments with high-latency links, where the quicker feedback than that obtainable from RED+ECN might be a sufficiently big win.)

1 0

Re: MTU of the Internet?
by Eric Germann 04 Feb '98

04 Feb '98

-----Original Message----- From: Robert E. Seastrom <rs(a)bifrost.seastrom.com> To: peterf(a)microsoft.com <peterf(a)microsoft.com> Cc: nanog(a)merit.edu <nanog(a)merit.edu> Date: Wednesday, February 04, 1998 1:40 PM Subject: Re: MTU of the Internet? <SNIP> </SNIP> >I have no idea where they came up with this "576 internally" nonsense. >Generally whenever one runs into that number it is as a result of >creaky old software that expects to be running over milnet or arpanet. > IPX used 576 forever whenever you had to cross IPX "subnets". The reason was simple. They were lazy. 576 was the least common denominator between Ethernet, TR, and _Arcnet_ Large IPX (LIPX) allowed them to do basically what IP calls Path MTU discovery. Only took them a day short of forever to figure out how to do it. >Are Microsoft stacks known to be broken in the packet >fragmentation/reassembly department? Or are just acknowledging >deficiencies in their path mtu discovery code by setting the MSS in >the basement? I knew they had problems with window length (this from >my friends with long fat pipes)... > With all the paranoids trying to block all ICMP, not just ICMP_ECHO, doesn't that essentially break PMTUD. 576 may not be efficient, but its probably the safest to assume.

2 1

backbone routers' priority settings for ICMP & UDP
by Marko B. 04 Feb '98

04 Feb '98

Greetings, In my travels I have heard numerous times that it is a popular practice to give ICMP and even UDP traffic a lower priority on backbone routers in times of congestion. Are there any providers that document this policy? How is this policy carried out on the actual hardware? Any pointers would be appreciated. Thanks. -Marko

8 12

Re: backbone routers' priority settings
by vaananen＠NASBPD01BS.ntc.nokia.com 04 Feb '98

04 Feb '98

>>> ICMP in general is or should be given higher priority, since it is >>> necessary for congestion control. Echo requests (pings) could be thrown >> >>Please, tell me of this magic ICMP that is used for congestion control. >>Obsolete things that are now recommended against don't count. >Where is ICMP made obsolete or recommended against? I don't see it. >From rfc1812: ... stuff deleted Also from RFC1812: 4.3.3.3 Source Quench A router SHOULD NOT originate ICMP Source Quench messages. As specified in Section [4.3.2], a router that does originate Source Quench messages MUST be able to limit the rate at which they are generated. DISCUSSION Research seems to suggest that Source Quench consumes network bandwidth but is an ineffective (and unfair) antidote to congestion. See, for example, [INTERNET:9] and [INTERNET:10]. Section [5.3.6] discusses the current thinking on how routers ought to deal with overload and network congestion. A router MAY ignore any ICMP Source Quench messages it receives. DISCUSSION A router itself may receive a Source Quench as the result of originating a packet sent to another router or host. Such datagrams might be, e.g., an EGP update sent to another router, or a telnet stream sent to a host. A mechanism has been proposed ([INTERNET:11], [INTERNET:12]) to make the IP layer respond directly to Source Quench by controlling the rate at which packets are sent, however, this proposal is currently experimental and not currently recommended. Pasi

2 1

Re: MAE-Central
by Sean M. Doran 04 Feb '98

04 Feb '98

"Kent W. England" <kwe(a)geo.net> writes: > (BTW, isn't it scandalous that MFS would copy the PacBell NAP and build a > MAE using S'com BPX switches? No, just tragically stupid. Sean.

5 5

BGP mailing list
by Bradley Reynolds 04 Feb '98

04 Feb '98

Because I was tired of BGP questions coming onto a wide variety of lists, I created a mailing list for them. To subscribe, send mail to bgp-request(a)iagnet.net with 'subscribe' in the body. Note: This list deals with more of the ground level BGP understanding. It is not intended to replace/duplicate bgp(a)ans.net. Just a wishful attempt to improve the clue factor :). BR brad reynolds ber(a)cwru.edu

1 0

Re: with a flap flap here and a flap flap there...
by Sean M. Doran 04 Feb '98

04 Feb '98

Marc Slemko <marcs(a)znep.com> writes: > 3333 6905 5623 1136 3300 7018 6478 1 701 814 7189 1691 852 6171 (history entry) > Am I the only one that has a problem with this? You withdraw a > route once, and it has flapped enough to be dampened in numerous > places. I could have been half convinced that we had gone back to > distance vector routing seeing this going on... BGP *is* a distance-vector routing protocol. What you were witnessing was a counting-to-infinity problem that is bounded by timers and toplogical constraints. Welcome to the wonderful world of BGP == RIP. This is precisely why a mechanism which constrains the amount of prefix transitions is so important: magnification of flapping is predictable. However, welcome to the wonderful world of lack of filtering, too. There is no apparent reason why a number of those ASes should have reannounced your routes to each other. Each BGP peering (customer and peer alike) should either explicitly allow announcements only from a list of appropriate ASes, or explicitly disallow announcements which have been through peers and (at least large) other BGP-talking customers. This is an Incredibly Smart Thing To Do. On a Cisco, the _ operator is your best regexp friend... Sean.

2 1

Re: Transparent Caching Solutions - Information Wanted
by Paul A Vixie 04 Feb '98

04 Feb '98

several folks have sent replies to me personally which may be of general interest: > Hit rates are user population dependent. We have seen hit rates > as high as 30% from a single T1 connected customer (with a population > of less then 500 people). so have we. but that was a computer club with its own POP and they were mostly sharing interesting (i.e., pornographic) URL's over an IRC back channel. we've got ~80 transparent caching units out in the field, and most of them are in "normal" modem pools where the users don't know each other and the communitities of interest have broader splay. > ... in some special cases you really can predict what would best be in the > cache beforehand. You then win from a speed standpoint (pre fetched data > is served up faster). yes, that's true -- in some special cases you can exercise prescience and if you can then the hit rate goes up by a lot as does the downstream data rate. however, to make this work you have to continuously feed the primary caches new prescient data (or prescient metadata by which prescient data can be fetched). interest factor is in other words dynamic and shortlived.

2 1

Re: MAE-Central
by Sean M. Doran 04 Feb '98

04 Feb '98

Dave Siegel <dave(a)rtd.net> writes: > Dave (who's waiting to see a NAP built with a GSR (or similar) ) Almost. Well, that is, this is almost what you are waiting for. What you should want is a NAP that scales upwards from a level below the interfaces that the GSR can give you. In effect, what you want is a NAP that looks like this: {ethernet,atm,POET,HSSI}--7507--POS---1 blabla------7507--POS---2 0---POS---customer 1---POS---customer 2---POS---customer of course, in order for this to work, you really want to be running MPLS on all the devices from the *connectee* inwards. This gives you a multi-media connection to a NAP at speeds ranging from slow (you could do DS0s on a 7507, for example) to fast (you could do STM-16c/OC48c out the 12012). Note that I was even really nice and left "atm" up there as a potential access method. This is similar to what Milo and I wanted to do with the MAE-WEST conspiracy to let the NSF declare the PAC*Bell and MAE-WEST facilities to be co-priority-NAPs. Unfortunately someone (ahem) played politics better than us on that one front. On the other hand, the PAC*Bell NAP has hardly been a model of stunning success as a result... Anyway, the idea is that you can colocate or not colocate at this facility as you see fit, and you can use several access technologies including some carrier's ATM fabric. The NAP is extensible -- you could have a really big ATM channel into the 12012 with lots of VCs talking MPLS, for example, if that was really popular. There are some interesting questions about what to do when multiple load-balanced OC48s among several 12012s don't provide enough bandwidth at a decent cost, but those interesting questions plague other parts of the Internet where that will be a ceiling faster (probably). Deployment problem #1: MPLS availability. Interim gross hack #1: GRE tunnels across a private small-i internet using RFC-1918 space. (GRE tax is high, but it is perhaps less gross a hack than several other possibilities that have sprung to mind). The JUUNIPERMCIWORLDPALMPEXETC people reading this may wish to advance alternatives to the 12012, or a supplement for the 12012 for "robustness". tli has, after all, also proposed designs very similar to this; i think one was even posted to NANOG... Sean. P.S.: POET (packet over E3/T3) is very cool as a sort of lower-speed alternative to point-to-point POS. It does very well in this type of environment... Thank you auntie Cisco.

1 0

Re: Transparent Caching Solutions - Information Wanted
by Paul Gauthier 04 Feb '98

04 Feb '98

Paul Vixie wrote: > > Inktomi <URL:http://www.inktomi.com> has announced their intention to offer > transparency but they are not an appliance (like Cisco, Vixie, and NetApp) > and last I heard they were waiting on some Solaris kernel changes before > they could actually ship transparency. > Paul Vixie gave a nice summary of some of the cache solutions available. To be absolutely correct, Inktomi's Traffic Server network cache does very much ship with integrated transparency today! It also provides a bunch of cache services that people like including multicast clustering, HSRP-derived failover, centralized management, adaptive networking and a fast raw-disk object store. We have some info on Inktomi's home page (www.inktomi.com) if you are curious. Paul

1 0