Dear Dccp'ers:
I've read through the draft and have the some comments and questions.
I hope its not too late for the current ongoing WGLC on this document:
This is more of a comment, but It appears that the draft is really
about a version of TFRC where the packet size-can-vary-as-long-as-u-
dont-send-more-than-100pps, adding up to a maximum data rate of 1.2
Mbps. Although, TFRC-SP did come about due to the needs of VoIP apps
(some of which have small 20 byte packets) any applications that
sends packets of 1500 or smaller and can abide by the 10ms ipi rule
can use this mechanism - this distinction only matters (if at all)
as packets of 1000 or 1200 bytes are not really considered small in
the current Internet.
The draft is not clear on the when feedback is sent back in instances
where the loss intervals are at most 2RTTs and the loss event rate
is computed as K/N? For TFRC, once a packet is lost in a new RTT, the
loss event rate changes, feedback is sent immediately and the
remaining losses within that RTT are ignored. However for TFRC-SP,
each loss modifies the loss event rate, therefore, should feedback be
sent immediately and on every loss (since p changes with every loss)
or should it wait until the end of the RTT?
Is the packet size of TFRC-SP in tables 2 and 4 set to segment-size +
40? it seems +40 is only done for the 14 byte and 1460 byte segments?
and not the 536?
also page 10, should it be:
using a packet size s of 1500 bytes -> using a packet size s
of 1460 bytes
and page 18:
as a 1460-byte-packet TCP --> as a 1500-byte-packet TCP
page 19: that a TCP would use -> that a TCP flow would use
cheers,
ladan
