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

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 19 May 2003 10:23:26 -0700

> > ii) by reducing cwnd, you are more vulnerable to additional
> > reductions = if a loss event occurs while you are trying to build
> > back up.
> 
> So, if I read the above right ... Assume we use maxburst,
> outstanding_data=X and cwnd=X+Y (bigger because of the maxburst
> limiting).  So, you're saying that if a loss event occurs we set
> cwnd to (X+Y)/2?  (Whereas if we reduce cwnd we end up doing
> something like: cwnd=(X+maxburst)/2.)  Do I have that right?
> 
> If I do have that right then I disagree.  I think that if you lose
> something when outstanding_data = X then you should be halving from
> X regardless of cwnd (i.e., cwnd = X/2).  (And, in fact, this is
> what rfc2581 would call for.)  

yeah, you're right.
> 
> Or, maybe I am misreading your intention?
> 

If you think of this as a CWV case, in the sense that the sender is
"ack-limited" rather than application-limited, then I would tend to
agree that your proposal is more in the spirit of that.  However, 
if you think about the intention of Reno, not requiring senders to 
reduce cwnd (or FlightSize) more than half for a single window's 
loss event, then one could argue for maxburst or rate-based pacing 
type of solutions.  I have tended to think of it as the latter.

But as we discuss this more, it seems to me that either your proposal 
#3 or the original maxburst proposal might end up being about the 
same in practice.  Either one should reduce the burstiness problem
that has been observed at the end of fast recovery.  Maybe there is 
a high-speed TCP angle that makes more of a difference one way or another.

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

---

From: Mark Allman <[email-masked]>
Date: Mon, 19 May 2003 22:46:53 -0400

> agree that your proposal is more in the spirit of that.  However,=20
> if you think about the intention of Reno, not requiring senders to=20
> reduce cwnd (or FlightSize) more than half for a single window's=20
> loss event, then one could argue for maxburst or rate-based pacing=20

Ah, ok... That's a nice description.  I think I have a handle on the
two ways to look at this now.  (I still think the former is the way
to go if one were to want a generalized burst controller... but, I
understand the thinking behind the latter.)

> But as we discuss this more, it seems to me that either your proposal=20
> #3 or the original maxburst proposal might end up being about the=20
> that has been observed at the end of fast recovery.  Maybe there is=20
> a high-speed TCP angle that makes more of a difference one way or =
> another.

I'd very much like to know of such implications, too.

Thanks!

allman

--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/