Sally - response to that last point is inline.
Sally Floyd wrote:
Gorry -
I've done a detailed read through this document, and it seems that
there are
several NiTs that were not caught during the WGLC, that should be fixed.
Issues that I would like to see considered or addressed in a new revision
are below.
Many thanks for the feedback. Most of the changes that you suggested
have now been made. Some specific comments are below. And I have
a question below about one of your suggestions.
...
3. TFRC-SP
* How could a sender determine an appropriate average sending size - an
average implies some history, is this history over the previous 4
periods.
The document now cites RFC3448bis, in a non-normative fashion, and says
that the average segment size SHOULD be calculated over at least the last
four loss intervals.
OK
* What happens if there is a sudden step-change in the packet size, does
this have any implications.
Section 6 discusses the use of TFRC-SP with applications that modify their
packet size in response to changes in the loss event rate, and says that
the
interactions between applications and the transport protocol in this
case will
have to be addressed in documents that are more application-specific.
For applications that vary their packet size for other reasons, RFC 4342
says the following:
CCID 3 implementations MAY check for applications that appear to be
manipulating the packet size inappropriately. For example, an
application might send small packets for a while, building up a fast
rate, then switch to large packets to take advantage of the fast
rate. (Preliminary simulations indicate that applications may not be
able to increase their overall transfer rates this way, so it is not
clear that this manipulation will occur in practice [V03].)
We haven't yet explored this for TFRC-SP. I would guess that the
restriction on the sending rate of at most one packet every 10 ms,
combined with the allowed sending rate explicitly in Bytes per second,
and the app's inability to know the packet-dropping or packet-marking
dynamics at the congested routers, would not leave the app with all that
much room for gaming the transport protocol by varying the packet size.
But, as I say, I haven't done any analysis or simulations.
This seems like a reasonable position to me (it would be good note
something in the draft).
* Please clarify text on the impact of a reduced TCP MSS (for example a
reduced MSS that could result from more widespread use of Path MTU
Discovery
over Paths with links that do not support an Ethernet-sized MTU). The
IPv6
Minimum MTU could mitigate this.
I am sorry, but I didn't understand this. You are talking about the impact
of TFRC-SP in environments where the TCP MSS would be less than 1460 bytes?
As I understand it, the design goal for TFRC-SP is to achieve the same
bandwidth in bps (as a TCP flow using packets of up to 1500 bytes. This
is under the assumption that the TCP MSS is 1460 bytes [Section 4.5].
So my question is what happens to the fairness with TCP, if the TCP MSS
is (much) less than 1460 bytes (some PPP links have a much smaller MTU,
that would force TCP to use a much smaller MSS) Would TFRC-SP be fair? -
I don't think so.
One of the use cases for TFRC-SP may be to offer CC on such
capacity-constrained links, does the draft comment on this somewhere,
and is this an issue that will need to be addressed before deployment?
...
7. Simulation
...
* I like the first 3 paragraphs of summary, and this clearly should be in
the main body of the document.
* IMHO, publishing specific ns2 simulation results in the body of a
standards-track RFC is not good practice. There may be precedents, but
the
approach of using protocol specs to publish data does not seem good -
it can
also make this data appear as authorative on the topic (whereas, I'd much
rather encourage more results by more people). If the intention is to
support the case and help illustrate the way this it is to be used,
which is
what it seems here, then I'd very much prefer the remainder of
section7 to
appear as an appendix providing the results to support the arguments.
Yep, done.
OK thanks.
Many thanks!
- Sally
http://www.icir.org/floyd/
Gorry
