Again, apologies for the month-long delay in getting to this.
On Dec 5, 2007, at 5:01 PM, Gorry Fairhurst wrote:
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:
1) Input is solicited how DCCP is being used (how, where, settings,
apps, ...) tested (results, comparisons, ...)
Someone else might know the answer to this.
2) CCID-3: Problems with receiver-RTT estimation X_recv accuracy
depends on RTT accuracy algorithm gets confused by the min CCVal = 5.
RTTs are influenced by packet-timing compression EWMA filter helps,
but RTTs appear much higher very messy to filter out marginal
conditions
I agree that with CCID-3, the RTT estimation using CCVal
can be messy and inexact (and the procedure doesn't work
when CCVal is 5 or greater, as noted in the RFC).
In terms of X_recv, the RTT estimation is used in calculating X_recv
after an idle period of longer than the round-trip time, and after a new
loss event. (Using the RFC 4342 Errata from October 2007.)
in other cases, feedback is sent when the receiver's feedback
timer expires, and the feedback timer was set to expire an RTT
after the previous feedback was sent. Section 10.3 of RFC 4342
describes how the receiver can decide when to send feedback
packets without using an RTT estimate. However, if the receiver
decided when to send feedback packets without using an RTT
estimate, this complicates the issue of whether to calculate X_recv
over the time since the last feedback packet was sent, or over
the most recent RTT (as specified in the October 2007 errata).
3) Suggestion that the CCID-3 sender communicates his/her RTT sender
has a very accurate RTT estimate originally suggested in RFC 3448
could use a DCCP option?
Yes, a few of the pros and cons for this are discussed in the last
paragraph of Section 10.2 of the CCID-3 spec. I think it would be
fine for someone to evaluate the pros and cons more fully, and to
add this as an option for DCCP. The unfortunate fact, however,
is that I am now semi-retired, and I am not likely to take on such a
revision myself. So someone else would have to volunteer to
do it.
On the plus side: an RTT option, for sending the RTT estimate, would
make implementation at the receiver simplier, I would assume.
On the negative side: an RTT option in every data packet would
increase the size of the packet header for data packets. So
it might make sense to the RTT option to be sent in data packets
at most once per RTT, or something like that. This is a design
decision that would have to be made.
4) Faster Restart Feedback: Implementing X_recv_set seemed too
complicated so implementation just used X_recv i.e. as per
rfc3448bis-00
I think it is important, in terms of functionality, to implement
X_recv_set. As the November version of the draft says
(draft-ietf-dccp-rfc3448bis-03.txt):
"The sender also
maintains X_recv_set as a small set of recent X_recv values
(typically only two values)."
I think it is important to implement X_recv_set to be able to contain
at least two entries, but I think there *could* be some performance
benefit to having room for three entries in X_recv_set. ((n either
case,
X_recv_set would keep the rule of deleting entries from X_recv_set
that have timestamps older than two RTTs.)
(This is how the sender could receive three X_recv values in two RTTs:
A feedback packet could be sent at time t, and a second feedback packet
sent an RTT later at time t+RTT. Then a third feedback packet could be
sent a very short time later when an ECN-marked packet arrives at the
receiver, denoting a new loss event.)
If X_recv_set is implemented to keep at most N entries, all that
is needed is the following line added to the end of the "Update
X_recv_set" procedure:
Keep only the N most recent values.
I will add this as an implementation note to the Faster Restart draft.
5) In present tests Faster Restart showed no noticeable improvement
but may be due to selection of test scenario contact Ian McDonald for
further information
Arjuna is doing the evaluations of Faster Restart, so I will let him
talk
with Ian.
- Sally
http://www.icir.org/floyd/
