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.
Thanks. Done.
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.
If a DCCP sender is generally going to be able to send packets
infrequently, say, with something like 100 ms between packets because
of OS timeslices, then I don't think the sender should be preparing
small data packets and sending ten or so small packets every time
it gets a timeslice. It would make more sense, in this case, for
the sender to be sending larger packets, less frequently (since it
already has the larger end-to-end delay of waiting 100 ms, sometimes,
to send small packets).
However, that said, I agree that we do need to add some text about
sometimes sending two or three small packets at once, because of
the constraints of OS timing. But I don't want to say that
the sender gets to routinely send 50 small packets back-to-back -
that wouldn't make sense to me.
Suggestions on language?
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.
I agree, but I don't necessarily want to hold up this document
for faster restart. I think that faster restart has to proceed
at its own pace.
Many thanks for the feedback!
- Sally
http://www.icir.org/floyd/
