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.
Best wishes,
Gorry
---
Abstract
* Please define "Min Interval" - or write in full in abstract.
2. Introduction:
* 1st para: The abstract states this is ³experimental², but the word does
not appear in the opening sentence of the introduction. Can you modify this
opening sentence to reflect this.
/This document specifies... a variant of ... RFC3448/
* 1st para: Please ensure introduction correctly motivates what is meant by
"small packet" - this still needs more clarity, can you say explicitly what
happens if a medium/large packet size is used with this algorithm? (i.e.
behaviour will follow that of TCP/TFRC with the rate-limited defined by
TFRC-SP - specifically please say if this is expected to be safe.
---
/consequences for the rate a /
/consequences for the rate that a /
^^^^
---
* Define "Min Interval" when first used in Introduction.
* Define Bps (Bytes per Second) when first used.
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.
* What happens if there is a sudden step-change in the packet size, does
this have any implications.
* 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.
* The "H" parameter text is very IPv4-centric, please ensure this paragraph
also includes an IPv6 example - to assure the reader that this also works
for IPv6. Please also make a clear recommendation whether IPv6 should use a
H of 40 or 60 bytes. I think section 4.1 says use 40B by default??
4.1 Response Functions
---
What is $4R$ - 4xRTT?
/RTO of $4R$/
^^^^
---
The following sentence seems very odd in the body of the document. I would
have preferred to have seen a citation of a reference at this point to the
external document/web-site in the informative references.
/The calculations for table 1..../
----
* Table 1,2,3,4 are useful, but they are not quite integrated in the text,
specific things that would be helpful are:
* Table 1,2,3,4: Insert "p" in the packet Drop rate (to tie-in with the
equation).
* Table 1,2,3,4: Insert "s" with the segment size (to tie-in with the
equation).
* Add a cpation to tables 2 and 4 that says: "Maximum Sending Rate of 100
Packets per Second."
* /exactly as desired/ - A rather bold statement, I think this needs to be
explained in clearer language.
* Paras following table: Add a sentence explaining that Table 2 shows the
effect of the 100 pps rate limit, which is 5.4 kBps, 53.6 kBps, and 150 kBps
respectively for segment sizes of 14B, 536B, and 1460B.
----
/usinsg/using/
---
4.2 Accounting for H
* para 2 - This seems to imply DCCP has a smaller header size than UDP,
which is not so, please rephrase.
* para 2 - It would be nice to clarify "seems sufficient" - I think this is
"seems sufficient for both IPv4 and IPv6" in the absence of more detailed
information on the actual header size used.
7. Simulation
---
/TFRC-PS/TFRC-SP/
---
* 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.
* In the simulation results:
/as routers are advised to drop rather than mark packets during high levels
of congestion/
Please cite the RFC at the end of the para before Table 8 to say where the
"advice" to routers comes from.
----
8. Discussion
---
/insure/ensure/ ??
---
* The English seems poor and vague at the end of the paragraph:
/has not made a big difference/ /We haven't used TCP with ECN, because our
judgment... / etc to the end of the paragraph. I think these last 2
sentences of this para needs to be written.
* Please be clear about the impact on the fairness over links where
there is use of several layers of network-layer tunnels (e.g. IPsec, GRE),
that could increase the IP packet size above that seen by the sender. Is an
increase of 20,40,60B significant?
9. Security consideration
* It would be good to identify the increased header added by IPsec here, and
point to the relevent section (especially if you may expect TFRC-SP to know
about the additional header overhead).
10. CONCLUSION
---
/. but/, but/
^
---
/TFRC-PS/TFRC-SP/
---
Appendix A
* This concludes rather oddly that /We will report on these investigations
on a separate document/ - please remove this last sentence.
