Ladan -
Many thanks for the feedback.
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.
Yep. Some discussion of the use of TFRC-SP with apps with different
packet sizes has been
added to the draft.
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?
Good question! Feedback should be sent when the loss is first
detected, and every
succeeding RTT. I added a section to the draft discussing this, and it
is appended to
the end of this email. Feedback would be welcome.
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?
+40 is done for all three packet sizes. The scripts are
available at:
"http://www.icir.org/tfrc/voipsims.html";.
I also fixed the use of "packet" and "segment", in the places where I
had been careless.
Many thanks!
- Sally
http://www.icir.org/floyd/
4.6. Dynamics of the Calculated Loss Interval Length
For a TFRC-SP receiver, the guidelines from Section 6 of RFC 3448
govern when the receiver should send feedback messages. In
particular, from [RFC3448], "a feedback packet should ... be sent
whenever a new loss event is detected without waiting for the end of
an RTT". In addition, feedback packets are sent at least once per
RTT.
We note that in a connection with a short loss interval (less that
two round-trip times) and multiple packet losses per loss interval,
the loss interval length reported after a loss event is first
detected can be quite different from the loss interval length
reported for that interval one round-trip time later, after all of
the losses in that loss interval have been detected. When the TFRC-
SP receiver detects a loss event and sends a feedback packet, the
receiver might initially know only about the first packet lost or
marked in that loss event. If the current short loss interval
consists of N packets, including one lost packet, then the loss
interval length is calculated as N packets. If, in the worst case,
the TFRC-SP receiver subsequently learns of K-1 more lost or marked
packets in that loss interval, and no more packets are received
unmarked, then the final loss interval length calculated by the
TFRC-SP receiver for the short loss interval is (N+K-1)/K packets.
As an example, if K=N, then the first feedback packet will report a
loss interval length of N packets, while the second feedback packet
will report a loss interval length of just under two packets.
We note that in the examples above, TFRC-SP differs from TFRC in the
second feedback packet, not in the first one. When there are
multiple packets dropped in a single short loss interval, TFRC-SP
uses the multiple packet drops in calculating the loss interval
length, in order to make the estimated loss event rate closer to the
actual packet loss rate. How severely can this reduction of the
calculated loss interval length for short intervals affect the
calculated loss event rate? Because the most recent loss event
length contributes 1/6-th towards the calculated average loss
interval, a single small loss interval can't increase the calculated
loss event rate more severely than a factor of 6/5.
A second question could be whether, in an environment with repeated
short loss intervals, the succession of large and small calculated
loss interval lengths will cause severe oscillations in the
calculated packet drop rate. That is, is it possible for the
calculated loss interval length to repeatedly oscillate between N
packets and 2 packets, for N large? This could result in the
average loss interval oscillating between (10/6 + N/6) and 2, with
the resulting loss event rate oscillating between 6/(10+N) and 0.5.
How large can N be, and how severe can the oscillations get?
One limiting factor on the possible oscillations is that the TFRC-SP
sending rate is limited to at most one packet every 10 ms, giving an
upper bound on the number of packets that could be sent in two
round-trip times (as a function of the round-trip time, of course).
A second limiting factor is that during a scenario with short loss
intervals, the number of packets sent in a round-trip time cannot be
large unless there is both a small loss event rate (to give a
sufficiently large allowed sending rate), and a reasonably large
receive rate reported in the previous round-trip time (given that
the sending rate for the TFRC or TFRC-SP sender is limited to at
most twice the receive rate, in packets per second, reported in the
previous round-trip time). These factors taken together would rule
out a pattern of strong repeated oscillations in the calculated loss
event rate.
We note that with TFRC-SP, a potentially-large difference between
two successive reported loss interval lengths for a single short
loss interval would not be eliminated if, once a loss event was
detected, the TFRC-SP sender postponed sending feedback packets for
short loss intervals until all of the lost packets had been counted.
There would be the same large difference in the successive reported
loss interval lengths if the first feedback message reported N
packets received during the first round-trip time, with no packet
losses, and the second feedback message also reported the K
additional packets lost during the second round-trip time.
