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.
|