Dear Sally,
Yes I know that you are not going (unfortunately) to be here for the
meeting. I wanted to address this issue in the meeting but I guess I
would
email this.
I tried reading the latest version of the draft in a hurry - so I am
not
sure if this fundamental problem has been resolved.
Sally, please do correct me if I am wrong or if I have overseen the
draft.
a) The problem is:
After an idle period, the sender sends 50 packets/RTT. The receiver
would
send a feedback for 1 or 2 packets and not all the 50 packets. So
basically
that means in the next RTT, the sender can send only upto 2 or 4
packets
since it would be limited by the receiver rate.
Yes, after a short idle period, the sender might send 50 packets/RTT.
The other problem can occur after a long idle period, when the sender
can still send three or four packets per RTT (in the absence of Faster
Restart).
b) Solution in the previous draft:
Ignoring the feedback packet after an idle period.
Disadvantages of ignoring: The sender may be datalimited, sending 1 or
2
pkts/RTT, so ignoring sounded like a bad option.
The previous draft (draft-ietf-dccp-rfc3448bis-01.txt) didn't ignore the
feedback packet in this case. But it didn't get it right for this case
either.
From Step 4 of Section 4.3 in that draft:
If (sender has been idle or data-limited
within last two round-trip times)
min_rate = max(2*X_recv, W_init/R);
Else
min_rate = 2*X_recv;
This works fine for the sender starting up with a sending rate of
W_init/R after a long idle period, but I agree that it has a problem
for a sender starting up with a sending rate of 50 packets/RTT
after a short idle period. The current version of the draft,
draft-ietf-dccp-rfc3448bis-02a.txt, has the same problem.
It basically just changed
"If (sender has been idle"
to
"if (feedback packet reports Limited Receive Rate"
as a more precise and more efficient way for the sender to
detect it has been idle at the beginning of the period
reported by the feedback packet. It didn't change
*how* the sender responded to the feedback packet,
so it has the same problem when the sender starts up
with a sending rate of 50 packets/RTT.
...
If I have understood c) properly then I would like to propose
something like
this:
1)The sender maintains the "number of packets" it has sent after an
idle
period.
2)Receiver sends feedback (1 pkt/RTT)
3)Ignoring the feedback after an idle period: The sender checks to see
if
the received feedback is less than what it has sent. Also it checks if
there
is any ECN marking or loss. If no ECN or loss, and if the received
feedback
is less than what it has sent, ignore the feedback. (Ignoring is
perfectly
OK here).
4)If the sender was data-limited (sending less than the min rate) and
it
receives a feedback (less than the min rate), then maintain the min
rate,
the feedback packet is NOT ignored.
I guess this would solve the problem of the sending after an idle
period.
So are you proposing something like this:
If (sender has been idle over period
covered by the feedback packet)
min_rate = Infinity;
Else if (sender has been data-limited
over period covered by feedback packet)
min_rate = max(2*X_recv, W_init/R);
Else
min_rate = 2*X_recv;
I don't think that works.
Consider the following cases. It works for Case B, but not
for Case A or Case C.
Case A, a long idle period:
Assume that after a long idle period, expirations of the nofeedback
timer have reduced X_recv to 0.5*W_init/R, and the sender starts
up with an allowed sending rate X of W_init/R. After the first
feedback packet after the idle period, reporting the receipt of the
first packet, the allowed sending rate can at most double, so it
can be at most 2*X. Even if X_Bps would allow a sending rate of
much higher.
(Nit: what if the sender sent less than the allowed sending rate
after the long idle period? Would that make a difference?)
Case B, a short idle period:
Assume that the sender was idle only for two RTTs, not long enough
for the nofeedback timer to expire. The allowed sending rate X is
500 packets per RTT, but the sender re-starts with a sending rate
of 50 packets per RTT. After the feedback packet after the short
idle period, reporting the receipt of the first packet, the sender
is going to be able to send 500 packets per RTT? Yep. So it works
to say that the sender is not limited by anything. It also works
to say that the sender is limited by 2*X.
Case C, no feedback from receiver:
Assume that the allowed sending rate X has been reduced to 1/64 packets
per second because of the nofeedback timer expiring, while the
sender has been sending packets as much as allowed. The sender
sends another packet when allowed, and the feedback packet is
received reporting a receive rate of one packet per RTT. The
sender's allowed sending rate in this case has to be limited by
2*X_recv, allowing the sender to send two packets per RTT in the
next RTT, slow-starting back up to its old sending rate.
I would suggest the following:
If (sender has been idle over initial period
covered by the feedback packet)
min_rate = max(2*X_recv, 2*X);
// X: the allowed sending rate when that first
// packet was sent
Yes? This works in all three cases above, I believe.
Then there are questions of what exactly
"If (sender has been idle over initial period
covered by the feedback packet"
should mean, and there are
implementation questions to be considered.
I think that the most accurate and efficient way to do this
is the following:
If (feedback packet reports Limited Receive Rate)
min_rate = max(2*X_recv, 2*X);
// X: the allowed sending rate when that first
// packet was sent
It is just about *how* the sender detects that the initial time
period covered by the feedback packet from the receiver was
an idle period (in this case, that means an idle period sufficiently
long that the receiver didn't send a feedback packet when its
previous feedback timer expired.
There are still difficulties with the case when the sender has
been data-limited, but that will have to wait for another email.
A note on Section 4.4:
Somehow RFC3448bis ended up deleting the last paragraph of
Section 4.4 in RFC 3448. I have added it back, with some rearrangement
of the text of Section 4.4 for clarity. The functionality of Section
4.4 in RFC3448bis is now back to being exactly what it was in RFC
3448.
"http://www.icir.org/floyd/papers/draft-ietf-dccp-rfc3448bis-02c.txt";.
- Sally
http://www.icir.org/floyd/
