It's not infeasible to make queues shorter. In any case, the throughput of a
link does not increase above the point where there is always one packet ready
to go by the time the currently outgoing packet is completed. It physically
cannot do better than that.
If hardware designers can't create an interface that achieves that bound I'd be
suspicious that they understand how to design hardware. In the case of WiFi,
this also includes the MAC protocol being designed so that when the current
packet on the air terminates, the next packet can be immediately begun - that's
a little more subtle.
But my point here is that one needs to look at the efficiency of the system as
a whole (in context), and paradoxically to the hardware designer mindset, the
proper way to think about that efficiency is NOT about link throughput
maximization - instead it is an end-to-end property. One has very little to do
with the other. Queueing doesn't affect link throughput beyond the "double
buffering" effect noted above: at most one packet queued behind the currently
transmitting packet.
Regarding TXOP overhead - rather than complicated queueing, just allow packets
to be placed in line *while the currently transmitting packet is going out*,
and changed up to the point in time when they begin transmitting. This is
trivial in hardware.
On Friday, July 31, 2015 1:04pm, "Jonathan Morton" <[email protected]> said:
> I think that is achievable, *even if there is a WiFi network in the middle*,
> by thinking about the fact that the shared airwaves in a WiFi network behaves
> like a single link, so all the queues on individual stations are really *one
> queue*, and that the optimal behavior of that link will be achieved if there
> is at most one packet queued at a time.
I agree that queues should be kept short in general. However I don't think
single packet queues are achievable in the general case.
The general case includes Wi-Fi networks, whose TXOP overhead is so ruinously
heavy that sending single MTU sized packets is inefficient. Aggregating
multiple packets into one TXOP requires those several packets to be present in
the buffer at that moment.
The general case includes links which vary in throughput frequently, perhaps on
shorter timescales than an RTT, so either packets must be buffered or capacity
is left unused. This also happens to include Wi-Fi, but could easily include a
standard wired link whose competing load varies.
The endpoints do not have and do not receive sufficient information in
sufficient time to reliably make packets arrive at nodes just in time to be
transmitted. Not even with ECN, not even with the wet dreams of the DCTCP
folks, and not even with ELR (though ELR should be able to make it happen under
steady conditions, there are still transient conditions in the general case).
- Jonathan Morton
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
