From: Carlos G Mendioroz (tron@huapi.ba.ar)
Date: Wed Oct 02 2002 - 20:05:46 GMT-3
The issue is complicated, to say the least. Some facts:
-NBAR only takes part of the traffic :-(
it catches fasttrack, napster (don't know if all of current
openNap versions) and gnutella. But there are tons of new
apps coming almost daily! (e.g. e-donkey2000)
-most do have some known ports for the peer2server link,
but peer2peer port is configurable, i.e., no fixed setup
can catch them.
-They do become hogs of bandwidth quite easily. I would not
vote for an ISP doing any policing, but this is shared bandwidth
for a university that I'm talking of.
-And users do adapt quite fast to anything you do.
My real problem is that ftp passive traffic has the same
port fingerprint. And ftp is considered "valid" so I guess
I have to come up with some kind of dynamic policy maker
based on many flows at once...
I'm trying to setup such a system. If anyone wants to discuss it,
let me know and we can talk about it offline. This is quite OT
for this list...
BTW, just ignore the postings made by psychology students working on
human reaction to strong stimuli :-)
Michael Snyder wrote:
>
> Ssh, telnet, pcanywhere, terminal services, use small packets!!!
>
> All the bandwidth hogs use large packets.
>
> The only exceptions would be web and email which we can use port
> numbers.
>
> From my point of view, everything that is interactive, that makes the
> user think the provider has fast internet, could be self tuned using
> small packets vs large packets.
>
> BTW, I'm not saying to block large packets, just to put bulk file
> transfers on the back burner in favor of the interactive services that
> users like. Internet radio, etc.
>
> Also not have to worry about the port numbers of kazaa anymore.
>
> The only interactive service I can think of that breaks the rule is
> internet video, and remember I was talking about outgoing traffic. This
> wouldn't affect incoming video streams from the internet.
>
> One more thing, the outgoing pipe is so congested that the tcp-acks are
> being dropped. Moving the acks to high precedence would allow more of
> the incoming pipe to be used.
>
> Just an idea,
>
> Michael
>
> -----Original Message-----
> From: Chris [mailto:clarson52@comcast.net]
> Sent: Wednesday, October 02, 2002 4:15 PM
> To: Church, Chuck; 'Michael Snyder'
> Cc: ccielab@groupstudy.com
> Subject: Re: dealing with fastrack (Kazaa et.al.)
>
> I agree. I would not want my ISP deciding what traffic is more
> important. I
> use ssh, ipsec, telnet etc. and some applications that would really
> suffer
> from something like that, especially when it involves remote control
> apps.
>
> And if Kazza is that popular on the providers network then why would you
> want to restrict it? If I were them I would be finding a way to appease
> those customers as an important part of their revenue base. File sharing
> is
> great. Piracy is an issue, but file shouldn't be.
>
> ----- Original Message -----
> From: "Church, Chuck" <cchurch@USTA.com>
> To: "'Michael Snyder'" <msnyder@revolutioncomputer.com>
> Cc: <ccielab@groupstudy.com>
> Sent: Wednesday, October 02, 2002 4:18 PM
> Subject: RE: dealing with fastrack (Kazaa et.al.)
>
> > So this ISP is going to try prioritizing traffic? Sounds like a can
> of
> > worms. Who's to say who's traffic is more important, outside of the
> control
> > traffic, of course. You're not dealing with one customer. You're
> dealing
> > with hundreds. Most cable providers limit your upload speed, which
> might
> > help, but that's a policing thing, which is done on the cable modem
> configs,
> > I think.
> >
> > Chuck Church
> > CCIE #8776, MCNE, MCSE
> > Sr. Network Engineer
> > Magnacom Technologies
> > 140 N. Rt. 303
> > Valley Cottage, NY 10989
> > 845-267-4000
> >
> >
> >
> > -----Original Message-----
> > From: Michael Snyder [mailto:msnyder@revolutioncomputer.com]
> > Sent: Wednesday, October 02, 2002 3:56 PM
> > To: 'McClure, Allen'; 'Church, Chuck'
> > Cc: ccielab@groupstudy.com
> > Subject: RE: dealing with fastrack (Kazaa et.al.)
> >
> >
> > Been thinking about this lately.
> >
> > Got a local cable modem provider getting hammered by kazaa and it's
> > like.
> >
> > The network admin of the provider is inept, and can barely put an
> access
> > list together. You would grin if you saw some of the configs I've had
> > to help with.
> >
> > The reason I'm sharing the above info is that CAR, CBWFQ, & LLQ is out
> > of this guys grasp for now, and of course he wants to maintain it
> > himself.
> >
> > Well, with the kiss method in mind, I think I have come up with a
> > possible solution.
> >
> > The main router has multibundle T1's going out, and lan interfaces
> > coming in from the rest of the cable equipment.
> >
> > My idea is to put WRED on the multibundle wan interfaces, because it's
> > much more likely to drop low precedence packets than high precedence
> > packets.
> >
> > Then to use a route-map on the lan interfaces to set precedence on the
> > outgoing wan packets. Something like the following.
> >
> > Set voice packets to set precedence to 5.
> >
> > Set any packet with less than 384 bytes to precedence value 4, because
> > nearly any interactive ip services uses small packets, games, im,
> > ip-ack, etc.
> >
> > Set any web or email packets to precedence value 3.
> >
> > Set ftp and nntp to precedence value 1.
> >
> > Leave everthing else (kazaa et.al) at precedence 0 to be dropped
> first.
> >
> >
> > What do you think? Haven't had time to lab it yet.
> >
> > The two problems I can think of, first it only does outgoing packets,
> > thought that's where most of the problem is.
> >
> > The other is the cpu cycles the route map will use.
> >
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > McClure, Allen
> > Sent: Wednesday, October 02, 2002 1:11 PM
> > To: Ciscomonkey@aol.com
> > Cc: ccielab@groupstudy.com
> > Subject: RE: dealing with fastrack (Kazaa et.al.)
> >
> > You may wish to learn a little more about the subject before you
> > criticize... It's not that easy. It actively works around firewalls
> and
> > ACLs. That's why Cisco has NBAR support for it rather than just
> saying
> > "block this port".
> >
> > Allen McClure
> > MCSE, CCNP, CCDP
> > YUM! Brands, Inc.
> > Sr. Network Analyst
> > NEW E-Mail - mailto:allen.mcclure@yum.com
> > 972-338-7494
-- Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
This archive was generated by hypermail 2.1.4 : Tue Nov 05 2002 - 08:35:37 GMT-3