Gorry -
(Sorry, just getting to your email from December 4...)
Here is the short summary of the email below:
* I added some text to RFC3448bis saying that the parameter
b=1 is consistent with RFC 3465bis.
* There is a short discussion below about the TFRC
equivalent of Congestion Window Validation (and the fact that
it isn't included in the current version of rfc3448bis).
The details are below...
On Dec 4, 2007, at 5:17 PM, Gorry Fairhurst wrote:
Sally Floyd wrote:
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).
The statement below from 3448.bis was my concern:
"Because many TCP implementations do not use
delayed acknowledgements, we recommend b = 1."
I see that 2581.bis recommends RFC3465 (eqtn2), to me this implies the
same behaviour as No ACK delay. That 2581.bis says this is correct is
sufficient for me, would you consider updating the text to cite this
instead?
Done.
---
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.)
Understood, but not yet happy. Let's discuss this.
As it is now, the TFRC sender's allowed sending rate is not reduced
by a data-limited period (as with TCP). But its allowed sending rate
*is* reduced by congestion events. So if a TFRC connection sees losses
as a result of returning to its old sending rate after a data-limited
period,
then its allowed sending rate will be reduced. And a TFRC sender
only gets to increase its allowed sending rate rather slowly after a
congestion event. So I don't think there are any congestion collapse
problems, or other dire problems, with allowing the TFRC sender
to follow TCP's lead of not requiring Congestion Window Validation.
Though I happen to like Congestion Window Validation, myself,
and would be perfectly happy if others wanted to see CWV-type
behavior added to rfc3448bis now, instead of waiting for more
exploration and a separate document...
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";.
That is: Multiple old entries in X_recv_set by 0.85.
Yep.
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.
OK, re-reading this, I see this, and I *am* happy with what is said in
4.4.
Great.
...
Take care,
- Sally
http://www.icir.org/floyd/
Best wishes,
Gorry
- Sally
http://www.icir.org/floyd/
