UPDATE 5: Craig Newmark still refuses to acknowledge his bug. All he has to do is correct his TCP settings and the whole problem goes away. Why won’t he?

I’m not sure… but reading some of the issues Craigslist is having related to it’s own firewall (see their system status page) I think they may be waiting on a vendor fix as well

A zero window simply means that the client will need to recieve an ACK from $server after every attempt to communicate with $server. The result is an incredibly slow TCP conversation that requires additional overhead (chatty) communication that may exceed timeout thresholds of higher level protocols (E.g. HTTP) There is no rule against the client continuing the conversation with a server advertising a 0 Window. It just needs more ACKnowledgements from the server before requesting additional data.

From what I’ve read, Authentium’s Achillies Heel is that it doesn’t respond correctly on subsequent packets when it is asked increase the window size.

This is only a problem when dealing with systems that don’t properly negotiate window sizes in the first place, and it’s not just an Authentium problem.. Many stateful firewalls (especially hostbased ones) only use the window sizes negotiated during the 3 way handshake, especially for stateless protocols like HTTP.

Craiglist’s webserver appears to only boost the window after the 3 way handshake occurs. I’ve just confirmed that myself via tcpdump.

A lot of these arguments are taking the form that Craigslist is a fault because “they were the last one who could avoid the accident.”

I disagree. Craigslist is the only people in charge of what Windows their hardware/servers are advertising, and since running a 24/7 web infrastructure requires technically more clue than installing and operating a host based firewall, it seems that Craig’s list could easily resolve all of the various problems they have with *MANY* firewalls (See their system status page for details) by fixing things on their end.

So the bottom line is this: Authentium has fixed its bug, but Craig hasn’t fixed his. Craig is still complaining about “discrimination” and Authentium is being gracious and taking full responsibility for the whole issue, even Craig’s part.

And meanwhile, the Save The Internet/Kosola Krowd are still saying this is proof that we need harsh regulations against ISPs.

Cox Cable delivers Craig’s List’s packets to its customers computers just fine, so the problem can’t remotely be attributed to malice on the part of Cox.

Craig Newmark has no credibility.

And why, PBC, do you keep pushing at Cox, when the easy solution to the entire problem is for the Craigslist people to fix their broken window size?

You argument seems to take the form that Cox is at fault because they’re not Craigslist. (And what “competing service” do they have? I mean, seriously? Nobody, figuratively speaking, has ever even heard of this service, which means it’s not competing at all, as the only strength of something like Craigslist is that many people use it.

Hell, their website doesn’t even mention such a service. The idea that they’re somehow deliberately preventing a fix from going out to bolster their own competitor to Craigslist is… I don’t even have words for what that is.)

BTW: the popularity of a website is no excuse for having it violate basic protocol behaviour… that arguement sounds suspiciously Microsoft-esque.

There is no question that everyone should follow the RFCs as closely as possible. Have you read RFC793? Authentium has, and their response was:

Our firewall driver responds by sending data only one byte at a time, even after the server increases the TCP window size. This is the glitch we have fixed and are QA testing.

I’ve read RFC793, and I’m not sure Craigslist is technically outside the specification, its just bad practice, unless its being used as a “cue” to send a 1-octet packet, which is what Authentium assumes it is. So, strictly speaking, Authentium is broken in that it responds with a single octet when none was allowed.

From what I’ve read, Authentium’s Achillies Heel is that it doesn’t respond correctly on subsequent packets when it is asked increase the window size. How this has been characterized as Craigslist’s sole problem speaks more to the desire to deflect this issue than to comment on good protocol practice.

A lot of these arguments are taking the form that Craigslist is a fault because “they were the last one who could avoid the accident.”

So I’d say they’ve done that already. The duopoly boosters are talking out of both sides of their mouthes. They are simultaneously arguing that the blame lays squarely with Craigslist and that Cox is fixing it.

Not exactly. Offering customers advice on installing a beta doesn’t mean that the beta is fully supported by Cox, what Cox is offering is a “hack” or “work around” to a problem outside of their control. It’s a common problem, but I don’t go screaming to my congressman about it.

From a technical perspective, the blame and *correct* solution to the *problem* (Technically defined as Hosts violating RFCs) is to have Craigslist fix their content director/loadbalancer or server to be less RFC ignorant.

If the #27 website can’t get Cox to act when its undoubtely being on its best behavior even though it is not compelled, one can only imagine the range of possibilities when the restrictions expire everywhere.

BTW: the popularity of a website is no excuse for having it violate basic protocol behaviour… that arguement sounds suspiciously Microsoft-esque.

Since when does Craig’s list get to offload it’s technical support duties for it’s users onto third party telcos or ISPs?

One of the claims being made by Lippard in this thread, is that one of the solutions offered to Cox users was to

install the free beta that addresses the problem.

So I’d say they’ve done that already. The duopoly boosters are talking out of both sides of their mouthes. They are simultaneously arguing that the blame lays squarely with Craigslist and that Cox is fixing it.

Actually, it was probably the users who wanted to get to Craiglist who offloaded their concerns onto their telcos and ISPs regarding a third-party site they believed they were paying to access.

Be careful with this line of argument, because it undercuts the “power of the marketplace” line being peddled as a reason we net neutrality supporters are trying to fix a problem that doesn’t exist.

If the #27 website can’t get Cox to act when its undoubtely being on its best behavior even though it is not compelled, one can only imagine the range of possibilities when the restrictions expire everywhere.