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

[Michael Welzl]

Hi!

Thanks a lot for your extremely useful comments!

Note to the list:
I think it's safe to interpret this as another review recommending to  
proceeding with the mechanism (provided that these
rather minor issues are addressed, which should be easy enough, we  
will do that of course).

Cheers,
Michael


On Aug 4, 2010, at 3:04 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE  
CORP] wrote:

> 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