Wows!!! The email was dated in 1969. This is really old email. Some of us were probably were not born when it was composed. :-)
An -----Original Message----- From: Gorry Fairhurst [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 31, 1969 8:17 PM To: Eddie Kohler; Sally Floyd; [email protected] Subject: [dccp] Feedback on draft-ietf-dccp-tfrc-voip-05.txt 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.
