On 24. aug. 2014, at 07:14, David Lang wrote: > On Sat, 23 Aug 2014, Hal Murray wrote: > >>>> Yep... I remember a neat paper from colleagues at Trento University that >>>> piggybacked TCP's ACKs on link layer ACKs, thereby avoiding the collisions >>>> between TCP's ACKs and other data packets - really nice. Not sure if it >>>> wasn't just simulations, though. >> >>> that's a neat hack, but I don't see it working, except when one end of the >>> wireless link is also the endpoint of the TCP connection (and then only for >>> acks from that device) >> >> That could be generalized to piggybacking any handy small packet onto the >> link layer ACK. >> >> Of course, then you have to send back a link layer ACK for the extra info. >> Does that converge? > > if you aren't talking between the two endpoints of the wireless connection, > probably :-) > > but fairness would be an issue for something like this. what constitues a > 'small amount of data' to try and piggyback, and what happens if you are > talking between endpoints, are the two allowed to monopolize the airtime?
I agree - there'd have to be a size limit placed on what you really do piggyback on link layer ACKs. TCP ACK size can vary, depending on SACK... > but backing up a step, finding airtime for the ack is just as hard as finding > airtime for the next transmission. I think not, don't link layer ACKs get to use a smaller CW? Or is this just me remembering it wrongly? Cheers, Michael _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat