07748
64295
07748
The access portion of the network is the focus of this problem statement. The user typically subscribes to a service with bidirectional [Internet] access partly described by rates in bits per second.
Parameter | Default | Tested Range or Values | Expected Safe Range (not entirely tested, other
values |
---|---|---|---|
FT, feedback time interval | 50 msec | 20 msec, 50 msec, 100 msec | 20 msec <= FT <= 250 msec; larger values may slow the rate increase and fail to find the max |
Feedback message timeout (stop test) | L*FT, L=20 (1 sec with FT=50 msec) | L=100 with FT=50 msec (5 sec) | 0.5 sec <= L*FT <= 30 sec; upper limit for very unreliable test paths only |
Load packet timeout (stop test) | 1 sec | 5 sec | 0.250-30 sec; upper limit for very unreliable test paths only |
Table index 0 | 0.5 Mbps | 0.5 Mbps | When testing <= 10 Gbps |
Table index 1 | 1 Mbps | 1 Mbps | When testing <= 10 Gbps |
Table index (step) size | 1 Mbps | 1 Mbps <= rate <= 1 Gbps | Same as tested |
Table index (step) size, rate > 1 Gbps | 100 Mbps | 1 Gbps <= rate <= 10 Gbps | Same as tested |
Table index (step) size, rate > 10 Gbps | 1 Gbps | Untested | >10 Gbps |
ss, UDP payload size, bytes | None | <=1222 | Recommend max at largest value that avoids fragmentation; using a payload size that is too small might result in unexpected Sender limitations |
cc, burst count | None | 1 <= cc <= 100 | Same as tested. Vary cc as needed to create the desired maximum sending rate. Sender buffer size may limit cc in the implementation |
tt, burst interval | 100 microsec | 100 microsec, 1 msec | Available range of "tick" values (HZ param) |
Low delay range threshold | 30 msec | 5 msec, 30 msec | Same as tested |
High delay range threshold | 90 msec | 10 msec, 90 msec | Same as tested |
Sequence error threshold | 10 | 0, 1, 5, 10, 100 | Same as tested |
Consecutive errored status report threshold | 3 | 2, 3, 4, 5 | Use values >1 to avoid misinterpreting transient loss |
Fast mode increase, in table index steps | 10 | 10 | 2 <= steps <= 30 |
Fast mode decrease, in table index steps | 3 * Fast mode increase | 3 * Fast mode increase | Same as tested |
Phase | Number of Flows | Maximum IP-Layer Capacity (Mbps) | Loss Ratio | RTT min (msec) | RTT max (msec) |
---|---|---|---|---|---|
Search | 1 | 967.31 | 0.0002 | 30 | 58 |
Verify | 1 | 966.00 | 0.0000 | 30 | 38 |
Phase | Flow Number or Aggregate | stn (sec) | Sender Bit Rate (Mbps) |
---|---|---|---|
Search | 1 | 0.00 | 345 |
Search | 2 | 0.00 | 289 |
Search | Agg | 0.00 | 634 |
Search | 1 | 0.05 | 499 |
Search | ... | 0.05 | ... |
Internet paths can have widely varying characteristics, ... Consequently, applications that may be used on the InternetMUST NOT make assumptions about specific path characteristics. TheyMUST instead use mechanisms that let them operate safely under very different path conditions. Typically, this requires conservatively probing the current conditions of the Internet path they communicate over to establish a transmission behavior that it can sustain and that is reasonably fair to other traffic sharing the path.
Latency samplesMUST NOT be derived from ambiguous transactions. The canonical example is in a protocol that retransmits data, but subsequently cannot determine which copy is being acknowledged.
When a latency estimate is used to arm a timer that provides loss detection -- with or without retransmission -- expiry of the timerMUST be interpreted as an indication of congestion in the network, causing the sending rate to be adapted to a safe conservative rate ...
To determine an appropriate UDP payload size, applicationsMUST subtract the size of the IP header (which includes any IPv4 optional headers or IPv6 extension headers) as well as the length of the UDP header (8 bytes) from the PMTU size.
Applications that do require reliable message deliveryMUST implement an appropriate mechanism themselves.
Applications that require ordered deliveryMUST reestablish datagram ordering themselves.
A congestion control [algorithm] designed for UDPSHOULD respond as quickly as possible when it experiences congestion, and itSHOULD take into account both the loss rate and the response time when choosing a new rate.
The implemented congestion control schemeSHOULD result in bandwidth (capacity) use that is comparable to that of TCP within an order of magnitude, so that it does not starve other flows sharing a common bottleneck.
Yes? | Recommendation in RFC 8085 | Section |
---|---|---|
Yes |
|
|
NA |
|
|
Yes |
|
|
NA |
|
|
For bulk transfers, |
|
|
NA |
|
|
NA | else, |
|
For non-bulk transfers, |
|
|
NA |
|
|
NA | else, |
|
NA |
|
|
Yes |
|
|
NA |
|
|
Yes | For DiffServ, |
|
Yes | For QoS-enabled paths, |
|
Yes |
|
|
NA | non-CC controlled flows |
|
Yes |
|
|
For tunnels carrying IP traffic, |
|
|
NA |
|
|
NA |
|
|
For non-IP tunnels or rate not determined by traffic, |
|
|
NA |
|
|
NA |
|
|
Yes |
|
|
Yes |
|
|
NA | Specific application mechanisms are |
|
Yes |
|
|
NA |
|
|
Yes |
|
|
Yes |
|
|
NA |
|
|
else, |
|
|
NA |
|
|
NA |
|
|
Yes | Applications specified for use in limited use (or controlled environments) |
|
NA | Bulk-multicast apps |
|
NA | Low volume multicast apps |
|
NA | Multicast apps |
|
Yes |
|
|
Yes |
|
|
NA |
|
|
Yes |
|
|
NA |
|
|
07748
64295
07748