how-to block ads
|
funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
 ·Verizon Online DSL
 ·Skype
| reply to espaeth
Re: MORE! MORE! MORE!
said by espaeth  :Forging RSTs is only about as wrong as cutting in line. It's not a very nice thing to do and it tends to annoy other people in the line, it may violate the social contract but there are no civil or criminal implications. That's true of all of the RFCs. Enforcement is essentially the missing part.
I'm on the record as saying that the FCC should limit its rulemaking to enforcement of existing rules, it shouldn't put itself into the position of duplicating, adding to, or changing Internet Standards.
But even better would be to restore wholesale competition to Broadband (the crap going on with Bell Canada now, not withstanding).
said by espaeth :The RFC examples you love to quote refer to unintended consequences of RST injecting by firewalls on unknown header values. The Comcast deployment is a little more specific -- they know how P2P apps respond to TCP resets, it achieves the desired effect for them, and they appear to be taking reasonable measures to ensure that only their intended application target is affected. (not 100% obviously, but I'm sure they try to make it as close to perfect as possible) I love to quote the RFCs (those that are the authoritative "Internet Standards") because that's the instruction manual for developers and implementors.
And Comcast didn't know how all P2P apps would respond -- all P2P apps haven't been written yet. And their secret addition to RFC 793 wouldn't give developers the heads up as to why their apps were behaving unexpectedly.
And even for the ones that are out there, they did not get it right. Remember that I found this after two months of investigation as to why I couldn't upload anything via Gnutella -- 24 hours a day, 7 days a week -- 100% blocked.
Their Sandvine "solution" doesn't delay uploads, it blocks them. Comcast's stretched definition of "delay" only works when there multiple copies of all pieces outside of the Comcast.net domain. Comcast, being the 2nd largest ISP in the US, repeatedly prevented a lot of original content from being uploaded. They didn't delay it, they blocked it.
And, once discovered, I couldn't even report the problem to anyone at Comcast because Customer Support (truthfully) did not know it existed on their network. My CS notes would probably say "customer sees UFOs and Black Helicopters - ID10T."
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
FCC Public Hearing on the Future of the Internet - Thursday, April 17th - Stanford Univ., Calif. | |
espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
·voip.ms
·Vitelity VOIP
·Callcentric
·VoiceStick
·ViaTalk
 ·Comcast
·Embarq
| said by funchords :That's true of all of the RFCs. Enforcement is essentially the missing part. Actually, for the worthwhile RFCs the enforcement is quite effective. "Do it this way or your shit won't work"
said by funchords :I love to quote the RFCs (those that are the authoritative "Internet Standards") because that's the instruction manual for developers and implementors. There are actually a couple Internet standards bodies: the Internet Engineering Task Force (IETF, who picks and chooses certain RFCs to become standards) and the IEEE being the two largest orgs. The difference between RFCs and IEEE standards is like the difference between books and scientific journals. To publish in a scientific journal you need a certain level of detail, research, and peer review whereas any jackass of the street can write a book.
I'm not knocking RFCs, there's a lot of brilliant ideas published in RFC form, but you have to take them for what they are. Many of the proposals are purposefully left open-ended for interpretation; that's why SHOULD vs MUST becomes a huge point of distinction in many RFCs.
said by funchords :And Comcast didn't know how all P2P apps would respond -- all P2P apps haven't been written yet. If the app doesn't exist, how would Sandvine profile it to be able to take action on it? | |
funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
·Verizon Online DSL
·Skype
| Any jackass can write an RFC, but it won't make "Internet Standard" level until its been fully vetted.
If the app doesn't exist, how would Sandvine profile it to be able to take action on it? Sandvine attacked the application protocol, so it recognized all BitTorrent applications. However, how one BitTorrent app responds to RST's resulting Winsock error code might be completely different than how another responds. Some apps might try and reestablish contact right away, others might mark the peer as "bad" and blacklist it.
Sandvine's method doesn't (and probably cannot) recognize which app is actually being used to generate the protocol it is attacking, so therefore it cannot predict what the app will do in response to the RST unless that behavior is also described in the protocol. And for BitTorrent, Gnutella, or ED2K, it is not. (I don't know about the others.)
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
FCC Public Hearing on the Future of the Internet - Thursday, April 17th - Stanford Univ., Calif. | |
RARPSL
join:1999-12-08
Suffern, NY
| reply to espaeth
said by espaeth :I'm not knocking RFCs, there's a lot of brilliant ideas published in RFC form, but you have to take them for what they are. And then there are the RFCs that are issued dated April 1 such as 1149 (A Standard for the transmission of IP datagrams on avian carriers) issued in 1990. This one was actually implemented experimentally a few years ago and even had an enhancement RFC issued a few years ago where the datagrams were tunneled via commercial air planes to speed the transmission time. | |
Doctor Four
My other vehicle is a TARDIS
Premium
join:2000-09-05
Dallas, TX
 ·AT&T U-Verse
| reply to funchords
said by funchords :And even for the ones that are out there, they did not get it right. Remember that I found this after two months of investigation as to why I couldn't upload anything via Gnutella -- 24 hours a day, 7 days a week -- 100% blocked. Their Sandvine "solution" doesn't delay uploads, it blocks them. Comcast's stretched definition of "delay" only works when there multiple copies of all pieces outside of the Comcast.net domain. Comcast, being the 2nd largest ISP in the US, repeatedly prevented a lot of original content from being uploaded. They didn't delay it, they blocked it. I have seen what is most likely Sandvine equipment in
operation on Gnutella and WinMX, where it forces peer
connection resets as soon as someone enters my upload
queue. And sometimes I've seen these people keep trying,
maybe not knowing that they are disconnected in this
manner, thinking perhaps it is the person they are
downloading from that is disconnecting them.
--
"The trouble with computers, of course, is that they are very sophisticated idiots." - Doctor Who (from Robot)
| |
|
