Patch to dummynet to allow simulation of compressed ack's

[rrs]

Summary

One of the harder things to make a transport protocol deal with is
compressed acks. Thats where a channel access time will be hit, during
which packets are queued. When the channel is accessed some time
later (think up to 200ms) all of the packets that were queued are
released. This causes a series of acks that used to be spaced out
to arrive all at once.

In order to "fix" a protocol to better work with compressed acks one
needs a mechanism to simulate it. This set of changes to dummynet allows
that by adding two new features to the profile configuration of dummynet.

Test Plan

Build a profile that includes the new features channel_bytes and clear_on_empty
and make sure dn will push out compressed acks. I have done
this multiple times now as a matter of fact. I have also tested
that with it off dn still works like it is supposed to.

[hiren]

This will be quite useful! Thanks.

I'll try to test this out. I guess the idea is to use this feature on ack path direction and club a bunch of acks together. If you can share a couple dummynet configs, I'll get a better idea.

A general note, term CTD (cell transfer delay?) is not something used in dummynet. Its simply called "delay" and I think we are not changing the notion of delay here but changing how bytes are sent on that delay. Might be less confusing to call it just "delay". If thats not the case, probably a good idea just to make it a bit explicit what CTD means.

[hiren]

Haven't been able to actually test this out yet but don't want to holdup the commit for that.

1. look at existing comment about CTD.
2. Add an example config entry in to the EXAMPLES section of the manpage.

[rrs]

A couple of configs I use:

For full ack compression like in cellular

name ack_compress
samples 4
channel_bytes 1500
clear_on_empty 1
prob delay
0.0 180
0.3 190
0.7 200
1.0 200

For mild ack compression like a congested reverse path

name med_ack_compress
samples 4
channel_bytes 0
clear_on_empty 0
prob delay
0.0 0
0.5 10
0.9 20
1.0 30

Now Lugi has suggested an alternative implementation that I have not had time to circle back to and try. If that
works I will update this patch and then commit it.. If it does not I will place this in since I know it works