how-to block ads
|
|
Uniqs:
829 |
Share Topic
 |
 |
|
|
iansltx
join:2007-02-19
Golden, CO
kudos:2 Reviews:
 ·Comcast
| uTP is GOOD! Seriously,
Small Scale: uTP's yielding characteristics mean that I can have BitTorrent on in the background and it not disrupt whatever I'm doing in the foreground
Large Scale: uTP's yielding characteristics mean that, if uTP is causing congestion on an ISP link, it throttles itself back gracefully, providing maximum speed while steering clear of collisions with other traffic
Opposition is acting just plain childish now.
Look at it this way:
You're standing in line. A person is in front of you. He notices you look like you're in a hurry and offers to switch places with you. Instead of accepting, you yell at him and tell him he's a burden to society and to get out of the line altogether or you'll call the cops.
Tell me how I'm erring here. UDP traffic is still counted in ISP data caps anyway, so why does it really matter?
Bottom line: uTP skirts around non-legit ISP throttling practices, yes, but it alleviates the concern that supposedly caused these tactics in the first place: flow control.
Really, if BitTorrent is proposing to self-inflict lower priority to its own traffic, with the result being better QoS on any connection in which BT is used...what's the fracking problem?!? | |
axus
join:2001-06-18
Washington, DC Reviews:
 ·Verizon Online DSL
| I'm a little skeptical, they'll have to prove it to me. How does uTP recognize that the network is dropping packets? I thought that UDP not having a built-in retransmit method meant that you never know for sure what happened to your packet... you just have to assume after a certain amount of time.
In the ideal case, UDP could use less bandwidth, but I imagine it would just increase utilization while being more efficient.
The worry in the Register article is that VoIP and games using UDP will no longer get their "free" QoS on the routers by using UDP. I don't know if they are full of baloney or not, because UDP is supposed to be unreliable. It seems plausible that increasing the UDP traffic could cause issues, but I'm thinking it's worth a try.
I know Bittorrent has been looking at making the BT protocol more efficient for ISPs, perhaps they've done some testing and this really is nicer? Only one way to find out; I'm glad that internet applications don't have to be approved by some committee before they are released. | |
 MattAll noise, no signal.Premium
join:2003-07-20
Jamestown, NC
kudos:12 | They have supposedly built a reliable transport mechanism on top of UDP. »forum.utorrent.com/viewtopic.php?id=49813
I don't understand what he means when he says "This UDP-based reliable transport is designed to minimize latency, but still maximize bandwidth when the latency is not excessive. We use this for communication between peers instead of TCP, if both sides support it." In addition, we use information from this transport, if active, to control the transfer rate of TCP connections.
So, is it using uTP for client control, but data transfer is still sent via standard TCP? Or they are using uTP for all BT communication, but they are controlling the entire transmit rate of the TCP/IP stack? I'm not clear and I'd have to see more information. | |
 funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:5 | said by Matt:I don't understand what he means when he says "This UDP-based reliable transport is designed to minimize latency, but still maximize bandwidth when the latency is not excessive. We use this for communication between peers instead of TCP, if both sides support it." In addition, we use information from this transport, if active, to control the transfer rate of TCP connections.So, is it using uTP for client control, but data transfer is still sent via standard TCP? Or they are using uTP for all BT communication, but they are controlling the entire transmit rate of the TCP/IP stack? I'm not clear and I'd have to see more information. Although it's not my paragraph, I'll say it a little clearer. Here's how I read it.
"This UDP-based reliable transport is designed to minimize latency, but still maximize bandwidth when the latency is not excessive. We will now use uTP for communication between peers instead of TCP, if both sides support it. If both sides do not support it, we still use information gained from the uTP transport, if active, to also control the transfer rate of standard TCP-based connections."
So, for Alpha-version to Alpha-version peer connections, file data and mesh overhead happens over UDP. Between Alpha-version to legacy peers, TCP will be used as it always was and UDP will be used as it always was. The legacy TCP connections will still benefit from the network condition information learned from the uTP connections, allowing uTorrent to dynamically raise and lower their throttles as conditions indicate.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
More features, more fun, Join BroadbandReports.com, it's free...
| |
MattAll noise, no signal.Premium
join:2003-07-20
Jamestown, NC
kudos:12 | said by funchords:said by Matt:I don't understand what he means when he says "This UDP-based reliable transport is designed to minimize latency, but still maximize bandwidth when the latency is not excessive. We use this for communication between peers instead of TCP, if both sides support it." In addition, we use information from this transport, if active, to control the transfer rate of TCP connections.So, is it using uTP for client control, but data transfer is still sent via standard TCP? Or they are using uTP for all BT communication, but they are controlling the entire transmit rate of the TCP/IP stack? I'm not clear and I'd have to see more information. Although it's not my paragraph, I'll say it a little clearer. Here's how I read it. "This UDP-based reliable transport is designed to minimize latency, but still maximize bandwidth when the latency is not excessive. We will now use uTP for communication between peers instead of TCP, if both sides support it. If both sides do not support it, we still use information gained from the uTP transport, if active, to also control the transfer rate of standard TCP-based connections."So, for Alpha-version to Alpha-version peer connections, file data and mesh overhead happens over UDP. Between Alpha-version to legacy peers, TCP will be used as it always was and UDP will be used as it always was. The legacy TCP connections will still benefit from the network condition information learned from the uTP connections, allowing uTorrent to dynamically raise and lower their throttles as conditions indicate. How is that going to benefit networks? It can't be a reliable transport without some sort of acknowledgment. So I'm not sure what the switch to TCP would do to allievate current issues.
Can you elaborate a bit on that? | |
funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:5
2 edits | said by Matt:How is that going to benefit networks? It can't be a reliable transport without some sort of acknowledgment. So I'm not sure what the switch to TCP would do to allievate current issues. Can you elaborate a bit on that? You mean the switch away from TCP, I think.
I don't know what method they've chosen, but it's possible that they're using the typical 16K block request boundary and after a series of successes, perhaps pipelining a series of 16K requests. Not receiving a piece is no big shakes, you can always ask again or ask another peer.
But, given that there is no error-testing until the piece is done (some torrent piece sizes go as big as 2MB or 4MB), I kinda doubt this was the tactic. So what they've probably done is to reproduce part or all of TCP's integrity checking in their UDP implementation.
Either way, a miss is a miss and a potential sign of congestion. So they can, at least, use the fact that a requested block never arrived as a sign -- but it gets even better. Because they're using UDP, the program itself can measure loss and latency and respond directly to congestion -- unlike TCP where the supervision is delegated to the network stack which responds to congestion -- any program using it can only infer what's going on.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
More features, more fun, Join BroadbandReports.com, it's free...
| |
MattAll noise, no signal.Premium
join:2003-07-20
Jamestown, NC
kudos:12 | I did mean switch to UDP.
I didn't consider using an unreliable delivery and then just doing a hash check sort of like they do now to verify the file and all the required parts are there.
I'm just not sure I buy into their "It'll make network management easier" bit, but I guess we'll see. | |
funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:5 | said by Matt:I'm just not sure I buy into their "It'll make network management easier" bit, but I guess we'll see. It makes it harder on the app, but a goal of uTP is to get rid of the problem where you can't surf, stream, or VOIP if you're torrenting unless you cut your upload speed so far back that you can't possibly overrun your broadband modem.
The clues for overrunning the modem are the same clues as overrunning any choking point in network. Since using uTP will give them direct view to loss and latency (unlike TCP, where they don't know if a retransmit was required). uTorrent can figure out quickly if it's a particular path that's congested or a common point (all paths), and react accordingly.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
More features, more fun, Join BroadbandReports.com, it's free...
| |
MattAll noise, no signal.Premium
join:2003-07-20
Jamestown, NC
kudos:12 | How can they not know if a re-transmit was required when using TCP? TCP uses acknowledgments after every packet sent or received, so if a packet was lost, the protocol stack would know immediately.
UDP doesn't require acknowledgments, so the protocol stack has no way of knowing if video was lost and no way to know if a retransmission is required. This is evidenced by warping players in an online video game, or stuttering audio/video in online streaming media. It's an unreliable (or unguaranteed) delivery mechanism, whereas TCP is reliable (or guaranteed).
So again, I don't see how simply switching to UDP doesn't anything but make the situation worse by requiring a torrent to have to send MORE data packets because once they overload the user's upstream and start dropping packets in favor of other traffic, all that data has to be re-sent.
»en.wikipedia.org/wiki/User_Datag···_and_UDP | | |
|
funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:5
2 edits | said by Matt:How can they not know if a re-transmit was required when using TCP? TCP uses acknowledgments after every packet sent or received, so if a packet was lost, the protocol stack would know immediately. Because TCP users (the programs) access TCP through a sockets interface. Basically the program opens a socket to an address and a port and sends/recvs data to it. All the details about whether or not a TCP retransmission is needed or a checksum fails is is left up to the network stack. As long as the socket hasn't terminated, it's working.
(The API can advise if a send function returns before all the data was queued, and the programmer has to deal with that by sending the rest of the data, so there are possible clues here for reactive processing, but BitTorrent already reactively avoids congested paths so it's not much help).
said by Matt:UDP doesn't require acknowledgments, so the protocol stack has no way of knowing if video was lost and no way to know if a retransmission is required. It has no way of knowing if you (the programmer) don't build in some kind of ACK/NAK or other scheme. And that's the thing -- with TCP, you don't have to do that yourself, TCP does it for you. With UDP, you have to handle this yourself.
But taking it out of the BitTorrent topic for a moment, why do you need TCP for something like viewing YouTube videos? If the network between YouTube and the viewer drops a packet, is it better to stop the flow and re-request the lost packet or is it better to skip the missed data and go on? I think it would be better to skip the missed data. TCP won't allow me to program that way, but UDP will.
Back to BitTorrent...
So again, I don't see how simply switching to UDP doesn't anything but make the situation worse by requiring a torrent to have to send MORE data packets because once they overload the user's upstream and start dropping packets in favor of other traffic, all that data has to be re-sent. First, it's not simply switching to UDP, they've also built in TCP-style acknowledgements and congestion control as well as preemptive control.
See this message from the developer: »www.ietf.org/mail-archive/web/le···076.html --- the presentation slides are »www3.ietf.org/proceedings/08nov/···at-4.pdf but they're probably cryptic without being in the room or knowing the 6-months worth of discussion that preceded it.
Second, overloading the user's upstream is the anti-goal or the thing to avoid (it's the Status Quo). uTP won't drop packets in favor of other traffic, it will hold it and avoid adding it to the outgoing queue.
Robb
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
More features, more fun, Join BroadbandReports.com, it's free...
| |
|
