Re: [tcpm] rfc2581bis-01 and RFC 2861

> > Yes.  One could argue that the faster increase (the traditional
> > approach) is inappropriate, but it is a pretty small effect (and, it
> > can cut both ways---sometimes being beneficial and sometimes not).
> 
> Can you elaborate how it may not be beneficial?

If you increase too fast you may cause (more) congestion.

The ACK splitting attack is sort of the bounding example.  If the
receiver ACKs every byte then it sort of defeats congestion control.
E.g., by getting the sender to increase cwnd from one packet of 1460
bytes to 1460 packets of 1460 bytes each (over 2MB) in one RTT.  That
sort of increase rate is not consistent with the spirit of slow start
and could certainly cause congestion on the network.

In congestion avoidance which way you increase things really doesn't
matter as much because the increase is linear and while ACKing every
byte still might help, it is probably not going to cause a big problem.

> You are right. However, as Christian Huitema pointed out, there are
> fairness issues here.

See my response.

Fairness depends on what you are competing with.  Christian's example is
a fine example of inequity.  But, how does an endhost tell the
difference between his scenario and a scenario whereby a zillion flows
are all sending at 10 packets/second and therefore when there is loss
the flow in question ought to be throttled?  No amount of counting of
bytes or using CWV of cwnd vs. FlightSize is going to give the flow the
information to make the right decision.

allman