uTP protocol support in Bit Comet

[SFD96]

I wonder if BitComet , my fav bt client since i dont even remember when , is able to communicate via uTP , as they claim this is the future of the entire bit torent sharing .

Some info found at uTorrent support page

µTP is a new lightweight BitTorrent protocol used by µTorrent starting in µTorrent version 2.0 - it makes incredibly efficient use of network bandwidth while reducing network problems.

1.µTP works to maximize network throughput while reducing network latency and congestion - it is designed to slow itself down when the network is overloaded (when sending and receiving would only make things worse!) - the result is a win-win of faster downloads for users with lower network impact for both users and ISPs

2.µTP is user-friendly within a home network, so one computer using µTorrent will not consume the whole network for itself

3.µTP is an open protocol in the process of being standardized - learn more about standardization of µTP on bittorrent.org and at the Internet Engineering Task Force (IETF)

4.µTP can get through most firewalls and NATs leading to far greater peer connectivity and faster download completion

[Vasy]

There's an article on Torrent Freak about KTorrent being the first to implement this protocol. This could earn us some attention. Both good and bad, mostly bad if you look at the banns on private trackers uTorrent now has for implementing this feature.

So if the devs like this idea it should be only an advanced option, disabled by default. The documentation can be found here.

Also, here's a quote from the utp thread in th Vuze forum, It made me laugh :lol: the arrogance I mean.

Ibslice

Posts: 1

Registered: 02/24/10

Re: uTP

Posted: Feb 23, 2010 9:06 PM <a href="http://forum.vuze.com/message.jspa?messageID=217474#217474" title="in response to: mmore1q3"> in response to: mmore1q3 Reply I put the suggestion to Firon (of uTorrent) of:

One thing many sites are discussing is a flag to turn the UTP part off - kind of like the flag to turn off DHT. Having such a flag and clients that respect that flag will make it more acceptable for every site and the way they wish to run their site.

his reply:

Firon that will never happen. that is completely unacceptable

Firon and it's complete nonsense to turn it off completely

The current problem with UTP is that it favours UTP:

examples:

For sites that are ratio driven it can be a problem for all those non UTP client users.

Also yes - if the swarm is high in NON UTP clients and there is only 1 or 2 UTP clients then those UTP clients will also suffer.

The big issue is UTP talks to UTP.

Even the UT DEV (ALUS) agreed with me but as he said.

Quote:

16:24 <alus> ok. if the network is still satisified, why does it matter who uploaded?

16:25 Ibslice because private sites members work on a ratio system for the majority of sites.

16:25 <alus> hm. I'm not sure the ratio system makes sense.

16:26 <alus> you're really trying to ensure a user will provide upload capacity when it is required of them, right

It peers better with itself than other clients so if there are multi users in the swarm on UT 2.0 then they get an advantage over the other clients. Especially if the initial seeder is also UT 2.0 - then the other UT 2.0 peers will get the torrent before the other clients do - creating an unfair advantage. The best fix is a complete swarm of UT 2.0 with no other non UTP clients. One of our site staff tested this:

"I created a max of 20 connections

and did 40 connections

20 instances of rtorrent

20 instances of utorrent 2.0

and on another box, a utorrent 2.0 seeder

NONE of the rtorrents connected to the 2.0 Seeder

and only ONE rtorrent slot could connect to the other 20 utorrentsi n the swarm

when I turned uTP off .. it was a pretty equal between the rtorrent and the utorrent

but with uTP on, the TCP connections didn't have a chance.

the other utorrent instances favoured each other greatly, though and 18 out of the 20 had 1 rtorrent peer with the other two having 2 rtorrent peers

which rtorrent was random

tcp .. equal spread across all of them

At least that is what my testing has shown."

also,

and this seems to agree with what I said.

waffles.fm wrote:

The downside to uTP is that outdated clients that don't support it will get lower priority when connections are made.

Many sites have banned uTorrent 2.0 and above because of how UTP plays unfairly with the non UTP clients. So my suggestion still stands - why not make it like DHT where sites can flag it on or off with the client respecting the private flag.

Also some more:

16:40 16:40 PM <v> Firon: it got a lot better on the 2.0 stable, but it's still not quite perfect

16:40 16:40 PM <v> Firon: it still sucks on high speed connections and there's a lot of other edge cases where it just doesn't do a very good job

16:41 16:41 PM <v> Firon: also, the utp implementation on 1.8 isn't very good, but there is some good news

16:41 16:41 PM <v> Firon: the plan is probably to turn on the new v2 header for utp (which is in 2.0 but not 1.8.5), so 1.8 users would no longer get utp connections

16:41 16:41 PM <v> Firon: with 2.0.1 or something

16:41 16:41 PM <v> Firon: once a majority of users have switched to 2.0

16:42 16:42 PM <v> Firon: and that'll just work better for everyone, since 1.8.x just handles utp pretty poorly.

Also 90% of sites have NOT banned Azureus like a couple of other sites have and have no intention of doing so (and in reality the ONLY reason Azureus was banned from those sites is because they cannot detect the modified cheat client versions) ..but implementation of UTP may change that.

Another chat with Alus:

00:33 <alus> so, feel free to put him in touch with me. we want to make sure uT 2.0 works for you guys.

00:34 <alus> and personally I want to see uTP get everywhere. it's just better for the internet

00:34 00:34 AM (Me)<q> ibs: well it might be better then

00:34 00:34 AM (Me)<q> ibs: but

00:35 00:35 AM (Me)<q> ibs: at the moment I think it is great for some swarms and detrimental to others - it really depends on the time of swarm it is getting into

00:36 <alus> can you give an example where it is bad?

00:36 00:36 AM (Me)<q> ibs: if you had 30 members all on UT 2.0 with UTP then 5 members on another non UTP client.. I think they would be pretty much pushed out.

00:36 00:36 AM (Me)<q> ibs: like bitomet used to do with agressive seeding tactics

00:36 00:36 AM (Me)<q> ibs: *bitcomet

00:37 <alus> you mean if the max connections for each client was something like 30? then they would all get connections to each other, is what you're thinking?

00:37 00:37 AM (Me)<q> ibs: yes as they would all get UTP preference as it would connect to those first

00:38 <alus> right. so, it's possible they would get all the connections first

00:38 00:38 AM (Me)<q> ibs: leaving the other clients a step behind

00:38 00:38 AM (Me)<q> ibs: which is great for UT 2.0

00:38 <alus> if that's bad for the swarm, then some clients would stall and the idle disconnect would kick in, allowing the other clients to step in

00:38 00:38 AM (Me)<q> ibs: but not so great for competing clients

00:38 00:38 AM (Me)<q> ibs: not if the speeds are travelling at 10mb/s and the file is done in 12 seconds

00:39 00:39 AM (Me)<q> ibs: 10 MB/s I mean

00:39 <alus> I see, so the other client wouldn't get the chance to seed anything

00:39 00:39 AM (Me)<q> ibs: correct

00:39 00:39 AM (Me)<q> ibs: or very little

00:39 <alus> hm.

00:40 00:40 AM (Me)<q> ibs: which is exaclt what bitcomet did

00:40 00:40 AM (Me)<q> ibs: and why it got banned on every private tracker under the sun

00:40 <alus> well, how did it do it?

00:40 00:40 AM (Me)<q> ibs: well it did it differently

00:40 00:40 AM (Me)<q> ibs: and was rather naughty

00:41 00:41 AM (Me)<q> ibs: sending d/c commands for part of it to non comet clients...lol - but the result was the same

00:42 <alus> right, obviously we wouldn't do that

00:42 <alus> that could even result in slower download speeds

00:43 <alus> it's hard to say that uT forming all of its connections very quickly is a bad thing...

00:43 <alus> what would be an acceptable solution here? leaving some % of the connections for TCP?

[Lucy26]

Other staff members in the forum have made the same suggestion, and the uTP protocol was added in the to-to list. Just this plan will take quite long to implement.

[kluelos]

uTp monitors the modem's queue. It has no way of knowing whether the network's congested or not, so any claim to ease network congestion is pure, untested blue-sky theory, the same kind of baseless claims we saw for "super-seeding" being faster.

uTP affects your bittorrent client only, not your other internet activity or the modem queue itself. That means that any packets which uTP holds back, your browser, file transfers, chat or email clients send instead. uTP can't slow THEM down.

uTP doesn't monitor the CONTENT of the queue, doesn't yield the right-of-way to those "more important" packets from your email or browser, and it doesn't ask THEM if they have anything to send first. Rather, uTP just keeps the queue filled up. This fails to achieve the design goal any more intelligently or interactively than the 80% limit popularly used.

Bottom line: there's no evidence that uTP does what it claims it does.

There IS evidence that it heavily favors other µtorrent clients and excludes all others.

This is how bittorrent.org describes utp:

uTP is a transport protocol layered on top of UDP

...

Like TCP, uTP uses window based congestion control. .... Any packet that has been sent, but not yet acked, is considered to be in-flight.

Right. One of the key differences between TCP and UDP is the absence of flow-control in UDP.

Under TCP, flow control means that every packet received is acknowledged. The acknowledgement, or "ACK", lets the sender know that the last packet was received, and that it's time to send the next packet.

If no ACK is received, the sender presumes that the packet got lost and sends it (the same packet) again. It's this very system that creates problems if you don't cap your upload speed: those ACKs get timed out, so your browser or email or whatever, looks like it stalled while the sender keeps resending the same packet over and over, waiting for an ACK.

OR to put it all this another way, under UDP, NO packet is EVER ack'd, that's a major difference between the two. The sender never knows whether the receiver got the last packet, or not.

Google "difference between TCP and UDP" and skim the first few articles that come up. I'll wait while you do.

Back now? Good. So now you can see that f you change the UDP protocol to send and wait for ACK's, you've done major surgery to the underlying protocol, and not something lightweight that rides on top of it. You've therefore done major surgery to the operating system software which implements it. This is not something I want a bittorrent client doing to my operating system, which is already unstable enough, thanks very much.

But let's also consider that we're no longer talking about a minor variant here, we're not "layering on top of" UDP -- we're making major changes, creating another protocol entirely.

This major change would be under the control of a single party -- µtorrent -- which, if you'll read the hidden transcript above, they consider changing at a whim, and they're happy to change it and cut off even previous versions of µtorrent. People who prefer to stick with version 1.85 of µtorrent will just be stuck, according to firion's vision. He can do that as easily to other clients. µtorrent doesn't believe in supporting ANY of their own previous versions, and have said so. If they won't support their own, they sure won't support yours. You'd have to change according to THEIR schedule and if you want to support previous versions, you'd have to develop that yourself. They aren't interested.

The protocol also does exactly what BitComet was falsely accused of doing -- heavily favoring current µtorrent clients and cutting anyone else off. See the hidden section of Vasy's message above.

Since uTP would represent a major balkanization of bittorrent, I hope it's never implemented by BitComet and ultimately rejected by the community. You should urge your favorite tracker to ban the client, as many already have.

[greywizard]

A few thoughts of my own (this is not a rant :D ).

1. kluelos, I think you're overreacting for no reason. By layering on top of UDP, the uTP protocol is not changing UDP anymore than DNS, DHCP, RTP/RTCP, RTSP and many other protocols that run on top of UDP are changing it. Basically, most streaming and "real-time" protocols (such as VoIP) run on top of UDP. Many network gaming protocols also layer on top of UDP. Heck, even TCP can run on top of UDP when it comes to it.

UDP is what's been called a "null protocol". It provides for OSI transport-layer addressing (a.k.a. port numbers) and thus multiplexing services for upper-level protocols/applications by using a source and a destination port fields. A length field and a checksum field is what follows in the header. And THAT IS ALL. 4 header fields amounting to a meager 8 bytes. The rest of the datagram is the PDU (i.e. the encapsulated data of the upper layer or what is called payload).

An uTP implementation does what all other protocols layering on top of UDP do, which is access programmatically the interface of the UDP software process in order to use UDP as a transport protocol or "carrier", if you wish, and relies on it for multiplexing and for talking to and passing the data to the the IP layer.

All the flow control functions are actually performed, in this case, at the higher application level (in the uTP process) which is completely transparent to UDP (it could carry uTP packets containing BitTorrent blocks or just as well an RTP stream containing the last clip of Pamela Anderson, for what it cares, it would be equally indifferent to it), since uTP is, as far as UDP is concerned, an application-layer protocol.

Nobody speaks of modifying the current TCP/IP stack software as far as I understand, which is Windows^TM by the way, but about using UDP as a transport protocol for uTP which will encapsulate at its turn BitTorrent traffic taking over the role of TCP in order to better manage flow control and consequently the network congestion WHICH IS CAUSED BY BITTORRENT TRAFFIC (I may be more or less wrong about whether BitTorrent protocol layers on top of uTP or not as the little I've read on the subject, was quite a while ago but the point I'm trying to make stays the same regardless).

uTP never pretended to be the universal panacea for network congestion, period, but only a solution for congestion caused by BitTorrent traffic as long as the clients producing that traffic implement it.

And lets face it, according to many, more or less accurate surveys and statistics, P2P traffic seems to account for more than half of Internet traffic nowadays (and I guess BT takes the lion's share of P2P).

2. I think everyone needs to differentiate between PROTOCOL SPECIFICATIONS and PROTOCOL IMPLEMENTATIONS. Since the specifications of the protocol have been made publicly available, I personally take that as a great sign of good faith and well-meant intentions.

I think everyone should analyze the protocol specifications closely and make their own decision on its usefulness based solely on that not on existing implementations.

No protocol implementation was ever perfect from the very beginning. Not even BitTorrent ones, which we so much praise these days in form of this or that client (and that for good reason). Since the only existent uTP implementation at present time (the one in uTorrent) is still in its childhood period, I reckon it should be granted some slack. We don't really like being demonized either, over that one short-lived version of BitComet that proved to have a bug which didn't respect the private flag.

I guess it's every tracker admin's right to ban a version of a client that doesn't behave well in one respect or another but on the other hand it's his/her moral duty to also check if any of the future versions did correct that issue and un-ban all the versions released latter than the corrected one, not necessarily assume that the developers are evil-meaning cyber-terrorists and ban their product forever.

Alas, many of them are too lazy or too little tech-savvy or simply too narrow-minded and easily biased to follow that path.

Let's not forget that this is the very mentality that still keeps BitComet banned on many trackers even today; I say we should not cultivate it but frown upon it, no matter which client it regards.

I take a different view and say that the move uTorrent devs had made by not supporting anymore v.1.8.5 is one to admire. They found out that v.1.8.5's implementation of uTP was flawed and they had the guts to acknowledge it and take positive measures even if they needed be a somewhat harsh, instead of denying it and burying their heads in the sand like many others do. I say, better cut out older version clients and let the protocol implementation evolve and improve.

That doesn't mean that they changed the protocol SPECIFICATIONS just THEIR own implementation of it!

And those very fond of v.1.8.5 can still use it the old fashioned way (i.e. layering BitTorrent on TCP by disabling uTP) as the rest of the BT scene still does without any fuss. Since the presence or lack of uTP is not affecting its ability to function as a BitTorrent client, I don't see it as such a major problem for the users of that version.

But to get back to the main idea, if anyone created at present time an implementation of the BitTorrent protocol (i.e. a BT client) which for whatever reason was more or less flawed or even crappy, you wouldn't blame that on BitTorrent specifications, right?

There are enough, hacked, modified, cheating BT clients out there; heck even MPAA/RIAA shills use ill-meaning modded implementations of BitTorrent and no one thinks of blaming Bram Cohen for that.

3. Nothing stops BitComet devs or any other client's for that matter to make a better, more stable and less flawed implementation of uTP, from the very first release. The gauntlet has been thrown down. The rules of the game are out there and I guess it's only a matter of deciding "if the juice it's worth the squeeze".

I haven't gotten to peruse the uTP specifications yet but I remember having read about it on uTorrent site a while ago and from the little I've read, it seemed interesting. As someone said, great things often start with good intentions. So if the goal of the protocol is as good as described and the algorithm is well designed, if not commending it (since I'm not familiar with it yet) at least I will keep an expectant stance towards it, for now. I will definitely try to make some time to read into the specifications.

As for the implementations, that's a somewhat different story. While possibly flawed in the beginning, they are subject to constant improvements in time, so I say there is nothing to worry about there, that much.

Just my two cents' worth.

[kluelos]

We all know, or will soon find out if it hasn't happened yet, that having piece boundaries that differ from file boundaries, can cause problems. BitComet created a simple and elegant system to solve that problem.

It was utterly rejected, not because it did not work, but because the "right people" didn't invent it. There is no reason to believe that an improved protocol, or one which actually does as claimed, would be accepted either. History suggests the contrary. uTP is under the sole control of one entity which can change it to the disadvantage of others, at will. There is no evidence that any changes, whether improvements or not, would be accepted from anybody. There is historical evidence that they will not be.

This protocol should not be accepted at all until that fundamental fact is changed, and BitComet should not be a party to implementing it to their own potential and very likely disadvantage.

I have looked at the protocol specification. It will not assist with network congestion in theory, and there's no evidence that it will work in fact. You cannot alleviate network congestion by monitoring the queue of a single modem. There is no theoretical basis showing how this will work. It's just a bloody guess that maybe, somehow, this might result in less congestion if enough people adopt it. Or maybe not.

This is an old song, we've heard before from the same parties, only last time it was all about super-seeding. Lacked evidence, lacked theoretical basis, turned out to be false, and never acknowledged as an error. This is just the second stanza.

We have two points, two things that we DO know:

1. There's no proof, or even persuasive evidence, that uTP will affect network congestion at all. There's no theory behind it, just guesswork.

2. There is evidence that it can be used to favor one client over all others. If that was evil when BitComet was accused of it, it's evil now. Adopting it would immediately divide bittorrent into the uTP's and the not-uTP's. This kind of balkanization is bad for everyone and needs to be fought and rejected at every point.

It's not up to me. BitComet bought into the half-open connection hysteria, and bought into super-seeding, both thoroughly debunked. It would be nice if BitComet didn't buy this latest myth.

[greywizard]

Well, you say that:

uTP is under the sole control of one entity which can change it to the disadvantage of others, at will.

But by following this reasoning path no one should have adopted and implemented the BitTorrent protocol, because it was under the control of a single entity (Bram Cohen) who could have changed it to the disadvantage of others, at will. I guess that like anybody else, the developers of uTP should be granted the benefit of the doubt, until proven the contrary. If you come to look closely at it, a lot of the open source implementations are based on good dose of common sense and good faith in the well-meaning intentions of the initial developers of the technologies. If anybody automatically assumed that a new technology has a hidden ill-meaning purpose, I think that the software landscape would be very different now (in a desolate way) and M$ and the the likes of it, would be even fatter and happier.

That's why I say that any decision should be made solely on the contents of the specifications.

There is no evidence that any changes, whether improvements or not, would be accepted from anybody. There is historical evidence that they will not be.

And why should BitComet care about that? Should the devs be the scary type who always sits in the corner and waits to see in which way most of the others lean, so that it can vote with the majority?

If the technology is good it should be embraced and implemented regardless of whether others have given it a shot or not. If not, it shouldn't be implemented anyway. At the end of the day, only time can prove if it will be the next great thing on the BitTorrent realm or just a dead end. But BitComet doesn't need to sit on its tail and play nice just trying step in the footprints of everybody else. It wasn't afraid to come up with new things before (such as DHT or PEX) and it shouldn't be now, it they decide it's worth the effort.

1. There's no proof, or even persuasive evidence, that uTP will affect network congestion at all. There's no theory behind it, just guesswork.

To this one I cannot add any informed comment since, as I said, I haven't perused yet the specifications of the protocol.

2. There is evidence that it can be used to favor one client over all others. If that was evil when BitComet was accused of it, it's evil now. Adopting it would immediately divide bittorrent into the uTP's and the not-uTP's. This kind of balkanization is bad for everyone and needs to be fought and rejected at every point.

I think you mistake protocol specifications with protocol implementation. One should not be judged on account of the other.

As I said, there is, just as well, clear evidence that BitTorrent protocol can be used to cheat or even hinder regular BitTorrent users. But nobody will accuse the original developer of the protocol and that for good reason; the protocol specifications are a tool that can be put to good or evil use, depending on who's wielding it. The same goes for this case.

Besides, I know that you're being bitterly ironical when you say: "If that was evil when BitComet was accused of it, it's evil now", but someone less witty may think you're actually meaning it. This would mean acknowledging that any of the BitComet devs were actually ill-meant when they wrote that version of BC which was bugged; we all know that was not the case.

And I don't think that's the case here, either. I don't believe that uTorrent devs knowingly tried to make uTorrent cheat in any way. It just bloody happens sometimes, when writing and modifying complex applications, that you can't cover all the angles and predict all the results, so things get occasionally more or less screwed up.

And then everybody jumps at you with torches and pitchforks as if you were the evil ogre, forgetting all the good work you've done in the past from which they benefited. It happened to BitComet before, it happens now with uTorrent. I don't think we should be among those carrying even as much as a torch; I certainly don't stand there.

I didn't like that it happened to BitComet and I don't like it now.

OTOH should that specific version of BitComet have been banned? Definitely yes.

Should the version(s) of uTorrent that doesn't/don't play fair be banned? That's a definitively yes, too.

But none of the clients or the devs should be demonized for that. Instead they should have been granted the benefit of the doubt and given time to correct the issue and come with a clean version, which plays fair with everybody.

Besides, one can always count on the large user community to sooner or later spot and weed out anything that willingly or inadvertently harms it in any way. Developers are, at the end of the day, compelled to follow the wishes of the user base they created.

This is just MY point of view. :)

I'm not arguing or anything and I'm not trying to impose it on anybody else; just presenting a different perspective on the matter.

[kluelos]

That's simply not true, Wizard.

First, Cohen immediately released bittorrent to the public domain.

Second, µtorrent has a history of rejecting anything "not invented here".

They've used up all the benefit of doubt they were entitled to, and then some. They could have decided to follow BitComet's lead on hiding padding files, to match file and piece boundaries. Instead they chose to call those files "spam" and complain about them. Why would anyone believe they'd treat any modification to uTP any differently?

µtorrent's people have demonstrated that they act in bad faith, and that they cannot be trusted. Firion invented and published stories about BitComet reporting incorrectly to trackers. They are not entitled to more presumptions of innocence, to another free bite at the apple. It's their own actions that have brought us to this situation, and they'll have to live with the consequences.

I say, do NOT look only at the specs, look also at the history of bad and evil motives of the people behind them. What's the first thing µtorrent did with it? Seize an advantage for µtorrent to the detriment of all other clients, EXACTLY what they've been (and continue!) screaming about BitComet doing. If BitComet adopted a technology that's under their sole control, it will simply give them more tools to continue doing that.

A monopoly on a single technology is a thing to be abhorred. BitComet should care because it is far too easily abused by people who've shown that they're happy to abuse it. BitComet should not embrace it or accept balkanization of the community. Instead they should reject it utterly. The community must maintain control of its future, not consign it to the whims of one company. That company has a policy and a history of simply abandoning earlier versions, of inadquately testing its products, then insisting that its customers upgrade to those products regardless of consequence. Such a company just cannot be trusted to exercise sole control over a technology.

Technology should never be judged solely on its own merits. It does not exist in a vacuum. It should be judged, like the rest of us, by its works. So far, that's 1) inconsequential and 2) evil.

uTP is a pointless dead end. If it really were the innocent new technology struggling to prove itself as you paint it, then it would start with a viable theory. It hasn't even got that. Then there'd be some lab evidence that the theory actually worked. It has just been spun into the next big thing, but it's all hype and no substance.

However, it CAN be used to divide the community so that one set of clients can't or won't communicate with the other. BitComet should never be willing to accept that.

We should instead remain the voice of reason and avoid getting pulled into this or allowing emotion to triumph over sense yet again. That's what happened with the half-open connection nonsense and with the so-called "super-seeding". For once, let's not get sucked in.

There are enough other things that need doing, too many to waste time implementing this foolishness.

[greywizard]

OK, let's talk facts.

You need to define what you mean by "releasing bittorrent to the public domain".

Because the specifications of the of the uTP are also publicly available. In the exact same place (among others).

If we consider http://www.bittorrent.org as being the central repository and homepage of the of the BitTorrent protocol specifications you can also find there the Index of BitTorrent Enhancement Proposals (or BEPs, as they are called).

On the page called The BitTorrent Enhancement Proposal Process under the section Intellectual Property and BitTorrent Standards you can clearly read:

"Any idea submitted in a BEP will not be considered for standardization if the idea is not in the public domain. Before a BEP can be considered Final, all people (including the BEP authors) or entities with a claim on the intellectual property expressed in a BEP must assign in writing all intellectual property expressed in the BEP to the public domain. If the BEP authors lack the power to assign intellectual property rights then they must disclose this fact before the BEP can be considered Final."

Also you can easily see there that there are at actual time only 2 BEPs which have reached the "accepted" status, as in becoming "official" (Extension for Peers to Send Metadata Files and Tracker Returns Compact Peer Lists).

ALL the rest of the BEPs are in the "draft" status (i.e. still ongoing discussion, testing, pending further improvements) and among them are many that are included since long in most major BitTorrent clients (such as DHT, Magnet Links, HTTP seeding, private torrents, BT extension protocol - which by the way has the same authors as uTP and which was ultimately implemented by most major clients, BitComet being among them - to enumerate just a few draft BEPs).

Lower in the list, if you look at BEP no.29, you will see the uTP entry.

So, as far as we're concerned, uTP is just as much public domain as BitTorrent is.

Now, you're aware that while Bram Cohen released the specifications of BT to the general public, he actually stayed one of the main brains behind the development of the project and the standardization of BT and its extensions. He is still called on the above mentioned site: "BDFL - a.k.a. Benevolent Dictator for Life".

He still has a say in the approving process for any of the BEPs that are submitted to be accepted for publication on the main site and which will be ongoing the standardization process. All these BEPs are subject to public discussions on the respective forums and while it stands to reason that the original authors and proposers will have the most important contributions, anybody can voice any concerns, complaints or flaws s/he finds in the specs and make them public and subject to discussion.

I can't see any difference between the process that is ongoing for any other of BitTorrent's proposed extensions and this one.

Furthermore, please note that among the designers of the uTP protocol specs there IS also Bram Cohen and another one happens to be one of the official BEP editors: Arvid Norberg.

Therefore, I don't see why this extension would be prone to benefit any different treatment from the staff behind BitTorrent.org than any other one from that list.

Also, please note that uTorrent has been acquired for quite a long time now (4 years) by BitTorrent Inc. which is responsible for updating the BitTorrent specs with the latest additions and which is basically Cohen's company.

That's why I say that this looks to me as an unjustified fear. How could anyone trust him on BitTorrent specs and all the other extensions on the site (many of which we are already happily using in any of the BitTorrent clients of your choice) but utterly distrust the guy and the rest of the BitTorrent.org staff, on this particular one, just because 2 uTorrent devs are among the authors (and they work for Cohen's company at the present time, by the way)?

In fact, from the authors only Greg Hazel (a.k.a. alus) is actually among the active developers of uTorrent, while ludde is only as a technical consultant (according to Wikipedia).

Firon, which you mentioned above, is in charge of the forums as far as I know, but I didn't find any info that he would be part of the dev team.

These, are some other reasons why I think that the main criterion in judging whether to implement or not uTP in BC should be the specs themselves and nothing else.

But, as I said this is just my personal opinion. Everyone should make up their own minds by examining the facts after putting their feet in ice-cooled water. :D

[kluelos]

If you do look at the specs themselves, then the first thing you should notice is this: There was no need for a new protocol, at all. None. Not even from their own public recommendation.

What's the idea? What is the basic notion behind all of this, that is supposed to make any difference? It is this: "monitor the modem's send queue. If it gets too full, then restrain the client from submitting any packets until the queue is emptied out."

That's it, that's the whole thing. Somewhere in there is a supposition that if you do it, what will result is less network congestion than exists now.

Now ask yourself why a new protocol is needed to do that? Isn't this monitoring and restraining process entirely internal, within the system itself?

There was a paper submitted to the Internet Engineering Task Force in October of 2009, which claimed that this wasn't good enough. (The paper's linked from µtorrent's web site in the developer section, as a deceptive attempt to demonstrate its openness. )

The paper notes that bittorrent interferes with bandwidth-intensive activities like gaming and, if not tuned, configured and restrained, with all other internet activity. Well, we knew all that, and we set a limit on the client's global upload speed for this very reason. It's an average value and a guess, but it works plenty well enough for most people.

What this paper proposed was that using a monitoring protocol -- watch how many packets are still on the way from sender to receiver -- and restrain the client based on that, it might ease network congestion. It called this protocol, "LEDBAT".

(µtorrent used this protocol exclusively in their failed and abandoned DNA project.)

Here's a cite from the last draft of that paper:

"Currently, no IETF standard transport specifies the use of LEDBAT, but all of TCP, DCCP, and SCTP could be adapted to use it."

There was no NEED for a new protocol. Study the proposal and you'll agree: all of this could have been done without a new and exclusive protocol. The IETF paper makes no mention at all of a new protocol. Quite the contrary, it says LEDBAT is entirely protocol-independent.

LEDBAT would certainly be easier to implement over existing protocol, so why go to all the trouble to create a new, incompatible protocol to implement it?

Because a new protocol implementation allows µtorrent to exclude all other clients from it, at their desire, simply by changing the implementation.

LEDBAT could have and should have been implemented over TCP, but then µtorrent wouldn't have exclusive control over it.

It's one thing to support LEDBAT, which at least makes a claim to an open standard. It's another entirely to support uTP, this completely unnecessary protocol implementation of LEDBAT, which is not. And make no mistake, LEDBAT was submitted to the IETF as an open standard, but uTP was NOT.

Here's the thing. A bittorrent client will interfere with your multiplayer online game, no question about that. They're competing for the same resource. If you restrain the bittorrent client your network doesn't suddenly become uncongested. Instead, the game takes over the resources that the client isn't using.

You've just substituted one sort of traffic for another. Net effect on network congestion? None. You failed to reduce network congestion. You didn't meet your stated goal.

What if there's less game traffic? Then the mechanism removes the restraint on the client.

LEDBAT has no mechanism for, and makes no attempt to implement its stated goal of reducing network congestion. It merely substitutes one sort of traffic for another so long as there IS other traffic. By adding its own new traffic, its own flow control, it actually adds to network traffic.

What it actually DOES with that flow control in terms of limiting client output, is every bit as much a guess as the Global Maximum Upload limit in your bittorrent client is.

We don't actually look at network congestion and reduce the system's overall generation of traffic - which is the obvious solution to network congestion. Instead we make a guess about limiting the bittorrent client's generation of traffic, which seems to work. That's exactly what uTP does with a great deal of fuss, hype and fanfare.

Well, is uTP better at it? The µtorrent site claims so and has the graphs to "prove" it.

They break down immediately. We want not to be lied to. Especially not stupidly lied to, but that's what we get:

The test sets up a µTP system and compares it, under the same conditions, with a standard client restrained to the recommended 80% of bandw....

uhh, wait.

They do the comparison with a client that was completely unconfigured. We know THAT is going to be worse and it's why we set the bleeding limit in the first place!

Duh! Just, f****** duh! What do they take us for, morons? What kind of test is that? The only thing these graphs prove is that uTP is better than an unconfigured client. Congratulations. I guess, on not being worse than nothing at all.

An honest test, an honest tester would not have to be told that this wasn't a reasonable, fruitful or honest test. That makes this a dishonest test, by dishonest testers, who insult our intelligence, then hype their product as some kind of breakthrough and this meaningless benchmark as proof. Instead of proof that it works even as well as what we've already had for years (tune your client), we get transparent doubletalk. Coming from µtorrent, that's somehow just not very surprising to me. They don't have to choose the dark side, but every single time, they have. Always check under the hood and make sure the tires are included, with these guys. Benefit of the doubt? Please!

If BitComet wants to support LEDBAT, should that technology actually prove out on IETF, that would be good. It might be worthwhile exploring a common implementation in TCP with Azureus. But BitComet should stay far away from supporting uTP under any circumstances.

ktorrent decided to support uTP, but it's giving them more than the usual number of fits. Something they did actually breaks their regular client under some circumstances that still aren't clear. Why would we want to buy into that, too?

[SFD96]

They told that uTP can bypass any of ISP restrictions or confuses like NAT networks , thats made me wonder becoz i was behind NAT and having one of the most fastest internet plans nowdays as the whole 100 Mbit , my upload rates was equal 0 kbs coz of NAT infrastructure . The fact it made me confused ( f***** up )

I cant see the future but i wish there will something new able to bypass any rules and laws and let ans download and seed anything we wanna :D

May the iNTERNET fORCE be with Us :D

[Vasy]

@SFD96 They were asked how, exactly, it does that, right? :huh: