Eddie: Ok I get it now..My entire arguments (hence the confusion )were based on RFC3448-bis and not RFC3448...I was raising points from the RFC3448-bis draft under the presumption that this draft obsoletes rfc3448 when it comes to implementing in ns-2.. Arjuna On 2/14/07, Eddie Kohler <kohler@xxxxxxxxxxx> wrote:
Arjuna: Arjuna Sathiaseelan wrote: > Dear Eddie, > Thanks for your reply..Ok - the way I saw this problem was like this: > > Say the sender is idle for 1.5 RTTs and then sends 2 packets, then > when the feedback is received, then the following part of the > algorithm from Section 4.3 (RFC3448) would be executed (the > presumption is that this algorithm (Section 4.3 RFC3448) is executed > for every feedback packet received): > > If (sender has been idle or data-limited) > min_rate = max(2*X_recv, W_init/R); > > This ensures that the min_rate is atleast W_init/R. I really don't get it. Are you talking about RFC3448bis or something? Because nothing like that is in RFC3448 section 4.3. RFC3448 section 4.3 doesn't even mention idle or datalimited senders. It does not contain the token "min_rate" or "W_init". I believe DCCP implementers should generally look at RFC3448 as modified by RFC4342. RFC3448bis is a different kettle of wax and for example I haven't taken an editing pass. Any document that provides the above min_rate calculation is I think wrong. > So what I felt was that what happens if one of those 2 packets were > lost. Do we still execute the above code? No, you never execute the above code, because no active standard specifies it > But after I wrote the previous mail and a deep inspection led me to > think that this may not cause any "serious" effect, since if the loss > event rate 'p' was greater than 0, then the sending rate would be rate > limited to the rate calculated by the throughput equation. So this > should not be a problem and if that is the case then you can ignore my > previous mail. Since RFC3448, the active standard, does not contain the token "min_rate", and neither does RFC4342, I can neither confirm nor deny your supposition. But as I explained in the last mail I do not think that an RFC4342 implementer should take this tack. Instead X_recv should be prevented from going below W_init/2R, which has the effect we want with no ambiguity. > This is in the same line of thinking that Gorry and I discussed few days > back: > > The response of the sender when a feedback packet arrives after the > nofeedback timer: > > ``if (not the first feedback packet, and not the first feedback packet > after a > nofeedback timer)'' - we ignore the feedback packet. > > In this case, we were wondering what happens if the sender was > datalimited after a nofeedback timer expiry and sends very few > packets! Do we still ignore the feedback packet? Again, is this RFC3448bis, or some other local version of RFC3448? If it really is RFC3448 can you point to where? It looks like it is RFC3448bis. My comments above apply. And I don't like this technical solution either. To summarize: * DCCP CCID 3 implements RFC3448 and RFC4342, not RFC3448bis * I cannot answer questions about RFC3448bis; I am not an author * The solutions in RFC3448bis are not yet ready for prime time; it is after all an -00 draft E > > -Arjuna
-- Electronics Research Group University of Aberdeen Aberdeen AB24 3UE Web: www.erg.abdn.ac.uk/users/arjuna Phone : +44-1224-272780 Fax : +44-1224-272497
