On 3/7/07, Sally Floyd <sallyfloyd@xxxxxxx> wrote:
The internet-draft "Profile for DCCP Congestion Control ID 4: the Small-Packet Variant of TFRC Congestion Control", aka CCID 4, is available from "http://www.ietf.org/internet-drafts/draft-floyd-dccp-ccid4-00.txt";
Looks good. A few comments. Comments: Section 5: Because CCID 4 is intended for applications that send small packets, the allowed transmit rate derived from the TCP throughput equation is reduced by a factor that accounts for packet header size, as specified in Section 4.2 of [TFRC-SP]. The header size on data packets is estimated as 32 bytes (20 bytes for the IP header, and 12 bytes for the DCCP-Data header with 24-bit sequence numbers). If the DCCP sender is sending N-byte data packets, the allowed transmit rate is reduced by N/(N+32). CCID 4 senders are limited to this fair rate. Should this be changed for 48 bit sequence numbers as this seems to be the default in implementations and with a note about if 24 bit sequence numbers are used. Section 5: Unlike CCID 3, the CCID 4 sender enforces a minimum interval of 10 ms between data packets, regardless of the allowed transmit rate. I think we need clarification here. Are we saying on average we should maintain a minimum interval of 10 ms. Think of an OS where timeslices 100 times a second (not uncommon). Now DCCP CCID4 might get time at (referencing from 0) 1, 11, 20, 33, 41. Should we be able to send each time slice (I think so) or do we say at 20 and 41 we can't because not 10 msec? Maybe we should say not more than an average of 10 milliseconds over some time frame (500 milliseconds ??) when actively transmitting. Section 5.1: 5.1. Response to Idle and Application-limited Periods This is described in Section 5.1 of [RFC4342]. I think we should consider faster restart here. Regards, Ian -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group
