Is that not an application of "ISP rotation" with random sending of packets possibly made of random byte parts? Portzamparc
2010/3/27 MtFBwU <[email protected]> > On a second thought, why don't we change the angle of this subject? > > Nowadays, dual ISP are pretty common. I may have a cable from Verizon > broadband and a wireless connection from AT&T at the same time. Now > suppose I want to run a bandwidth-demanding online service, > OnLive<http://www.onlive.com/> for example, let's say it requires a > 10mbps connection, my cable and my wireless each has only a 6mbps > connection. > > Can I *combine* the speed of these two connections as one so I can use > OnLive? > > I think it's a legit problem IETF need to address. If there are more > and more ISP and connection availability due to advance of technology, > people will always seek for a way to exploit a combination potential > of full bandwidth. > > Now, anti-censorship is only a by product of the protocol. We can > create a virtual ISP in a single ISP connection, but it's *hard* to > surveillance or censor. > > I mistakenly replied to Dave alone not to the list, sorry. So here's > what I previously said few days ago: > > > On Sat, Mar 20, 2010 at 11:27 AM, MtFBwU <[email protected]> wrote: > > Thanks for all the replies > >> Such a censorship system would be quite stupid. We would not even > >> need complicated protocols to workaround it, just using synonyms > >> or euphemisms would suffice. > > Haha, very true indeed. Now let me tell you a real story > > China blocked youtube right? First it does DNS tamper, so I setup a local > > DNS server, forward 8.8.8.8 using TCP would solve the problem. > > Then the Great Firewall (G.F.W.) do URL blocking, it concatenate the HOST > > header and the GET strings together then judge if your HTTP query is > > unwelcome. I have also discovered a way to bypass it, we can actually use > a > > double or multiple space after GET like > > GET / HTTP/1.1 > > HOST: www.youtube.com > > I can get partial return of HTML. Because sadly, the last block, DPI > checkes > > this string > > <title>YouTube - Broadcast Yourself.</title> > > It would RST you in the middle of a transport. So I can only load HTML up > to > > the title part > > So really, fighting against censorship is a two-way game. Yes we can > > use synonyms or euphemisms in domestic communications, we can do double > > thinking, but the real problem is we can not ask the other end like > youtube > > or google to change its fingerprints regularly and accordingly to > > each censorship. We have to and we can solve the problem in a lower > level, > > once and for all. > > > >> he resistance in Cuba uses USB thumb drives to transport > >> information. Looking at ways to improve the use of such drives is likely > to > >> produce a more effective counter-censorship scheme. > > You see, the G.F.W is in fact, under a lot of pressure. Evidence shows > that > > China use a massive cluster of Shuguang 4000L super computer farm to do > the > > censorship job, if we have a FEC-like protocol, along with multiple > > BitTorrent downloading sessions simultaneously open on each client, then > the > > censorship would not work properly. In the past we have encountered GFW > > failure from time to time, because it was during the evening where > Internet > > activity peaks in China. > > In this real-time web world, using USB thumb would be too slow for > important > > information spreading. :P > > > >> What "prior art" research have you done? What did you find, and why > > wasn't it suitable? What do you see as the already available building > > blocks, or concepts to extend? > > I am very sorry, I know IETF is a place where people discuss technical > > details, but currently I do not have that comprehensive knowledge to go > any > > futther. As a user, this thread is more like just a suggestion to you > guys, > > if there will be an important protocol to be designed for the future, > please > > consider making it to be intermediate node agnostic. > > On Sat, Mar 20, 2010 at 10:21 AM, Dave Aronson < > [email protected]> > > wrote: > >> > >> On Fri, Mar 19, 2010 at 09:59, MtFBwU <[email protected]> wrote: > >> > >> > I am an average Internet user from China. Sorry for my bad English. > >> > >> Actually, it seems fairly good to me. Anybody who can understand, let > >> alone come up with, a username like yours, obviously has a pretty good > >> grasp of it. :-) > >> > >> > In my opinion, theoretically, we *can* make the Internet uncensorable, > >> > >> In the large, it already essentially is. Find one tiny little > >> pinhole, through which to leak something to somewhere free, and it > >> cannot be erased from the net as a whole. (Note that said pinhole > >> need not be via the net! Leak it on paper in a bottle, and someone > >> might find it and post it to the net.) Anything from reports of > >> power-embarassing events, to the old goatse pix, are still available > >> SOMEwhere. > >> > >> > The TL;DR answer is FEC algorithms. > >> > >> Hmmm, interesting. I'm not an info-theory wonk, but at first blush, > >> late on a Friday evening, this sounds plausible, to me. As Stephane > >> points out, some of it is already popular. It sounds like you want to > >> combine the diverse routing of BitTorrent (and ToR?), with some > >> steganography ("debris nobody will notice", possibly in non-user > >> data), and FEC to account for the possibility of some data being > >> blocked or altered. > >> > >> What "prior art" research have you done? What did you find, and why > >> wasn't it suitable? What do you see as the already available building > >> blocks, or concepts to extend? > >> > >> -Dave > >> > >> -- > >> Dave Aronson - Have Pun, Will Babble | Work: davearonson.com | /\ ASCII > >> -------------------------------------+ Play: davearonson.net | \/ > Ribbon > >> "Specialization is for insects." | Life: dare2xl.com | /\ > Campaign > >> -Robert A. Heinlein | Wife: nasjleti.net | > Email<>Web > >> _______________________________________________ > >> Ietf mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/ietf > > > > > _______________________________________________ > Ietf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf >
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
