[click] element design question: ACKRetrySender, etc.

[Douglas S. J. De Couto]

Hello Clickers,

The question is: I have written an some elementd assuming that they
works at the Ethernet level.  How can I make them useful at other
levels in the network, e.g. IP.  OR, perhaps these elements aren't
useful at other levels of te network (but I doubt that).

The two elements implement positive acknowledgement of packets:
ACKRetrySender and ACKResponder.  The idea is to emulate/implement the
link-layer retransmissions used in wireless networks like 802.11.

you use the elements like so (similar to ARPQuerier/Responder):


... -> ACKRetrySender -> <link> -> ACKResponder -> ...
           ^                           |
           |                           V
           +-------------<link>--------+


Data packets flow along the top, ACKs flow back on the bottom.

The elements assume that packets are Ethernet packets.  I made a new
Ethernet packet type to be used by the acknowldgements.

The ACKResponder needs to know its own address, in order to decide
which packets to acknowledge.  The ACKRetrySender needs to know about
the address formats in the packets it acknowledges, so it knows when
an ACK matches the packet it is caching for possible resends.  Also, I
decided to use an explicit ACK packet format so that the
ACKRetrySender could do some sanity checking (as opposed to treating
any packet on that ACK input port as an ACK for the current data
packet).

Any suggestions on how to generalize so that it would work at the IP
level as well?  Perphaps some judicious use of AddressInfo and the
packet type annotation?


----

-- Different ARP policies:

Because the ACKRetrySender can only handle on data packet pending ACK,
I made it pull.  If you want to implement a policy where packets are
dropped if one is already outstanding, you could use a Queue of size
1.  I think that if ARPQuerier were pull, it would also be able to
accomodate different ARP policies (e.g. drop packets while ARP
outstanding, or queue packets until ARP received).  I am not quit sure
how the interaction would work, because the ARPQuerier is implicitly a
size-1 queue.  well this isn't quite worked out yet...

cheers,

d



-- 
Douglas S. J. De Couto    decouto at lcs.mit.edu