arp querier/responder for multiple ip addrs on multiple networks using the same interface

[Eric Freudenthal]

Many thanks for your efforts over the weekend.  I am responding to several
of Eddie's notes in this one message.
Eric

> Did you include a ToDevice in the config? You must, when you use
> PollDevice. Even Idle->ToDevice(whatever) is enough.

Thanks for the incantation.  An implicit (automagic) Idle->ToDevice would be
handy.

> ARPQuerier only knows about one IP address and Ethernet address, but I
> don't see what a "multi-address querier" would do. How would it decide
> which address to use?

I assumed a multi-arp querier would include several network addr/masks, and
therefore could choose one in a network that included the dst addr.  Our
scripts now emit multiple queriers, and outgoing messages are forwarded to
the same one.  I assume that they aren't scheduled when there's nothing to
do.

>Short explanation: In the kernel, FromDevice is broken into two parts:
>something quick that happens at interrupt time, and a task. The
>interrupt-time part enqueues the arriving packet on a queue internal to the
>FromDevice (128 packets long). The task part dequeues packets from this
>internal queue and pushes them through the configuration.
>
>Normally there aren't that many tasks. However, each DelayUnqueue contains
>a task. 300 DelayUnqueues == 301 tasks == FromDevice is serviced 300 times
>less often == large, variable delay.
>
>The problem here is that most of your DelayUnqueues probably aren't doing
>much work. It's a shame they stay on the task list anyway.
>
>So I've checked in something experimental that may help you. Check out
>Click from anonymous CVS to get it. Basically, instead of this
>
> -> Queue(256)
> -> SetTimestamp
> -> DelayUnqueue(0.00001s)
>
>say this:
>
> -> NotifierQueue(256)
> -> DelayUnqueue(0.00001s)
>
>Now DelayUnqueue will go off the task list when it notices the
>NotifierQueue is empty, and NotifierQueue will stick DelayUnqueue back on
>the task list when an empty queue gets a packet. NotifierQueue acts like
>Queue except for notification functionality. Use a regular Queue to get the
>old behavior.
>
>Note also no more SetTimestamp; the new DelayUnqueue does that for you,
>which seems to make more sense.

Thanks; this should make a difference, but still waste cycles polling
DelayUnqueues when they contain packet with long residual delays.  Perhaps
it would make sense to only run DelayUnqueues when they need to do
something.  I suggest the following alternative design:
1. A blocked task would indicate a desired reschedule time.  The earliest
(enforced) reschedule time would be the time the task blocked. The latest
reschedule time would be infinity.  A task's reschedule time can be lowered
(perhaps only once, from infinity).  For compatibility, the default behavior
could be to reschedule now.
2. Replace the ready queue with a min-Q, keyed on reschedule times.
3. An DelayUnqueue's input-(probably push) method that would make an empty
DelayUnqueue non-empty would  lower the associated task's reschedule time to
the time that packet should be pushed.  Similarly, a task pushing a packet
would determine its next reschedule time based on the queues contents.

Cheers, and thanks again,
Eric

Eric Freudenthal  // Courant Institute // New York University
719 Broadway, Room 712 // New York, NY // 10003
office: 212-998-3345 // cell: 917-279-6208

-----Original Message-----
From: Eddie Kohler [mailto:kohler at icir.org]
Sent: Monday, March 04, 2002 12:12 AM
To: Eric Freudenthal
Cc: Taozhao at Cs. Nyu. Edu; Vijay Karamcheti; click at amsterdam.lcs.mit.edu
Subject: Re: arp querier/responder for multiple ip addrs on multiple
networks using the same interface

> For our application, the same network interface will clearly need to have
> multiple ip address, each on another net.  I scanned the click doc, and it
> appears that arpResponder and arpQuerier don' know about multiple
> ipaddr/nets.


ARPResponder, however, does support multiple IP and Ethernet addresses.

Eddie