Here are some comments after reading your latest FR draft.
I understand from the WG meeting, that keep-alives are no longer needed
at the transport level, that removes several inconsistencies. I think
that you are proposing a decay of the rate following methods suggested
for decreasing the TCP window.
Gorry
---
Simulations are needed, and three of the issues I'd like to understand are:
1) What is the best time-constant used for decay of the max receive rate
allowed by FR? I think the case for the periods used in the draft to
maintain the window are not justified - either by need to cater for 30
minutes of idleness, nor the safety of this case. In my mind, this is
an issue that should be thought upon, since the longer the value the
more the "case" that this should be experimental. In my mind, I wonder
if much smaller periods would be acceptable for typical applications -
such as video-conference sessions (e.g. by thinking on different periods
of idleness)?
2) What is the effect when the max rate was close to the bottleneck
capacity (i.e. overshoot impact on other traffic)?
3) What is the effect when the max rate was calculated for a RTT that
has substantially increased (due to mobility), and do we need to
consider this?
---
Finally a procedural note: this was chartered as Experimental. That does
not mean it could not go forward as PS. Please could we be clear what
potential issues this raises (which may require experiments prior to
recommended deployment), and the scope of these experiments. Of course,
once these potential issues are identified, if they are not founded, it
would be great to re-consider this as a PS!
