Steve wrote:
Recent reports are that Comcast is killing torrents by using a packet
spoof to tell two connected clients that the other is requesting a
connection close.
In the news yesterday:
Consumer groups ask FCC to fine Comcast, stop it from hindering file sharing
See http://www.sltrib.
On Wed, Oct 24, 2007 at 10:54:53AM -0600, Steve wrote:
> Recent reports are that Comcast is killing torrents by using a packet
> spoof to tell two connected clients that the other is requesting a
> connection close.
Perhaps Comcast only kills connections that are swamping their
network. If so, the
On 10/25/07, Corey Edwards <[EMAIL PROTECTED]> wrote:
> If you're talking about consumer routers then you might be right, but big boy
> ISP routers won't drop your packets just because it's some unknown IP
> protocol. They don't care and they don't have the time to do inspection of
> that sort.
Th
On Thu, Oct 25, 2007 at 01:00:22PM -0600, Lonnie Olson wrote:
>
> How is this page unclear?
> http://www.qwest.com/residential/internet/other_isps.html To me, it is
> extremely clear.
All of their sales literature seems to quote prices that assume that you
also get telephone service from them. O
On Thu, 2007-10-25 at 13:13 -0500, Andrew McNabb wrote:
> Qwest can only offer their highest speed services in certain areas, and
> they refuse to be clear about pricing.
How is this page unclear?
http://www.qwest.com/residential/internet/other_isps.html
To me, it is extremely clear.
Personally,
On Thu, Oct 25, 2007 at 02:24:11PM -0400, Andrew Jorgensen wrote:
>
> I've read the RFCs for several protocols (including TCP). My
> assertion is that if you don't need all that complexity you can save a
> lot by not using it.
And you can break a lot by not using it.
Congestion Control is impor
On Thursday 25 October 2007 12:19:54 Andrew Jorgensen wrote:
> On 10/24/07, Lonnie Olson <[EMAIL PROTECTED]> wrote:
> > Right, using UDP as a base is a very bad idea. But writing your own
> > transport layer protocol is difficult. There are many applications that
> > don't do well on TCP, or UDP.
On 10/24/07, Levi Pearson <[EMAIL PROTECTED]> wrote:
> "Andrew Jorgensen" <[EMAIL PROTECTED]> writes:
>
> > As long as you don't do a significantly worse job than the authors
> > of TCP and you're not trying to implement all of the features of TCP
> > you will not have "slower downloads" than you w
On 10/24/07, Lonnie Olson <[EMAIL PROTECTED]> wrote:
> Right, using UDP as a base is a very bad idea. But writing your own
> transport layer protocol is difficult. There are many applications that
> don't do well on TCP, or UDP. Examine the progress of SCTP. It has
> many new features. Is it w
On Wed, Oct 24, 2007 at 05:11:04PM -0600, Lonnie Olson wrote:
>
> Remember the last-mile options are not always tied to ISPs.
> Last-mile options:
> Qwest DSL:
> Many ISPs to choose from
Qwest can only offer their highest speed services in certain areas, and
they refuse to be clear about p
Steve wrote:
It's like you're intentionally trying to miss my point here.
I feel the same way.
--Dave
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
It's like you're intentionally trying to miss my point here.
Maybe this is a communication problem, maybe I'm just exhausted and
not making myself clear.
I'll get a prototype up in the next couple of days and maybe it will
meet with approval, maybe it won't, but at least it'll show what I'm
talkin
Steve wrote:
I fail to see how using "send" vs "sendto" makes things much easier.
Come to think of it, if using UDP is so easy, I think I'll just "#define
send sendto" and move all my apps to UDP. I'm sure they'll be fine.
Let us know when the reference implementation is finished.
--Dave
On 10/24/07, Steve <[EMAIL PROTECTED]> wrote:
> I fail to see how using "send" vs "sendto" makes things much easier.
Then you don't know enough to know what you don't know. :) If you
want to pursue this futher, you should probably invest in a good book
like the one Levi mentioned.
-Jonathan
/*
I fail to see how using "send" vs "sendto" makes things much easier.
As far as I see TCP is like making a phone call.
UDP is more like sending a letter.
Neither is particularly hard each have their uses.
On 10/24/07, Dave Smith <[EMAIL PROTECTED]> wrote:
> Steve wrote:
> > Truth be told, protoco
Steve wrote:
Truth be told, protocol writing at the application level, should be
part and parcel with any good network enabled program.
Sure, unless you throw away the one thing that makes writing network
enabled programs easy: TCP.
--Dave
/*
PLUG: http://plug.org, #utah on irc.freenode.
Of course he's going to say that, he wrote Bittorrent and receives
royalties from the licensing of his protocol :)
Truth be told, protocol writing at the application level, should be
part and parcel with any good network enabled program.
Sincerely,
Steve
On 10/24/07, Joe Crown <[EMAIL PROTECTED
All I can say is go listen to Bram Cohen on his 2002 presentation at
code con. Basically he says that designing a new protocol is a major
pain in the butt. I'd have to listen to it again to give an exact quote.
Steve wrote:
Recent reports are that Comcast is killing torrents by using a packe
> Dave Smith wrote:
>> Steve wrote:
>> Yes anything using TCP would be vulnerable. So I'm saying for the
>> purposes of this file transfer protocol lets ditch TCP all together
>> and instead use UDP.
>
> ISPs can block UDP datagrams by port number with a single
> iptables rule. They could even do
I think you have two options. Find an ISP that will charge you by how much
bandwidth you use. Or try to hide your traffic in a VPN or encryption.
Anyboyd used "Mute"?
On 10/24/07, Steve <[EMAIL PROTECTED]> wrote:
>
> I digress, I'll keep developing the idea and see how this pans out.
> In the
"Andrew Jorgensen" <[EMAIL PROTECTED]> writes:
> As long as you don't do a significantly worse job than the authors
> of TCP and you're not trying to implement all of the features of TCP
> you will not have "slower downloads" than you would with TCP.
Assuming that you can do as good a job as the
I digress, I'll keep developing the idea and see how this pans out.
In the meantime, at least maybe I've raised awareness of this issue.
Sincerely,
Steve
On 10/24/07, Joshua Simpson <[EMAIL PROTECTED]> wrote:
> On 10/24/07, Dave Smith <[EMAIL PROTECTED]> wrote:
>
> > If your aim is to get around
On Wed, 2007-10-24 at 19:46 -0400, Andrew Jorgensen wrote:
> I'm NOT advocating a UDP P2P protocol but this is just plain wrong.
> To put it simply if TCP can do it so can you. TCP has a lot of bulk
> in it that you just don't need and there are definitely going to be
> better ways you can do thin
On 10/24/07, Dave Smith <[EMAIL PROTECTED]> wrote:
> If your aim is to get around an unscrupulous ISP, forget it. A new
> protocol ain't gonna fix that problem. Choosing a new ISP will.
I completely agree. The time spent on developing a new P2P protocol would
be more wisely spent on advocating
On Wed, 2007-10-24 at 17:28 -0600, Steve wrote:
> The whole point here is to make an attack like that impossible to pull
> off. Because if Comcast is doing it today,. other ISPs will do it
> soon as well.
My point was to say that developing a new p2p protocol on top of UDP to
get around a few ISP
Steve <[EMAIL PROTECTED]> writes:
>
> The whole point here is to make an attack like that impossible to pull
> off. Because if Comcast is doing it today,. other ISPs will do it
> soon as well.
>
If you have the option of choosing a non-Comcast ISP, you probably
also have the option to choose betw
Steve wrote:
Yes anything using TCP would be vulnerable. So I'm saying for the
purposes of this file transfer protocol lets ditch TCP all together
and instead use UDP.
You seem to be ignoring the elephant in the room, that is that ISPs can
break a UDP-based protocol just as easily as they
On 10/24/07, Lonnie Olson <[EMAIL PROTECTED]> wrote:
> The overhead of TCP really isn't that bad. Only 3 packets to start a
> connection. And an extra return packet for each packet sent.
We obviously have very different opinions of what bad overhead is.
> p2p apps wouldn't work very well on top
No I really haven't forgotten nor have I misunderstood the OSI model.
Yes anything using TCP would be vulnerable. So I'm saying for the
purposes of this file transfer protocol lets ditch TCP all together
and instead use UDP.
It's not UDP/TCP we are talking about implementing, it's UDP/IP which
i
On Wed, 2007-10-24 at 10:54 -0600, Steve wrote:
> Therefore I would like to propose that we create a new protocol which
> is not susceptible to man in the middle attacks, and is stable, safe,
> secure and reliable.
You are either forgetting or mis-understanding the OSI model which
details the laye
On Wed, 2007-10-24 at 15:44 -0600, Andrew McNabb wrote:
> The lack of choices is really depressing. In Sandy, the only choices
> are Comcast, Digis, and Qwest. I think Qwest is the only company worse
> than Comcast. In Provo, there should be choices, but iProvo is so
> poorly set up that you're
Thad Van Ry wrote:
> On 10/24/07, Dave Smith <[EMAIL PROTECTED]> wrote:
>> The only way to beat a bad ISP is to stop being their customer. No
>> protocol or technology can change that. Ditch Comcast. Get XMission. Be
>> happy.
>>
>
> Many of us would love to have that option. I can't get DSL, and
On 10/24/07, Dave Smith <[EMAIL PROTECTED]> wrote:
>
> The only way to beat a bad ISP is to stop being their customer. No
> protocol or technology can change that. Ditch Comcast. Get XMission. Be
> happy.
>
Many of us would love to have that option. I can't get DSL, and I'm not
about to go back to
Andrew McNabb wrote:
The lack of choices is really depressing. In Sandy, the only choices
are Comcast, Digis, and Qwest. I think Qwest is the only company worse
than Comcast. In Provo, there should be choices, but iProvo is so
poorly set up that you're stuck with Comcast or Qwest or the equall
On Wed, Oct 24, 2007 at 03:25:49PM -0600, Dave Smith wrote:
>
> The only way to beat a bad ISP is to stop being their customer. No
> protocol or technology can change that. Ditch Comcast. Get XMission.
> Be happy.
The lack of choices is really depressing. In Sandy, the only choices
are Comcast, D
Steve wrote:
However instead of using TCP, and a connection based protocol, it
should use UDP and a connectionless protocol.
A new protocol won't work. Instead of using a "tcpkill" approach,
Comcast will just try something else, like block UDP on those ports at
their firewall for clients w
Appearantly so yes...
http://www.consumersunion.org/blogs/hun/2007/04/now_that_you_mention_it_we_do.html
On 10/24/07, Michael L Torrie <[EMAIL PROTECTED]> wrote:
> Steve [-1 top post, -1 no trim] wrote:
> > Yeah they could, except that in many places Comcast is the only game
> > in town, and of co
Steve [-1 top post, -1 no trim] wrote:
> Yeah they could, except that in many places Comcast is the only game
> in town, and of course there is the little matter of contract
> termination fees.
Is this a recent thing? I've never heard of this. I've had comcrap for
several years, and they always
Yeah they could, except that in many places Comcast is the only game
in town, and of course there is the little matter of contract
termination fees.
On 10/24/07, Doran L. Barton <[EMAIL PROTECTED]> wrote:
> Not long ago, Steve proclaimed...
> > Recent reports are that Comcast is killing torrents b
Not long ago, Steve proclaimed...
> Recent reports are that Comcast is killing torrents by using a packet
> spoof to tell two connected clients that the other is requesting a
> connection close.
[...]
> Therefore I would like to propose that we create a new protocol which
> is not susceptible to
On Wed, Oct 24, 2007 at 11:16:46AM -0600, Hans Fugal wrote:
>
> Whoop, great way to kill all the internet. One of the biggest bandwidth
> users out there using UDP. Goodbye VOIP. Goodbye any goodwill ISPs had
> towards p2p.
This is a very important point. Congestion control is extremely
importan
On 10/24/07, Steve <[EMAIL PROTECTED]> wrote:
> TCP is overkill, we need neither guaranteed, nor reliable, nor ordered
> delivery.
> The request for bytes either comes back as a yes here's your bytes, or
> no sorry we don't have those bytes but we do have this list of bytes,
> or no sorry we don't
TCP is overkill, we need neither guaranteed, nor reliable, nor ordered delivery.
The request for bytes either comes back as a yes here's your bytes, or
no sorry we don't have those bytes but we do have this list of bytes,
or no sorry we don't have any bytes.
The bytes can come in any order, and th
Steve wrote [-1 top post, -1 no trim]:
> Well,
>
> One reason for using UDP, rather than TCP would be the simple fact
> that TCP has significantly more overhead than UDP. That overheads
> costs bytes, by removing that overhead we perform the same function
> with a fairly good savings on bandwidth
Well,
One reason for using UDP, rather than TCP would be the simple fact
that TCP has significantly more overhead than UDP. That overheads
costs bytes, by removing that overhead we perform the same function
with a fairly good savings on bandwidth.
Per packet signing is the only way I can think o
> Also instead of a tracker which can be taken down, I propose a query
> request method using a globally unique identifier, based on some sort
> of file signature algorithm. So essentially you query a list of known
> hosts for each file, if they don't have it they query all the hosts
> they know
On Wed, 24 Oct 2007 at 10:54 -0600, Steve wrote:
> However instead of using TCP, and a connection based protocol, it
> should use UDP and a connectionless protocol.
Whoop, great way to kill all the internet. One of the biggest bandwidth
users out there using UDP. Goodbye VOIP. Goodbye any goodwill
Recent reports are that Comcast is killing torrents by using a packet
spoof to tell two connected clients that the other is requesting a
connection close.
Not only is this evil, it seems to me that a man in the middle attack
should be something the designer should account for when designing a
prot
48 matches
Mail list logo
