Changeset 11161
- Timestamp:
- 06/23/09 14:07:51 (9 months ago)
- Files:
-
- 1 modified
-
dotorg/trunk/html/beps/bep_0029.rst (modified) (9 diffs)
Legend:
- Unmodified
- Added
- Removed
-
dotorg/trunk/html/beps/bep_0029.rst
r11159 r11161 39 39 40 40 The traditional solution to this problem is to cap the upload rate 41 of the bittorrent client to 80% of the uplink capacity. 80% leaves41 of the BitTorrent client to 80% of the up-link capacity. 80% leaves 42 42 some head room for interactive traffic. 43 43 44 44 The main drawbacks with this solution are: 45 45 46 1. The user needs to configure his/her bittorrent client, it won't46 1. The user needs to configure his/her BitTorrent client, it won't 47 47 work out-of-the-box. 48 48 2. The user needs to know his/her internet connection's upload … … 50 50 may connect to a large number of different networks. 51 51 3. The headroom of 20% is arbitrary and wastes bandwidth. Whenever 52 there is no interactive traffic competing with bittorrent, the52 there is no interactive traffic competing with BitTorrent, the 53 53 extra 20% are wasted. Whenever there is competing interactive 54 54 traffic, it cannot use more than 20% of the capacity. … … 130 130 ....... 131 131 132 This is the prot col version. The current version is 1.132 This is the protocol version. The current version is 1. 133 133 134 134 connection_id … … 145 145 This is the 'seconds' and 'microseconds' parts of the timestamp of when this 146 146 packet was sent. This is set using gettimeofday() on posix and QueryPerformanceTimer() 147 on windows. The higher res ultion this timstamp has, the better.147 on windows. The higher resolution this timestamp has, the better. 148 148 149 149 timestamp_difference_microseconds … … 210 210 a packet that has not yet been received. 211 211 212 The bitmask has reverse byte order. The first byte represents packets [ack_nr + 2,212 The bitmask has reverse byte order. The first byte represents packets [ack_nr + 2, 213 213 ack_nr + 2 + 7] in reverse order. The least significant bit in the byte represents 214 214 ack_nr + 2, the most significant bit in the byte represents ack_nr + 2 + 7. The … … 264 264 The sequence number is initialized to 1. The connection ID is initialized 265 265 to a random number. The syn packet is special, all subsequent packets sent 266 on this connection (except for re sends of the ST_SYN) are sent with the266 on this connection (except for re-sends of the ST_SYN) are sent with the 267 267 connection ID + 1. The connection ID is what the other end is expected to 268 268 use in its responses. … … 348 348 In order to have as little impact as possible on slow congested links, uTP adjusts 349 349 its packet size down to as small as 150 bytes per packet. Using packets that small 350 has the benefit of not clogging up a slow up link, with long serialization delay.350 has the benefit of not clogging up a slow up-link, with long serialization delay. 351 351 The cost of using packets that small is that the overhead from the packet headers 352 352 become significant. At high rates, large packet sizes are used, at slow rates, … … 373 373 original sender of the packet (timestamp_difference_microseconds). This value is not meaningful 374 374 as an absolute value. The clocks in the machines are most likely not synchronized, 375 especially not down to mic orsecond resolution, and the time the packet is in transit is375 especially not down to microsecond resolution, and the time the packet is in transit is 376 376 also included in the difference of these timestamps. However, the value is useful in 377 377 comparison to previous values. 378 378 379 379 Each socket keeps a sliding minimum of the lowest value for the last two minutes. This value 380 is called *base_delay*, and is used as a baseline, the min umum delay between the hosts.380 is called *base_delay*, and is used as a baseline, the minimum delay between the hosts. 381 381 When subtracting the base_delay from the timestamp difference in each packet you get a 382 382 measurement of the current buffering delay on the socket. This measurement is called *our_delay*. … … 384 384 decrease the send window (which controls the send rate). 385 385 386 The *CCONTROL_TARGET* is the buffering delay that the uTP accepts on the up link. Currently the386 The *CCONTROL_TARGET* is the buffering delay that the uTP accepts on the up-link. Currently the 387 387 delay target is set to 100 ms. *off_target* is how far the actual measured delay is from the 388 388 target delay (calculated from CCONTROL_TARGET - our_delay).
