On Dec 3, 2007, at 5:34 AM, Gorry Fairhurst wrote:
Sally Floyd wrote:
Gorry -
---
Page 14
/because many implementations do not use delayed acknowledgements...
we
recommend b=1/
- I'd like to understand what this really means.
- 2581.bis says:
"The delayed ACK algorithm specified in [RFC1122] SHOULD be used by a
TCP receiver."
So is the 3448.bis draft saying a TFRC sender should be more
aggressive
than a 2581.bis TCP sender (because some TCP implementations are more
aggressive than 2581), or does it say that the TFRC sender is less
aggressive than a TCP sender that uses 2581?
It says that a TFRC sender can be more aggressive than a 2581.bis
TCP sender that doesn't use Appropriate Byte Counting (RFC3465),
and that follows the SHOULD about the delayed ACK algorithm.
(MANY TCP implementations ACK every packet, at least part of the
time.)
(And I forget if Appropriate Byte Counting is in 2581.bis or not.)
2581.bis currently says:
"While traditionally TCP
implementations have increased cwnd by precisely SMSS bytes upon
receipt of an ACK covering new data, we RECOMMEND that TCP
implementations increase cwnd, per:
cwnd += min (N, SMSS) (2)
where N is the number of previously unacknowledged bytes
acknowledged in the incoming ACK. This adjustment is part of
Appropriate Byte Counting [RFC3465]..."
.
So, I guess my question is:
"Is the working group comfortable with being more aggressive than the
standards-track TCP implementation?"
TFRC is *not* more aggressive than a TCP implementation that uses ABC.
TFRC with b=1 is roughly the same level of aggressive as TCP with ABC
(as recommended in RFC2581bis).
...
---
I note the current draft describes a "Congestion Window Validation"
like
approach as future work - which could be OK with me, if the standard
method that is described in 3448.bis addresses the issue below. At
the
moment, I can not tell if this is addressed.
I would be concerned if a 3448.bis sender could potentially inject a
very large volume of data into the network (up to the highest rate it
ever attained in ancient history, e.g. hours before), when the recent
rate (for many NFT intervals) was much lower. I think if the aim is
to
keep "history about the path", the period that this previous capacity
"state" needs to be bounded in time.
During a data-limited period, X_recv_set contains the largest X_recv
from the period including the data-limited period, and the two
round-trip
times before the data-limited period. This is specified in the
procedure
"Maximize X_recv_set" .
I need to think what this actually means, and may try to see you
face-to-face to make sure I understand what this is intended to do.
My two strawmen are:
* A sender with a varying send rate, that becomes data-limited and
then wishes to return to a much higher rate.
Without Congestion Window Validation, the sender gets to return to the
sending rate immediately before the data-limited period. (As TCP today,
without Congestion Window Validation, gets to use its old congestion
window after a data-limited period.)
The one-line change to add Congestion Window Validation behavior
to TFRC is shown in page 8 of the slides at:
"http://www.icir.org/floyd/talks/tfrcbis-dec07.pdf";.
I think this should be added to TFRC in a separate internet-draft, not
in
rfc3448bis.
* A sender that transmits at a high rate and remains dormant for many
hours and then wishes to return to a much higher rate.
A sender that is dormant has the NoFeedback Timer expire, and reduces
its allowed sending rate each time the timer expires.
...
Take care,
- Sally
http://www.icir.org/floyd/
