On 3/19/07, Sally Floyd <sallyfloyd@xxxxxxx> wrote:
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: Old: Unlike CCID 3, the CCID 4 sender enforces a minimum interval of 10 ms between data packets, regardless of the allowed transmit rate. New: Unlike CCID 3, the CCID 4 sender enforces a minimum interval of 10 ms between data packets, regardless of the allowed transmit rate. If operating system scheduling granularity makes this impractical up to one additional packet MAY be sent per timeslice providing that no more than three packets are sent in any 30 ms interval.
> 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.
Understand. However remember VoIP will be more susceptible to this then other apps as it often employs silence supression. Perhaps in an RFC tracking section you can say that an implementor MAY track faster restart before an explicit update to the RFC? Ian -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group
