[Iccrg] MulTFRC update: draft-irtf-iccrg-multfrc-01

Wed Aug 4 14:04:16 BST 2010

Here are some comments I had; none are very serious or really protocol-related, but are mostly just things that I thought would strengthen the document as an RFC.

Section 1
=========

- "not all data transfers are of equal importance to a user"; this would be more accurate as "the required delivery rates and times for all transfers are not all equal"

- between the first and second paragraphs, there's a sentence or so missing to indicate why using multiple actual flows is less desirable than a single transport flow that can emulate the congestion response of multiple actual flows.  To some extent this is in the 3rd paragraph, but it would make more sense to fully introduce the problem prior to the solution :).

- paragraph 4: "steady-state throughput of TCP" might better be "steady-state throughput of a TCP connection under the observed loss rate, RTT, and segment size.

- paragraph 4: "TFRC code" -> "TFRC pseudocode"

Section 2
=========

- section 2.1 has inconsistent spacing in the block of one-line assignments; to me, the "a = ..." form is more legible than the "af=..." form, and there's plenty of horizontal room in those lines.

- "maximum number of packets acknowledged" -> "maximum number of segments acknowledged"

- "the number of packets transmitted" -> "the number of data segments transmitted"

- I'm not sure if the suggested implementation data types for each variable should be mentioned; some are (N, x, af, a, z, q), and others aren't.  For instance, p is clearly a floating point number, but t_RTO might be understood as an integer since it's described only as "in seconds".

- section 2.4: "upon expiration of feedback timer" -> "upon expiration of the feedback timer"

- section 2.5: we should be careful about unqualified use of "obsolete" since that has a specific
meaning in the RFC series; I would add a qualifier and use a different wording here like:
"RFC 5348's Section 8.1 is therefore not relevant to the MulTFRC specification." rather than the
sentence that says "It is therefore obsolete."

Section 3
=========

- In reading section 3.1, it leaves the reader wondering "ok, so what was wrong with MulTCP?"
since it mentions that the N-TCP emulation is the key selling point rather than the smooth
rate.

Other Comments
==============

- instead of simply titling sections as e.g. "Section 3 of RFC 5348", I'd suggest also either giving some indication of the content of that section or the section title itself, just so this document is slightly more self-contained.

- since this will be an IRTF document (representing a research product), it would seem good to
me to identify at the end if there are any strings dangling for future research.  Some that I
saw hinted at in the document or though of are below.

Possible forward work:

- Changing N on the fly; note this may be relevant for any N-flow scheme.

- TFMCC (RFC 4654) also builds upon TFRC, though is geared for multicast applications.  As many multicast applications involve (potentially) high-rate media, it would make sense to consider the possibility of how MulTFRC and TFMCC relate (if at all), or if there is overlap in the potential user bases.  The "Mul" in MulTFRC could possible be confused for meaning multicast even, so it would be good to call out the relationship (or lack of).

- Quantifying the differences between N=1 in MulTFRC and using vanilla TFRC (apologies if this is already in the thesis).

--
Wes Eddy
MTI Systems

>-----Original Message-----
>From: iccrg-bounces at cs.ucl.ac.uk [mailto:iccrg-bounces at cs.ucl.ac.uk] On
>Behalf Of Michael Welzl
>Sent: Saturday, July 31, 2010 5:33 PM
>To: iccrg at cs.ucl.ac.uk list
>Subject: [Iccrg] MulTFRC update: draft-irtf-iccrg-multfrc-01
>
>Dear all,
>
>At yesterday's ICCRG meeting, I said that I would submit a minimal
>update of our draft
>immediately after the meeting (fixing minor syntactical issues). This
>update is now
>available:    http://www.ietf.org/id/draft-irtf-iccrg-multfrc-01.txt
>
>and here's the link to our MulTFRC website:
>http://heim.ifi.uio.no/~michawe/research/projects/multfrc/index.html
>
>My first presentation of this document to ICCRG is now exactly a year
>ago; we would
>therefore like to move ahead with this as soon as possible now. Thus,
>please provide
>any comments that you may have by the end of August, preferrably
>earlier.
>
>Thank you!
>
>Cheers,
>Michael
>
>
>_______________________________________________
>Iccrg mailing list
>Iccrg at cs.ucl.ac.uk
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg