how-to block ads
|
|
Share Topic
 |
 |
|
 IgnitePremium,VIP
join:2004-03-18
UK | reply to larytet
Re: Ellacoya quote:
btw why not to give this a try ?
i mean what are you afraid of ?
Well a few things really. Firstly CMTS isn't really intended to manage traffic of this nature, and if a load of users do this they'll DoS their own CMTS. Second what you propose is a SYN flood of ISP equipment, however little traffic it involves that's what it is. Thirdly custs doing this will render the upstreams they are on useless to any other users by using all the upstream transmit opportunities on the upstream MAP.
I work with CMTSes, they can NOT handle worst case traffic, they are built to handle the usual nature of traffic, mostly large concatenated transmissions with a very limited amount of this nature of traffic. A CMTS faced with a considerable proportion of subscribers doing this will grind to a halt. Pointless looking at the datasheet as this will vary depending on which NPE is in the box as well as which line cards, which modulation schemes, and any other CPU intensive tasks that may be running on the box such as SNMP monitoring, etc.
quote:
i never said that router/forwarder is good in traffic shaping, but it IS good in dropping packets according to simple rule like if IP port=6776 drop the packet ALWAYS.
I'm sure that this would really please subscribers, completely pointless apart from as protection against known trojan and exploit ports.
Maybe you should check out Thingamajig's post rather than trying to encourage subscribers of another ISP to attack the kit that is providing them access to the internet. It's heartening to see that the only thing your suggestion has met with so far is derision. Technically flawed, illegal and fundamentally stupid. 'Stress test' your own ISP, see how they appreciate it rather than encouraging users justifiably upset to do the experiment for you. | |
4 edits | Technically flawed, illegal and fundamentally stupid It is not illegal to open 2000 TCP connections. Actually i do it from time to time.
It is not technically flawed in my view. I do not accept your arguments about CMTS performance. You said right things about different issue. CMTS CPU handles normally only SNMP, ARP, DHCP. Main stream IP traffic (data) flaws without participation of CPU - there are dedicated ASIC/network processors, etc. Wirespeed performance is must for CMTS (some pizza boxes can be an exclusion). did you work with »www.arrisi.com/ ? i will appreciate any info/opinion related to their products.
My suggestion to create multiple dummy connections does NOT consume significant part of bandwidth and this is not SYN attack, because all connections are going to stay for long time, like days or even weeks.
The second alternative with NMAP (SYN port scan) is not what usually done. It is perfectly legal to connect to port 80 www.yahoo.com, keep connection opened for 5s and then close it. Actually FireFox Tab Autoreload does exactly this - you will need Tabbrowser Extensions from »texturizer.net/firefox/extensions/#tbe
My post was a suggestion, nothing more. I do not care what Shaw subsribers will do or will not do. After more than a couple of emails i decided to answer all questions using some public forum. "You asked what i think, You get it"
returning to Shaw and it's problems with providing reliable services with law latency, etc. I understand very well that VoIP, multiplayer games require QoS or eventually traffic shaping. I understand that cable is shared media and due to deficiencies. of DOCSIS experiences more troubles with handling upstream traffic (than, for example, SDSL).
I think you understand as well as me that UDP based P2P protocol not using TCP flow control can fill the upstream to the CMTS no matter what traffic shaper does (i would glad to hear any comments regarding this). Essentially it means installing of these devices only for the reason of providing QoS is wasting money.
It does not mean that there is no solution even in case of cable provider. DOCSIS 2.0 porvides native QoS and Voice Support. Probably Shaw decided that replacing CMTS's is more expensive than installing Ellacoya's. How many cable providers in the world reached the same conclusion ? Two ? Three ? Let's be honest here (see also »www.gigaom.com/2004/11/sbcs_voip_end_r.php)
Shaw wants to provide VoIP and Shaw wants their VoIP be better than any other and Shaw does not want to spend money. My humble opinion that there is no free meals.
Bottom line - installing of Ellacoya to throttle P2P is not that great idea as Shaw management probably believes. It looks great on the paper, but in reality they increase complexity of the network and consequently maintenance costs, latency, jitter.
have nice weekend.
P.S. Do you have HTML version of your resume »www.arap38.dsl.pipex.com/carlresume.doc ? I am not sure that Open Office rendered the file right. you can google my nickname to find my cv if you care.
P.S.1 i read the posts (most of the posts) in the link Thingamajig provided. i could not find the MP3 itself.
BitTorrent is sapping up to 90% of the backbone of Shaw Cache for the bittorrent traffic is relatively simple thing to do and probably cheaper than Ellacoya boxes. If Shaw worries about outward traffic they can keep all or most of the traffic (90%) inside of the network. Isn't it great to have satisfied and happy customers and do not have any traffic from other ISPs.
Another approach to the problem is to hire Mr. Cohen to develop embedded high performance BitTorrent client. I estimate $200K US R&D costs and $0.5M production. 5Tbytes of disks, 2GB RAM and Linux stripped for the bittorent application. I almost see the box already. I would call it btCache.
Think also about BT extension for FireFox (if it happens). If video blogs start to use P2P to deliver VoD than Shaw effectively will throttle legitimate traffic - access to the video servers. | |
IgnitePremium,VIP
join:2004-03-18
UK
2 edits | Here's a CMTS doing what a CMTS does (not one belonging to my current employer btw):
CPU utilization for five seconds: 77%/73%; one minute: 78%; five minutes: 78%
Throw a load more packets at the baby, force its' NPE to work harder processing them through access lists, managing the CEF for the packets, increase load on the line cards arranging the upstream MAPs and it all adds up.
IP Input and CEF both consume CPU.
How do you plan on keeping the TCP connections alive without sending a SYN as a keep alive? Doing this as many times as upstream will permit? Sounds a bit SYN flood like to me.
Unfortunately wirespeed performance isn't going to happen on a CMTS due to no CMTS being able to manage as much traffic on its' HFC side as it can on its' IP side. Depending on the NPE in the CMTS can be pretty badly short of wirespeed.
The NMAP scan you suggest confuses me. It's perfectly legal to connect to a website but having a load of users doing it at the same time is a bit scary.
quote:
I think you understand as well as me that UDP based P2P protocol not using TCP flow control can fill the upstream to the CMTS no matter what traffic shaper does (i would glad to hear any comments regarding this).
Absolutely right, having conducted experiments it maxed around the 165 datagram per second mark, although no P2P app that I'm aware of relies solely on UDP, or uses it for file transfer.
Regarding my resume, I had forgotten it was there and I'm afraid there isn't an HTML version at this time.
Regarding BT cache, P2P caches already exist and are deployed in the odd service provider network caching BT, Gnutella, FastTrack, WinMX and other protocols. | |
4 edits | CPU utilization for five seconds: 77%/73%; one minute: 78%; five minutes: 78% This is bad i have to tell you. this is really really bad. I would suggest to replace the box with something bigger or to investigate why this CPU consumption. What is the current packet rate in the system ?
How do you plan on keeping the TCP connections alive without sending a SYN as a keep alive? Doing this as many times as upstream will permit? Sounds a bit SYN flood like to me. The followinf is quote: RFC 1122 states that keepalive should not be enabled unless the application requests it. If enabled, the keepalive probe timer must be configurable with a default of not less than two hours. Keepalive should be set on a system-wide, not per-connection basis.
Unfortunately wirespeed performance isn't going to happen on a CMTS due to no CMTS being able to manage as much traffic on its' HFC side as it can on its' IP side. Yes, indeed. Though most have packet rate limiters at least in the upstream direction. But HFC interface can schedule the modems TX according to the available upstream (this is DOCSIS, right ?). Theoretically every modem has it's chance to send a packet. If this or that CMTS does not work like this and fails to fill backbone connection should we blame BT and install middle man ? i guess the answer is to find better systems. I understand that you like Cisco. You learned their MIBs, CLIs, etc. you know to configure them easy, you spent lot of time and effort to learn the equipment. its hard for you to imagine that there is something else (better ?) on the market. Shaw technicians are probably under pressure of the managemnet to deliver service which is not deliverable with the equipment in place unless everybody around plays according some strict rules, like 1 email/day between 9 and 11PM, 10 WEB pages every morning and one installation (download) a month (please use monday nights)
The NMAP scan you suggest confuses me. It's perfectly legal to connect to a website but having a load of users doing it at the same time is a bit scary. Forget word NMAP. I used it as an example how TCP connections can be established periodically. Firefox can do the same. TCP connection will stay alive as far as no peer sends disconnect and (optionally) peers send keep alive each other. In reality no data whatsoever flows across an idle TCP connection...This means we can start a client process that establishes a TCP connection with a server, and walk away for hours, days, weeks or months, and the connection remains up. Intermediate routers can crash and reboot, phone lines may go down and back up, but as long as neither host at the ends of the connection reboots, the connection remains established.. And in case of keepalive enabled we are talking about ~1 packet/min and not milliseconds and not even seconds. Actual keepalive timer depends on the TCP/IP implementation, but usually is not less than 30s. Run Azureus, up number of simultaneous connections to 200 and watch your firewall counters. Try 500, then 1000, then 2000 connections. Just this very morning i was watching 1000 leachers downloading the same file. I could establish and maintain simultaneuos connections to 300-350 of them with total bandwith under 20Kb/s.
Another interesting example is CNN.com. The page is rather heavy and not stripped out like Google. Every 5 minutes or so the page refreshes itself. It does not mean that Shaw is going to throttle traffic to CNN too. If Shaws network is not scalable this is a problem which can not be solved by traffic shaping. They can not put on top of it more services without more investment into the existing infrastructure.
although no P2P app that I'm aware of relies solely on UDP, or uses it for file transfer. I am developing one. You can try send LOOK request »larytet.sourceforge.net/btRat.shtml . In the current version it works really like DDoS - the application makes IP scan, but this is of course temporary phase. i make some research and this thing helps me. I am sorry that my project web site gets hits because of Ellacoya and not because of search engine, fast data transfer, built in version manager and other features.
Probably i do not make it clear enough. The idea behind my post was to prove to Shaw that this is pointless to use this approach (Ellacoya) to solve this specific problem (P2P). I have never thought that Shaw subscribers would start deliberately attack their own ISP, but the scenario is possible and Shaw has to think about it. There are places in the world where money can be used more efficiently. It does not mean that there is no application at all for Ellacoya box - actually there is.
P.S. from wikipedia »en.wikipedia.org/wiki/Stateful_firewall | | |
|
|
