Subject: RE: [Tsvwg] taking NewReno (RFC 2582) to Proposed Standard

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 16 May 2003 11:32:43 -0700

> -----Original Message-----
> From: Armando L. Caro Jr. [mailto:[email-masked]]
>
> Yes, agreed. I think the right thing to do is to apply max 
> burst always.
> No matter what, each ack may only trigger a send of at most Max.Burst
> packets.
> 

Does such a recommendation, if agreed, belong in a NewReno specific document?

Another issue that may or may not be NewReno specific is whether it is a good idea to recommend suppressing the sending of pure window updates intermingled with dupacks, to avoid resetting the counter to enter fast retransmit (Jeffrey Hsu mentioned this to me earlier this week).  This probably is not an issue when SACK is used.    

Tom 
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Murali Bashyam <[email-masked]>
Date: Fri, 16 May 2003 11:47:24 -0700

> Another issue that may or may not be NewReno specific is whether it is a good idea to recommend suppressing the sending of pure window updates intermingled with dupacks, to avoid resetting the coun…

During recent testing with NewReno, we had observed this too, and it's a good idea to consider suppressing pure window updates, to reduce the recovery time.

With regard to burstiness introduced by the fast recovery algorithm, we observed an interesting behaviour and i thought it might be relevant to this discussion. Sometimes we had noticed that  the sender increments cwnd in response to a duplicate ACK by a MSS, and then does not use this cwnd because there is no new application data
available to send, and after several duplicate ACKs (still  remaining in fast recovery phase),  the application queues more data, and the sender now   uses the cwnd all at once to transmit a long burst of packets, sometimes upto 10 or 11 packets back to back. I agree this is not NewReno specific, i think the scenario is likely to
happen with Reno too, but the solution to avoid this burst is to use the maxburst parameter, i guess?

Murali

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Fri, 16 May 2003 15:04:10 -0400 (EDT)

> Does such a recommendation, if agreed, belong in a NewReno specific document?

I am not sure. Maybe it should be in a protocol/TCP-variant independent
document. What do others think?

~armando

0--                                                  --0
| Armando L. Caro Jr.      |  Protocol Engineering Lab |
| www.cis.udel.edu/~acaro  |    University of Delaware |
0--                                                  --0