- NANOG - lists.nanog.org

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

RE: QOS or more bandwidth
by Frank Coluccio 29 May '01

29 May '01

>>>But what QOS features are included in the standard product offerings?<<< 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. ------Original Message------ From: Sean Donelan <sean(a)donelan.com> To: nanog(a)merit.edu Sent: May 29, 2001 6:17:46 AM GMT Subject: QOS or more bandwidth 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?

1 0

Re: VPN Solution (WAS: ORBS (Re: Scanning))
by Andy Bradford 28 May '01

28 May '01

Thus said "Patrick W. Gilmore" on Mon, 28 May 2001 01:24:58 EDT: > The VPN solutions I have used (e.g. Bay Networks, MS PPTP) send *every* > packet from the end user machine to the VPN end-point, not just selected > packets (like with SSH tunneling). This should be configureable, if it isn't then maybe it's time for a switch in protocols/software. :-) > So, does anyone know of a VPN that does selective forwarding like SSH > tunneling? FreeS/Wan does this by default. Only traffic defined by the tunnel security association is encrypted, the rest goes through untouched. Very optimal. :-) I don't believe this is specific to FreeS/Wan either, as most IPSEC implementations I have seen do something similar. (including hardware solutions). Andy [-----------[system uptime]--------------------------------------------] 3:43pm up 19 days, 18:20, 6 users, load average: 1.00, 1.01, 1.00

1 0

RE: EMAIL != FTP
by Roeland Meyer 28 May '01

28 May '01

> From: Scott Francis [mailto:scott@virtualis.com] > Sent: Friday, May 25, 2001 4:03 PM > Oh give me a break - is there ANY modern browser that will > not prompt you to > save the file if it does not recognize it as a displayable > format? Your > reasoning is going downhill ... Have you ever setup an Apache web server (or any other)? Create a random binary file and call it something.xyz (or any other extention not defined in your mime-type) and see if ANY browser will load it as something other than garbage.

11 14

RE: Layer4 Re: VPN Solution (WAS: ORBS (Re: Scanning))
by Roeland Meyer 28 May '01

28 May '01

> From: Jon Mansey [mailto:jon@interpacket.net] > Sent: Monday, May 28, 2001 7:37 AM > > Does anyone know of a way to put layer 4 switching in front of a VPN > client such that (for example) email and nntp dont get tunnelled > while everything else does, or vice-versa? Depending on requirements, isn't the whole idea to put the email into the tunnel? That's why this thread came up in the first place. BTW, SSH tunneling can drop every packet through the tunnel with a forward-all config. it isn't even very hard and can be done with a Win client, using F-Secure. In fact, sometimes that works, when PPTP doesn't, in Windows-hostile environments (*nix bigots sometimes do everything they can to screw up Win machines). However, none of it works when port 22 is blocked by the firewall. > We're probably talking Windows software here I know...... > > > > The VPN solutions I have used (e.g. Bay Networks, MS > PPTP) send *every* > >> packet from the end user machine to the VPN end-point, > not just selected > >> packets (like with SSH tunneling). > > If you want a commercial solution that does selective > tunnelling - the > >FW-1 addin (VPN-1) exports a "topography" file to the client > at setup; this > >really consists of a list of subnets that the VPN will > handle, and is set at > >the server side. anything not on the topography list goes > out via the dialup > >adaptor or network card as normal.

1 0

Possible solution? (e-mail parcel vs. FTP)
by E.B. Dreger 28 May '01

28 May '01

Here are my "givens": * Average users cannot, and will not, tolerate FTP * HTTP and FTP are more efficient than SMTP * New protocols (IM2000) might be nice, but we need interoperability * Attachments are usually MIME, with a few uuencoded ones now and then. Methinks that it's proxy time. Why not hack the popular MTAs so that they take attachments, spool them in a Web-accessible directory, then modify the message. Just like e-cards... ATTACHMENTS: 1. http://some.domain.tld/path/to/sample/file.jpg 2. http://another.place.tld/second-attachment.doc Go to the link, receive a warning that they must save the file after download, that it will be deleted after successful download. Or delete it after a few days. Or maybe users could manage their Web spool, deleting messages as they please. There are some details to work out, but is the "FTP upload" not a task that we could automatically perform for users? Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet Division Phone: (316) 794-8922 --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist(a)brics.com> To: blacklist(a)brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist(a)brics.com>, or you are likely to be blocked.

5 5