From: Michael Snyder (msnyder@revolutioncomputer.com)
Date: Wed Oct 02 2002 - 18:58:58 GMT-3
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
This archive was generated by hypermail 2.1.4 : Tue Nov 05 2002 - 08:35:37 GMT-3