Gorry -
Ah dear. My apologies at being more than a month late at
getting to these.
During the WG meeting today we looked at the following set of
questions posed by implementors. Could people in the working group
please look at these questions and see if they are able to help with
answers?
Questions relayed by gorry to the list:
a) Should reported X_recv be used as-is?
CCID-4 doesn't mention X_recv, because it is treated a
exactly as in CCID-3.
Section 5.2 in CCID-3 describes how X_recv is modified for DCCP's
Data Dropped and Slow Receiver options. and other than that, CCID-3
refers to RFC 3448 for specifications of X_recv. CCID-3 says that
Section 6.3.1 in RFC3448 specified how X_recv is set after the first
loss event, and CCID-3 says that Section 3.2.2 of RFC 3448 specifies
the use of X_recv. So yes, except for DCCP's Data Dropped and Slow
Receiver options, and after the first loss event, X_recv is used
as is.
b) Should application run the values through "smoothing" function
before using new value?
e.g. using a standard EWMA filter?
Not for X_recv.
(As an aside, RFC3448bis (in progress) is less strict than RFC 3448 in
how X_recv is used in data-limited periods.)
c) Calculation of average loss interval in TFRC-SP: the most recent
loss interval is used in calculation only if it's "long" (e.g. >= 2
RTT
is this sufficient for senders not validating X_recv against reported
loss intervals and dropped packets?
I would say that it is orthogonal to whether senders validate X_recv
against reported loss intervals and dropped packets. A "short"
loss interval should not be used in the calculation whether or not
the sender performs this validation, because with TFRC-SP, the
calculated length of a "short" loss interval can change in odd ways
as new losses are reported. And if the sender doesn't validate
X_recv against reported loss intervals and dropped packets, then
it would be easy for receivers to "cheat", completely aside from
any considerations of short loss intervals.
d) CCID4 Feedback: options: Are the Loss Intervals / Dropped Packets:
fields too big for Lossless Length, Loss Length, and Data Length?
The lossy part of Loss Interval cannot be > RTT: 24-bit counters
appear to be over-dimensioned especially with CCID-4 (which sends at
most 100pps).
I think that the large fields (three bytes) for the Lossless Length
and Data Length fields in the Loss Intervals Option are useful,
even for CCID-4. It is true that CCID-4 is going to send at most
100 pps, but the round-trip time could be some seconds, leading to
a sending rate of hundreds of packets per RTT. To maintain this,
the CCID-4 sending would want to hear about fairly large loss
intervals, larger than 256 packets. So clearly at least a two-byte
field is needed for the Lossless Length and Data Length fields,
even for CCID-4.
A two-byte field can report a Data Length of 64K packets, corresponding
to a loss event rate of 0.00002; this is enough to give the CCID-4
sender an allowed sending rate of roughly 250 packets per RTT, which
is enough for a connection with a round-trip time of at most 2.5
seconds. For a CCID-4 connection with a larger round-trip time,
the three-byte Lossless Length and Data Length fields would be
better.
For the Loss Length field in the Loss Intervals Option, reporting
the number of packets in the one-RTT lossy part of the loss interval,
I don't think that a one-byte field would be sufficient for a CCID-4
connection with a long RTT (three seconds or longer), but a two-byte
field would be sufficient; three bytes is clearly overkill for
CCID-4 for the Loss Length field.
However, my assumption would be that for CCID-4, the benefits of
using the same Loss Intervals options as in CCID-3 out-weight the
benefits of reducing a field from three bytes to two bytes (even
if the Loss Length field is used up to eight times in a feedback
packet). But if others thought otherwise, it would be easy to
change the Loss Length field in the Loss Intervals Options from
three bytes to two bytes, for the specific case of CCID-4 (using a
different option number for that option in CCID-4).
The three bytes for the Drop Count field in the Dropped Packets
option is clearly unnecessarily large for CCID-4; this option
wasn't originally designed for use only by CCID-4. It only needs
to be large enough to report the number of drops in the lossy part
of the loss interval. I think that a one-byte field would be fine
for this - while one could imagine a CCID-4 connection with a very
long round-trip time and more than 256 losses in a round-trip time,
this clearly would be a very unusual event, and not something that
could happen in steady state.
So a two-byte field for the Drop Count would clearly be sufficient,
and a one-byte field would probably work fine also. I would be
happy to change then when I revise the draft.
e) Due to feedback once per RTT [RFC4828]: Lossless Length and Data
Length fields might also be shorter, e.g. 16 bit or even less?
No, because the Lossless Length and Data Length fields report the
length of an entire loss interval, not just of the data received
since the last feedback packet.
Thanks for the feedback!
- Sally
http://www.icir.org/floyd/
