I have just finished reading the latest rev of 3448.bis. I have only a
few questions. I think this is a good sign, and look forward to your
response and the presentation in the DCCP meeting.
Best wishes,
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?
---
Page 48
/receives reports a receive rate/
^
- this should be /received/
---
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.
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)?
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).
