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?"
---
<snip>
---
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.
* A sender that transmits at a high rate and remains dormant for many
hours and then wishes to return to a much higher rate.
In C.1, the draft mentions using the "receive rate before data limited
period", which I understand to be such history about the path, but I do
not yet see a method to implement this for a scenario where the rate was
once large, reduced some time back (may be several times) and is now
low. In this case, which previous receive rate is the one that would be
used (the highest ever, or some other rate)?
See the paragraph above. Appendix C.1 is a non -normative, general
description, not a detailed specification.
If the rate reduces gradually with respect to time, how would a "receive
rate before data limited period" be chosen?
(I saw a separate note from Arjuna after a long discussion with him on
possibilities for Congestion Window Validation for TFRC - and this may
be related, since if the history information decayed with respect to
time, albeit rather slowly, then this would probably also address this
concern).
Yes, I will answer Arjuna's note next - but that might not be until
tomorrow...
Take care, and thanks for the feedback.
- Sally
http://www.icir.org/floyd/
Best wishes,
Gorry
