Subject: Re: Model Draft: events comments

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 11 Jan 2006 17:53:08 -0500

I think that is simply much too complicated.
To put it differently, I don't think that is a threshold that the CE will 
want to respond to.  That is the kind of thing that a management system 
provides so that Human beings can respond to truly anomalous 
occurrences.  I don't think we need that much power on the FE-CE 
interface.  I do want to avoid excessive notifications (which is why I put 
in the hysteresis, and I am willing to look at other modest controls.)

Yours,
Joel

At 05:23 PM 1/11/2006, you wrote:
>Joel,
>
>apologies for taking so long to post.
>Let me start with the most important concern and then later go into the
>little issues in other emails (I have to run unfortunately):
>
>Generally, I think there is a lot of good thinking that went into the
>events descriptions - so kudos.
>
>My desire is to have a nagle-like feature such that one can define
>thresholds for events; example
>"tell me when 3 such events occur or every five minutes"
>
>Thoughts?
>
>cheers,
>jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 12 Jan 2006 09:40:03 -0500

On Wed, 2006-11-01 at 17:53 -0500, Joel M. Halpern wrote:
> occurrences.  

In our case the reasoning has to do with performance and not Human
interaction. 

Assume a worst case scenario (without saying what specific LFB would do
this):
Every time a packet of a certain flow arrives, an event to the FE is
generated. Imagine further this is a high throughput flow and add to
that the fact you have several thousand such flows.
The amount of events that could be generated to the CE by such a LFB
would be horrendously high.

> I don't think we need that much power on the FE-CE 

If you can show me how the above problem is solved by the hysteris you
scheme proposed or other additional controls, that would suffice. 

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 12 Jan 2006 09:48:59 -0500

I have trouble envisioning a situation in which a packet directly produces 
an event.  One would not have an event tied to the bad IP header event.

The case where this sort of thing comes up is with redirected 
packets.  Many routers support rate limiting specific sets of packets (ICMP 
for example) to the control processor.  ForCES needs to support that.  But 
that is a data plane event.  It would be done with a meter applied to 
either the aggregate ICMP to the CE or on a per-flow basis for ICMPs to the 
CE (implemenation / CE choice).  Assuming (as we should) that we have a 
meter LFB, the CE can include that in the data path and provide the 
appropriate control.

To phrase it differently, any condition which can be provoked by a single 
data packet should not result in an event.  Redirect with meta-data will 
handle such circumstances better.

Yours,
Joel M. Halpern

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 12 Jan 2006 09:59:24 -0500

> an event.  One would not have an event tied to the bad IP header event.

Think of a scenario where an arriving packet possesses some state that
is needed to be synced in with another FE for HA purposes.
 
> handle such circumstances better.

Refer to what i said above. It's for state synchronization. You dont
need the whole packet[1] - you need a few small pieces of bits and bytes
of info from it.

cheers,
jamal
[1]so redirect is a really bad way of doing this, not wrong - just dumb
because it would need a lot more resources (both compute and bandwidth).

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 12 Jan 2006 10:38:33 -0500

I think that this may be better addressed with a custom LFB that generates 
a redirect packet with meta-data.  (it probably would actually produce a 
smaller packet, too...)
For one thing, as you describe it this can probably cope with loss or 
significant delay in reporting.  The events use the reliable control channel.
Also, the number of variables I can imagine for synchronization are much 
higher than I think makes sense for event reporting.

I would like to keep the amount of state that the FE needs to keep for each 
event small.  Since one assumes the FE has whatever the current state is, 
and has the information as to the definition of the event, hysteresis only 
requires one extra bit.

A reseting counter only seems useful if it also has a time limit.  Time 
limits imply timers per event.  I fear that could increase the complexity 
noticeably  (many boxes I have built have had limits on the numbers of 
timers they could implement efficiently.)

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 12 Jan 2006 11:18:55 -0500

> a redirect packet with meta-data.  (it probably would actually produce a 

Let me position it differently:

Consider a packet arrival at the FE that updates a table row. Say i am
interested in such an update for the purposes of updating another FEs
(backup) so the table states between them are synced. I believe this
would be a generic desire and not one that necessitates a custom LFB.

> significant delay in reporting.  

indeed - it is a trade off. The longer you wait for the updates, the
longer it would take to failover or the more compute/bandwidth it would
take etc. So let the CE control those two knobs as configured by the
admin. 

> The events use the reliable control channel.

We could use a reliable channel but it is unnecessary. You can afford to
loose some of these updates (as you stated above) since they tend to be
accumulative updates of some table entry. A reliable channel will
retransmit obsolete knowledge under congestion.

> limits imply timers per event.  

This is implementation details really not architectural concerns.
Weiming and I have had long debates on the timers - and depending on how
you implement your timers, yes you could suffer. 

> I fear that could increase the complexity 

I think every box would have a limit, no doubt. Most contentious issue i
have come across is RAM - at least on Linux[1]. My fear at the moment
(based on experience) is the scalability of a Forces cluster because we
decided not to add event congestion control.

cheers,
jamal

[1]I can do hundreds of thousands of flows in Linux today each monitored
by a timer or two without any problems. I would rather pay for the extra
RAM than worry about overwhelming the CE with just a few hundred FEs
only.

---

From: Tom Petch <[email-masked]>
Date: Mon, 16 Jan 2006 12:26:20 +0100

----- Original Message -----
From: "Joel M. Halpern" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 12, 2006 3:48 PM
Subject: Re: Model Draft: events comments

> an event.  One would not have an event tied to the bad IP header event.
From a management perspective, you are asking if there are single packets which
are so momentous in their impact that they need immediate attention.  I believe
there are, or will be, for example in signalling, such as congestion
notification or packets that indicate substantial changes to the topology.

I also hear a concern about how feasible it is to implement such as '3 events in
5 minutes' to which I suspect the answer is feasible when they are based on a
pre-existing
timers - such as TimeTicks in SNMP - and on shift/add, as opposed to anything
resembling decimal arithmetic.  Over the years, SNMP has got much more
sophisticated in the ability of a user to tailor what it is they need to know to
run a network - eg the work of rmon/disman - and it would be a shame to lose
that.

Tom Petch
<snip>

---

From: "Guo, Xiaoyi" <[email-masked]>
Date: Tue, 24 Jan 2006 12:00:46 +0800

hi, folks 

I and Joel work for one of the LFB Library in LFB library draft some 
days and now i think we need the workgroup comments. 

The following is the LFB library of the section 5.1.  IPv4 Validator LFB[1] .
And please comments.

cheers,
xiaoyi

[1].
   <LFBLibrary provides="IPv4ValidatLFB">
     <load library="Base"/>
     <metadataDefs> 
        <metadataDef> 
          <name>ErrorId</name> 
            <synopsis>Error Types.</synopsis> 
          <atomic> 
            <baseType>int32</baseType> 
            <specialValues> 
              <specialValue value="0x00020001"> 
                <name>WrongIpVersion</name> 
                <synopsis>the IP version wrong</synopsis> 
              <specialValue value="0x00020002"> 
                 <name>WrongLength</name> 
                 <synopsis>
                  the packet length is not as long as 
                  the header indicates
                 </synopsis> 
               <specialValue value="0x000200FF"> 
                  <name>otherError</name> 
                  <synopsis>The errors we not defined now</synopsis> 
                </specialValue>
              </specialValues> 
          </atomic> 
        </metadataDef> 
     </metadataDefs>     
     <LFBClassDefs>
       <LFBClassDef LFBClassID="0x00010003">
         <name>IPv4Validat</name>
         <synopsis>
           An LFB Class definition for validates the IPv4 packet.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
           <inputPort>
             <name>ValidatIn</name>
             <synopsis>
               Normal packet input.
             </synopsis>
             <expectation>
               <frameExpected>
                 <name>IPv4<name>
               </frameExpected>
               </expectation>
           </inputPort>
         </inputPorts>
         <outputPorts>
           <outputPort>
             <name>ValidatOut</name>
             <synopsis>
               Normal packet Output.
             </synopsis>
             <product>
               <frameProduced>IPv4 packet</frameProduced>
               </product>
           </outputPort>
           <outputPort>
             <name>FailOutput</name>
             <synopsis>
               The port to send packets that do not match any entries.
             </synopsis>
             <product>
               <frameProduced>
                 <ref>taggedFrame</ref>
               </frameProduced>
               <metadataProduced>
                  <ref>ErrorId</ref>  
               </metadataProduced> 
             </product>
      </outputPort>
         </outputPorts>
         <description>
           This LFB validates the IP version and header length
           fields, including verifying that the packet length 
           is at least as long as the header indicates.
         </description>
       </LFBClassDef>
     </LFBClassDefs>
   </LFBLibrary>