- Test - lists.nanog.org

RE: NANOG Digest V1 #737
by Roeland Meyer 29 May '01

29 May '01

I got one too...same conditions ... no action on my part. > -----Original Message----- > From: Kai Schlichting [mailto:kai@pac-rim.net] > Sent: Tuesday, May 29, 2001 8:02 AM > To: nanog(a)merit.edu > Subject: Re: NANOG Digest V1 #737 > > > > Hmm, is this just me, or did someone else start receiving the > digest version this morning,too - without any action on his/her own? > Simultaneously, I receive the regular (non-digest) list mail > as well. Both come from the same host (trapdoor.merit.edu) > > > > Received: from trapdoor.merit.edu > (postfix(a)trapdoor.merit.edu [198.108.1.26]) > > by conti.nu (8.9.3/8.9.3) with ESMTP id GAA06067 > > for <kai(a)pac-rim.net>; Tue, 29 May 2001 06:35:35 -0400 (EDT) > > Received-Date: Tue, 29 May 2001 06:35:35 -0400 (EDT) > > Received: by trapdoor.merit.edu (Postfix) > > id 227A291218; Tue, 29 May 2001 06:28:57 -0400 (EDT) > > Delivered-To: nanog-digest-outgoing(a)trapdoor.merit.edu > > Received: by trapdoor.merit.edu (Postfix, from userid 56) > > id B735C91217; Tue, 29 May 2001 06:28:56 -0400 (EDT) > > From: owner-nanog-digest(a)trapdoor.merit.edu (NANOG Digest) > > To: nanog-digest(a)trapdoor.merit.edu > > Subject: NANOG Digest V1 #737 > > Reply-To: > > Sender: owner-nanog-digest(a)trapdoor.merit.edu > > Errors-To: owner-nanog-digest(a)trapdoor.merit.edu > > Precedence: bulk > > Message-Id: <20010529102856.B735C91217(a)trapdoor.merit.edu> > > Date: Tue, 29 May 2001 06:28:56 -0400 (EDT) > > X-UIDL: 913bee7d2f58a5cea4042a463d2a49f6 > >

1 0

Tucows/OpenSRS Down
by Seth M. Kusiak 29 May '01

29 May '01

It appears that Tucows/OpenSRS is down and service should be restored by 1:00 PM EST today. Does anyone know what happened and why there is no announcement on the ICANN website? Thanks, -Seth

3 2

RE: QOS or more bandwidth
by Ukyo Kuonji 29 May '01

29 May '01

The problem is, while most vendors support tagging and priority queuing, non of the current vendors can support true end to end QoS. Instead, we have taken to calling their options CoS. The problem that I have seen is that while you can make certain that a good effort is made to ensure that your high proirity traffic is transmitted before your best effort traffic, you have no real way to ensure that the high priority arrives at the destination in the same manner that it was transmitted. I'm talking about packet order, jitter, and latency. Sure, it will probably get there, but will the data still be worth anything. For Internet traffic, QoS/CoS is probably not worth it, as there is no way to realistically do either across two or more network providers. The real need will be on single provider wishing to sell more than just Internet across their expensive backbone. Such applications will be Toll-quality voice, production/broadcast-quality video, VPN, etc. The way I have seen it, either IP QoS will have to become a reality, or the applications themselves will need to change to handle the poor CoS substitute that is offered now. UK --- Opinions in this email are the personal opinions of the author and are not associated with author's employer. This email account is a not the regular email account of the author and is being used for the protection of the employer. --- Original Message --- Most competitive vendors now provide native and upgrade provisions for QoS in one form or another. The problems most often encountered revolve around multi-vendor cos/qos feature implementation incompatibilities. The "least common denominator features" that are needed for basic interworking usually do not extend to 'differentiating' features that vendors like to hold close to the vest, such as prioritization and cos/qos features. Not without much grief, in any event. It forces one to seriously consider single vendor solutions. fwiw. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

2 1

QOS or more bandwidth
by Sean Donelan 29 May '01

29 May '01

While its generally more effective to add more bandwidth than rationing it with QOS, with the recent downturn in capital markets will QOS become more popular? If your budget for bandwidth has been cut, I'm not sure people will have any budget for QOS either. But what QOS features are included in the standard product offerings?

5 5

Re: QOS or more bandwidth
by smd＠clock.org 29 May '01

29 May '01

| I would disagree and argue that your core needs to be running top of the | range routers with fat pipes with spare bandwidth, for a large network if | you run out of CPU or bandwidth your routers will simply fall over. Which CPU are you worried about? My top-of-the-range routers all seem to have more than a dozen in them... The bandwidth I'm worried about right now is on the memory busses; the optical people who make things that blink lights really quickly are well ahead of IP's present needs. | (plus [QoS] will slow down the routing process). Which routing process? Assuming you mean packet forwarding will be slowed down, that really depends on architecture (more modern ones won't show a measurable slowdown, and even less modern ones don't care much about work-conserving fancy queueing - consider Villamizar's projections on SFQ vs CPU/state). Assuming you mean signalling - well - it depends on how you do it. Static support for preset "flavours" (DSCP, diff-serv code points is the jargon - sorry :) ), a small number of priority levels for WFQ or WRED, and so forth is pretty easy to set up. Reservations- based signalling (RSVP et al) is a bit harder, and also consumes more non-human resources. However, I would worry more about QoS signalling slowing down human processes, such as debugging problems and handling complexity, than I would about QoS slowing down high-end packet processing equipment. That said, since detecting blinking lighs fast enough is not presently a constraint on growth, a toolset whose principal use is combatting situations in which there is a bandwidth constraint seems more like an unnecessary frill than essential equipment. Sean.

1 0

RE: QOS or more bandwidth
by smd＠clock.org 29 May '01

29 May '01

"Ukyo Kuonji" <kawaii_iinazuke(a)hotmail.com> | The problem is, while most vendors support tagging and priority queuing, non | of the current vendors can support true end to end QoS. Where is the interoperability document (e.g. RFC) that describes "true" "end to end" QoS? In the absence of such a document, from which anyone can build an interoperable "true" "end to end" QoS system into his or her product, I am tempted to believe that such buzzwords are weapons in a DoS attack by marketroids. | you have no real way to ensure that the | high priority arrives at the destination in the same manner that it was | transmitted. I'm talking about packet order, jitter, and latency. TDM. What flavour would you like? SONET/SDH? PDH? "Virtual dark fibre"? ITU-Grid optics? | Sure, it will probably get there, but will the data still be worth anything. If you're not sure that it'll be worth anything on arrival, you shouldn't send in the first place. Be liberal in what you accept, and conservative in what you send is a good maxim. RFC 2001 style congestion avoidance is an excellent example of a system which follows this maxim closely. | For Internet traffic, QoS/CoS is probably not worth it, as there is no way | to realistically do either across two or more network providers. I keep waiting for a document which describes RSVP-TE/X.75 gatewaying to solve this particular problem. | Such applications will be Toll-quality | voice, production/broadcast-quality video, VPN, etc. These are all travelling across multiple-provider paths today... | The way I have seen it, either IP QoS will have to become a reality, or the | applications themselves will need to change to handle the poor CoS | substitute that is offered now. The latter distributes the problem better. The former requires well-adapting, well-behaved, Internet-ready apps to subsidize the migration of apps which are not all of these, and that will not fly. (Note that even the poor CoS substitute is unnecessary for current well-adapting, well-behaved, Internet-ready apps... that's one reason they're so inexpensive.) Sean.

1 0

[zoc-0635624] [uunet-395213]: Not to be alarmist, but is there a known problem in San Diego?
by Bill Woodcock 29 May '01

29 May '01

UUNet says that they're opening a lot of tickets there, starting at 5:35am PST, and we lost a bunch of stuff down there, and every _voice_ phone number I've tried in the 619 or 858 area codes gets an error message "We're sorry, the number you're calling cannot be completed from this telephone at the customer's request". That includes both the NOC for the San Diego Supercomputer Center and the NOCs of several San Diego-area ISPs. Anybody else noticing anything? -Bill

2 3

RE: ORBS (Re: Scanning)
by owen＠dixon.delong.sj.ca.us 29 May '01

29 May '01

> > I don't buy the "we need open relay for nationwide users" argument, > > either. Build a cheap MX that does nothing but take mail from a given > > POP, and send it to the world. Anti-spoofing at the border, > > don't accept mail from the outside world, and you're done. > > You must not have a roaming staff or are willing to keep telcos wealthy. > > Roaming staff usually needs some form of VPN access, anyway, and even if they don't, this is a great use for one. Put a VPN client on the roamer's computer (Linux, Mac, and Windows 9x/NT/ME/2k all have IPSEC capable clients available), then use the VPN to get back to the mail relay. If the mail relay is behind the VPN tunnel termination point at the server end, then it should only accept mail for relay from valid VPN clients. As such, you solve the roaming staff problem without an open relay. VPN boxes like Ravlin and Nokia Crypto Cluster are cheap enough today that I would consider it a valid cost of doing business if you don't have a better solution. Owen

9 8

port filtering list
by chrisb＠kippona.com 29 May '01

29 May '01

Does anyone keep track of packet filtering based on destination port, of the form: provider ports action ------------------------------------------------ uu.net 25 drops all outbound <another>.net 25,465,587 drops all outbound aol.com ?? ?? msn.net ?? ?? earthlink.net ?? ?? demon.co.uk ?? ?? ... ... ... More and more users want to roam and knowing this info ahead of time helps. Chris

1 0

RE: Email Parcel Post is Good!
by Roeland Meyer 29 May '01

29 May '01

> From: Andrew Brown [mailto:twofsonet@graffiti.com] > Sent: Friday, May 25, 2001 10:59 AM > > >> that and a small perl script are how i get all the > internet drafts and > >> rfcs as they are published. > > > >Do you seriously expect a marketing VP to write perl? > > no. i expect someone to tell the marketing vp that emailing large > documents is "wrong" and that someone will fedex them some floppies. > or a zip disk. or a jaz disk. or a dlt tape containing a bzip2'ed > copy of a hpodc cpio archive. in halfword swapped format. :) > > but not email. ... and you expect to get this disk from Livermore to Chicago, in 5 minutes, ... how? Business moves at Internet speeds these days, in case you hadn't noticed. To put it in a way even understandable to techies; Collaborrative document, updated and swapped between 4 authors, and reviewed by two others, widely separated geo-physically. Revised and rewritten 5 times per day, for a week (Not counting NetMeetings). Trust me, management does work this way. Process run-time, with email = 1 week; with FedEx = 1 month. Process cost (transit only), with email <= $20, with FedEx = $4500 (FedEx = very happy) Real cost; Deal is blown out because deliverable is three weeks late. Instant lost revenue. > my opinion. opinion: invalid.

3 2