Hello christian, 1)
I do see TFRC-SP
being more aggressive if the packet rate is increased. TFRC-SP allows the
sending rate to be more than TFRC when small packets < 1500. So if we allow
higher packet rate, then TFRC-SP could be more aggressive. 2)
The TFRC algorithm
specifies that we can send from 1 to 4 packets in one RTT based on the packet
size..So if you are using small packets to achieve that sort of rate you
mentioned, you would have to transmit a minimum of 4 packets in one RTT..But if
there was loss, then you could send down to 1 packet every 64 seconds! So I
guess you can still scale down to 100 bps – but then only when there was
extreme congestion.. Arjuna From:
dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf Of Christian
Hoene Hello, in the context of the WG Codec, which is standardizing a
codec that might be capable of operating at very high bit rates and very high
frame rates, I have two questions regarding DCCP with TFRC-SP (RFC4828) 1)
Section 4.3 (“The TFRC-SP Min Interval”)
limits the packet rate to 100 Hz (=10ms). Actually, we are working with 2.5ms
frame sizes. Do you expect any problem if the packet rate is increased to 400
or higher Hz? 2)
Are there any minimal transmission rates that DCCP
TFRC-SP support? I read something in the Linux Kernel but I do not find it in
the RFCs… Actually, it would nice if DCCP scales down to 100 bit/s. It is
possible? Thank you very much for your help. With best regards, Christian Hoene |