The IETF used to define itself by rough consensus and working code. So we can observe some of these things. In the end of the day, the problem is to make a platform on which many applications, with many design approaches, and whose goals we cannot appreciate at the "network layer", work well in the real world. Protocol designers should actually spend some time working on large scale systems, writing code in JavaScript and server-side frameworks, or developing conference systems or MMORPG's. These are the real issues, and congestion matters. But the problems cannot be "defined away" by focusing on a single TCP flow on a simplified network where everything else is assumed to be gaussian or poisson "noise" that can be ignored.
On Wednesday, October 7, 2015 4:57pm, "Jonathan Morton" <[email protected]> said: > > > On 7 Oct, 2015, at 23:40, Agarwal, Anil <[email protected]> > wrote: > > > >> Since the cable modem link will lead to clumped ACKs the difference > between sending 100 ACKs vs. 1 ACK is probably not that big... > >> (except w.r.t. reliability). > > > > The difference may not be big in the spacing of new packets that a sender > will send, unless the sender implements some sort of pacing or if the return > link > is very thin. > > > But with ABC, there will be a difference in the amount of cwnd increase at > the sender. > > There is also a potential difference for detecting packet loss in the forward > direction. It’s entirely possible that thinning would cause a DupAck > condition to be recognised only after three MAC grants in the reverse > direction > have elapsed, rather than one. Receivers are REQUIRED to send an ack for every > received packet under these conditions, but that would be subverted by the > modem. > AckCC would not induce this effect, because the receiver would still produce > the > extra acks as required. > > Packet loss causes head-of-line blocking at the application level, which is > perceived as latency and jerkiness by the end-user, until the lost packet is > retransmitted and actually arrives. Hence the addition of two MAC grant delays > (60ms?) may make the difference between an imperceptible problem and a > noticeable > one. > > - Jonathan Morton > >
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
