On Sun, 11 Oct 2015, Joe Touch wrote:
On 10/11/2015 2:18 PM, David Lang wrote:
But you will notice that in both cases, I am in favor of reducing the
number of packets on the wire. Packets not send can't interfere with
other traffic.
The degenerate case of this approach is a circuit. Take a look at
Morris's 1997 ICNP paper to see what happens when you end up with one -
or sometimes less than one - packet per round trip time.
One of the reasons we use packets is to provide more timely,
fine-grained feedback between endpoints. Aggregating them at the source
or in the network (rather than at the receiver) can amplify reaction to
packet loss (when the aggregate ACK is lost)
the issue of amplified reaction to packet loss is a valid one, but packet loss
is still pretty rare, so the proposal of putting a duplicate stretched ack into
the queue for the next transmit window when you aggregate packets in the current
transmit window should largely mitigate this.
In addition, Since cablemodems have been doing this for 15 years, we should be
able to get people to look at real-world traffic and tell us how much of a
problem this is.
and increases
discretization effects in the TCP algorithms.
This is where I disagree with you. The ACK packets are already collapsed
time-wise. Whatever timing they had when they were generated, the fact that they
are all sitting in the same queue at the same time means taht that timing has
been lost, Nobody is adding latency by trying to recreate the time spacing, so
the discretization (or as I've been calling it quantitization) of the traffic is
happening even if every ACK packet is sent.
My contention is that since this is already happening, consolidating the ACK
packets into stretched ACKs doesn't make this any worse, and it saves network
bandwidth (and decreases latency to the extent that data is acked faster than
waiting for the entire chain or original ACKs to get through, especially if that
would take multiple transmit windows). As a result, thinning the ACKs is kinder
to the network.
I am in no way advocating delaying any packet that could be sent, just combining
those that have already been delayed.
We're talking about ACK packets here, but any protocol that sends short TCP
packets is potentially fair game (TCP/SSH for example). If the packets are all
sitting in the same queue, they should be able to be combined. This happens on
the sending server if multiple writes to the socket happen before the packet has
been sent, it should be able to happen on the network as well (further reducing
overhead by sending the same data with fewer packets)
David Lang
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
