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. 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. c) Solution in the latest draft: We have a limited receive rate option, which tells that the receiver is sending feedback after an idle period. So the sender tries to maintain the "minimum" sending rate of (upto) 4 pkts/RTT. I guess this is what you are trying to achieve? Please do correct me if I am wrong. If that is the case, then I don't think this actually solves the problem since the sender although it had sent 50 pkts/RTT, it goes down to 2*4pkts/RTT in the next RTT - which I don't think is right. 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. Regards Arjuna -----Original Message----- From: Sally Floyd [mailto:sallyfloyd@xxxxxxx] Sent: 19 March 2007 19:16 To: Arjuna Sathiaseelan Cc: 'DCCP mailing list'; 'Gerrit Renker' Subject: Re: Re: revision of draft-ietf-dccp-rfc3448bis Arjuna - > I still believe the Limited recv rate does not solve the problem. I > shall > address this problem tomorrow in the meeting for Sally's view. Unfortunately, I am not going to be at IETF this week, so I think we have to do this by email. The current draft of draft-ietf-dccp-rfc3448bis does have a discussion of how it would work to have the sender rather than the receiver detecting feedback packets sent after idle periods. And the current draft has a discussion of how the sender could use Receive Rate Length feedback instead. Both of these are in Section 8, under "Feedback packets reporting Limited Receive Rate". - Sally http://www.icir.org/floyd/
