Search:  

 
 
   News
newer
story category Cox Scraps App-Specific Throttling Trials
May be waiting to see how FCC rules are defined...
06:23PM Thursday Oct 15 2009 by Karl Bode
tags: legal · fcc · business · bandwidth · cable · networking · net-neutrality · consumers · Cox HSI
Last year Comcast faced an FCC investigation and endless media scrutiny for their decision to use packet forgery to throttle upstream P2P for all users. Cox dodged much of that media attention despite the fact they were busy doing roughly the same thing. That's in part because nobody noticed what Cox was doing (well, almost anybody). But it's also because unlike Comcast, Cox didn't lie about what they were up to when asked about it.

Things of course have changed a lot since last year, with Comcast employing a new network management system that instead of throttling all P2P users, temporarily throttles only the highest consumption users on the most congested nodes. Cox too quietly backed off their upstream throttling and packet forgery approach, and instead began testing a network management system in Kansas and Arkansas that throttled only applications Cox somewhat arbitrarily declared to be "non-time sensitive" (like P2P or software updates).

We will continue to explore ways to manage occasional congestion on the network but will not conduct a market trial of any techniques without first updating these Congestion Management FAQs.
-Cox
Cox today updated their network congestion FAQ to indicate that they have concluded their application-specific throttling trial, and have decided not to implement the system nationally. No test results were shared.

"We’re conducting our final engineering analysis of the data gathered during the trial period," says the company. "We do not plan to further deploy this method at this time." "We will continue to explore ways to manage occasional congestion on the network but will not conduct a market trial of any techniques without first updating these Congestion Management FAQs."

Why isn't Cox moving forward with the trial? For one, network management hardware from companies like Sandvine is getting more sophisticated, allowing for specific congestion targeting that makes targeting by application a little like using a dull knife. Cox may also want to wait until the FCC finishes crafting their planned network neutrality rules before moving forward with any specific network management plan.

The FCC's new network neutrality push is primarily aimed at beefing up the FCC's legal authority in instances of extreme anti-competitive behavior, given Comcast's challenging the FCC's authority in court. Despite carrier fears, it's highly unlikely that the new rules will prohibit companies like Cox or Comcast from employing largely invisible throttling systems that specifically target extremely heavy users on heavily congested nodes.

It's far more likely that the rules won't look kindly upon throttling systems that target specific applications. Cox does employ caps for most of their tiers, though they aren't always enforced (aka "soft caps").

Related:
  1. The EFF 'Test Your ISP' Project
  2. Time Warner Cable: Let's Not Talk About Net Neutrality
  3. New Docs Show FCC Glossed Over BPL Flaws
  4. Cable Cooking Up New Network Management System
  5. Google Voice Ban Is Clear Network Neutrality Violation
  6. FCC: Please Define Broadband
  7. What Network Neutrality Is REALLY About
  8. Comcast Still Fighting FCC Throttling Sanction
Forums » Cox Scraps App-Specific Throttling Trials
view: topics flat text 
Post a:
robl27
Premium
join:2008-07-16
Mary Esther, FL

That's GOOD

Leave my packets alone, I got skype, vonage, and I watch online paranormal shows, I don't need my ISP telling me what's right for me.

They just issued a 256 Gig cap for premier users. I hope this isn't a step towards metered billing!

redxii
too big to fail
Premium,Mod
join:2001-02-26
Texas

Re: That's GOOD

Maybe it isn't the cap alone. Maybe it's the "5GB cap for the same price you're paying now, if you want more shell out the Benjamins!"
--
Peter Schiff for U.S. Senate.
iansltx

join:2007-02-19
Golden, CO
·Comcast
·Qwest.net
·magicjack.com
·BeeCreek Communica..
·Sprint Mobile Broa..

The throttling was application-specific, not provider-specific, and VoIP would be one of the aps prioritized, always. Which IMO is fine. It's not net neutral to the extreme, but it's net neutral "enough" when you have 160 Mbps of capacity serving 250+ users on a cable node.

Also, Cox has had caps for a LONG time. They actually raised them recently. Before, they were quite low, albeit soft.

Ikyuao
Pro. debian Linux

join:2007-02-26
Wichita, KS
·Cox HSI

Thanks for your desicion, but...

...I have no plans to make scraps anti-reset flag attack in TCP specific off from my Iptables firewall so I keep that way to protect my computer from TCP RST disruption packet attacks incoming in the direction.
--
Professional Linux environmental blows microsoft windows out of the water.
iansltx

join:2007-02-19
Golden, CO

Re: Thanks for your desicion, but...

Well, you're not hurting anything, though the anti-RST routine will just sit and spin now that Comcast and Cox have decided to stop crapping on your interwebz like that.

Ikyuao
Pro. debian Linux

join:2007-02-26
Wichita, KS
·Cox HSI


1 edit

Re: Thanks for your desicion, but...

I haven't hurt anything, I set up that way to designed the anti-TCP RST attack technique of iptables firewall to keep any of TCP RST packets incoming at bay of lid down in the black hole like dropping TCP RST packets down in the black limitless hole in there of full of darkness void so TCP RST packets incoming won't reach to my computer because iptables is doing to keep trash rubbish garbage worthless of TCP RST down in the darkness void hole so I get cleaner packets out of my local Iptables firewall after packets are in the wash machine hahaha lol.
--
Professional Linux environmental blows microsoft windows out of the water.

espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN

Re: Thanks for your desicion, but...

You're ignoring the fact that TCP RST packets have a valid function in standard TCP operations. Eventually you will run into scenarios where that will break applications.
k1ll3rdr4g0n

join:2005-03-19
Homer Glen, IL

Re: Thanks for your desicion, but...

said by espaeth See Profile :

You're ignoring the fact that TCP RST packets have a valid function in standard TCP operations. Eventually you will run into scenarios where that will break applications.
I agree, it is in the RFC for a reason.

Ikyuao
Pro. debian Linux

join:2007-02-26
Wichita, KS
·Cox HSI

Huh? that doesn't breaks any of applications so my iptables firewall is supposed be protecting the system from TCP RST attack packets by *forged packet creator hacker*
--
Professional Linux environmental blows microsoft windows out of the water.

espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
·voip.ms
·Vitelity VOIP
·Callcentric
·VoiceStick
·ViaTalk
·Comcast
·Embarq


1 edit

Re: Thanks for your desicion, but...

said by Ikyuao See Profile :

Huh? that doesn't breaks any of applications so my iptables firewall is supposed be protecting the system from TCP RST attack packets by *forged packet creator hacker*
But if you drop all TCP RST packets you are also blocking valid TCP RST packets. The RST packet exists for a reason, it serves a valid function in standard TCP transactions.

If you block all TCP RST packets, eventually you will run into situations where it will negatively affect applications.

Ikyuao
Pro. debian Linux

join:2007-02-26
Wichita, KS
·Cox HSI

Re: Thanks for your desicion, but...

does that means this valid TCP RST will disconnect my application from server if TCP have a good reason to send out a TCP RST packet to cut my connection off...? I only block all of TCP RST packets incoming. not outcoming direction of TCP RST blocked. it is only incoming direction that I blocked TCP RST packets. so there, it is not caused of applications be problems.
--
Professional Linux environmental blows microsoft windows out of the water.

espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
·voip.ms
·Vitelity VOIP
·Callcentric
·VoiceStick
·ViaTalk
·Comcast
·Embarq

Re: Thanks for your desicion, but...

If you block incoming TCP RST packets there are only 2 ways for a TCP session to close: a valid FIN/FIN-ACK sequence, or the session has to time out.

A common place where TCP RSTs are used is in applications that reside behind a load balancer. Say you go to a website that is balanced across a pool of servers, usually your session will have a sticky association to just one of the servers. If that back-end server you are associated with goes down, the load balancer handles that by resetting the TCP session and redirecting you to another server once you establish a new TCP connection.

If you block the incoming TCP reset your browser will still assume the connection is valid and that website will appear to be down until the TCP session eventually times out and you attempt to establish a new session.

This is just one case of many where TCP RSTs serve a valid function.

Ikyuao
Pro. debian Linux

join:2007-02-26
Wichita, KS
·Cox HSI

Re: Thanks for your desicion, but...

said by espaeth See Profile :

If you block incoming TCP RST packets there are only 2 ways for a TCP session to close: a valid FIN/FIN-ACK sequence, or the session has to time out.
That is exactly that I leaves only FIN and FIN/ACK sequence are allowed in the both directions of traffics.
--
Professional Linux environmental blows microsoft windows out of the water.

espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
·voip.ms
·Vitelity VOIP
·Callcentric
·VoiceStick
·ViaTalk
·Comcast
·Embarq

Re: Thanks for your desicion, but...

said by Ikyuao See Profile :

That is exactly that I leaves only FIN and FIN/ACK sequence are allowed in the both directions of traffics.
So you are operating your system in a way that contradicts the operation of TCP as described in RFC 793.

Eventually that is going to bite you. Standards are funny that way.

Ikyuao
Pro. debian Linux

join:2007-02-26
Wichita, KS
·Cox HSI

Re: Thanks for your desicion, but...

that is not gonna be happen to bite me at all so not either happening to the applications and applications of functions are fine and there is nothing wrong with applications in matters that i have no issues with applications, TCP RST is not used by the applications unless if there is no response of connection over TCP so user application browser may have to click on "reload" tab to send the TCP RST to the host server to disconnect the virtual circuit of TCP of server side but server side really can send out the TCP RST if there is connection problems but that isn't going to work that due the client side of iptables firewall swallows TCP RST packet in the hole till user have to do manually click reload tab button of browser to send out the TCP RST packet to server side to cut connection out.
--
Professional Linux environmental blows microsoft windows out of the water.

funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
If this is the same person, then I tried to explain this to him more than a year ago. He won't accept the explanation.

Oh well, he breaks it, he owns both pieces.

Ikyuao
Pro. debian Linux

join:2007-02-26
Wichita, KS
·Cox HSI

Re: Thanks for your desicion, but...

Breaks? what are you talking about? there's nothing wrong with TCP specific that is nature of flag bits of TCP specific so there is nothing do with applications, if administrator don't like to receiving the TCP RST flag bit packet inbound direction then administrator have right to block the TCP RST flag bit packet off of inbound completely and you don't know what are you talking about...
--
Professional Linux environmental blows microsoft windows out of the water.

funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
·Verizon Online DSL
·Skype

Re: Thanks for your desicion, but...

I agree. You have the right to break (as in cripple the functionality of) your network stack and leave a bunch of half-open TCP connections in your state table.

And I do indeed know what I'm talking about, and so does Espaeth.

I told you then, and I'm telling you know, screening out TCP RSTs does not avoid any problem and only harms you. YOU HAVE THE RIGHT. It doesn't harm me, so go right ahead. It's yours. Break it if you want to.
--
Robb Topolski -= funchords.com =- District of Columbia -- KJ7RL
Test your Broadband connection today! -- »measurementlab.net/

Ikyuao
Pro. debian Linux

join:2007-02-26
Wichita, KS
·Cox HSI

Re: Thanks for your desicion, but...

Again, I were telling that I'd blocked the TCP RST abuser packets INBOUND DIRECTION, NOT OUTBOUND DIRECTION of iptables firewall packet filter that way the iptable firewall operate that I designed that way to filtering TCP RST out of inbound direction but TCP RST is not filtered at outbound in firewall processing before going out of outbound direction that is nothing harms me at all. So screening TCP RST out can help, that bittorrent application won't be interrupted that where TCP RST is filtered out of inbound direction that is I don't have problem with that where TCP RST abuser is filtered out of inbound direction. TCP RST in RFC that were designed to disrupt the connection immediately or cut connection out immediately and unfortunate, abuser can take advantage of TCP RST to abuse the TCP RST flag bit set packet to forge it but I set it to filter TCP RST out for inbound only with iptable firewall that's it I have peace now and my internet performance were great of speeds.
--
Professional Linux environmental blows microsoft windows out of the water.
Forums » Cox Scraps App-Specific Throttling Trials


Friday, 27-Nov 22:19:56 Terms of Use | Privacy Policy | Hosting by www.nac.net - DSL,Hosting & Co-lo | feedback | contact
over 10 years online! © 1999-2009 dslreports.com.