[Bloat] Random idea in reaction to all the discussion of TCP flavours - timestamps?

[Rick Jones]

On Wed, 2011-03-16 at 00:26 +0200, Jonathan Morton wrote:
> On 16 Mar, 2011, at 12:19 am, Stephen Hemminger wrote:
> 
> >> Knowing the occupancy of the hardware buffer is useful if the size of the buffer cannot be changed, because it is then possible to simply decline to fill the buffer more than a certain amount.  If you can also assume that packets are sent in order of submission, or by some other easy rule, then you can also infer the time that the oldest packet has spent there, and use it to tune the future occupancy limit even if you can't cancel the old packet.
> >> 
> >> Cancelling old packets is potentially desirable because it allows TCPs and applications to retransmit (which they will do anyway) without fear of exacerbating a wireless congestion collapse.  I do appreciate that not all hardware will support this, however, and it should be totally unnecessary for wired links.
> > 
> > Have you looked at actual hardware interfaces. They usually are designed to
> > be "fire and go" with little to no checking by CPU. This is intentional because
> > of the overhead of bus and CPU access. Once packets go into the tx ring there
> > is no choice but to send or shutdown the device.
> 
> For a wired device that would certainly make sense.  For a wireless
>  device some extra flexibility is plausible, even if it doesn't exist
>  in practice.

Back and forth synchronization between driver and device is
doubleplusungood.  Being able to remove a packet on the tx queue already
made known to the NIC sounds like it could become a rathole. If you are
lucky, you *might* have a "valid/invalid" bit in a packet descriptor
that the driver could hope to set before the NIC had pulled-in a copy
across the I/O bus.

rick jones