Subject: Re: [NPF-SW-FAPI] RE: [NPF-SOFTWARE] Reminder: FAPI Teleconference, Tuesday 4th

From: Alan DeKok <[email-masked]>
Date: Tue, 4 Nov 2003 15:33:26 -0500

John Renwick wrote:
> > I thought I'd try to put in writing some of the comments I had
> today about the ForCES model draft.  I see two major issues,
> and some smaller things.  The first major one is about metadata:

  I've cross-posted your NPF post to the ForCES list, where ForCES
related discussion belongs.  That list is open to all, and I suggest you
join it, if you haven't already done so.

> Section 4.4.4 lists, as one of the Capability attributes of
> LFBs: "Metadata pass-through limitations of the LFB."  If an
> LFB definition must indicate all metadata elements that are
> "passed through" it, it would have to refer to metadata that
> it is not at all concerned with, and maybe hasn't even been
> thought of at the time the LFB is defined.

  There is a simple solution to this problem.  The LFB's describe only
the metadata they care about.  All other metadata can pass through the
LFB unchanged, and un-examined.

>  If the FE must
> expose all this detail about the routing of metadata, does it
> suggest that there are metadata flow paths that are distinct
> from packet flow paths, that also need to be revealed in the
> LFB topology?

  Perhaps.  See the NPF hardware "lookaside" interface design.  Packets
do NOT flow through a piece of "lookaside" hardware, but that hardware
does produce metadata.  Something must manage that metadata, and
correlate it with the packet.  That management should be modelled.

>  On the other hand, why do we care at all?
> Isn't it enough to indicate, for each metadatum, which LFB
> produces it and which LFBs use it, and then assume that the
> implementation is functional enough to make each available
> in some way to the LFBs that need it?

  Making implicit assumptions is almost always bad.  The purpose of the
ForCES model document is to *model* the functionality of the FE.  Not
including large aspects of the FE in the model means that the model is
less effective

> The second major thing concerns ingress/egress ("hybrid")
> ports.  If a port represents both ingress and egress, making
> an LFB topology acyclic may require the port to be represented
> as two LFBs -- or two instances of the same LFB.  We have a
> similar problem in FAPI.  How will ForCES resolve this?

  The LFB topology may be acyclic, even if there *appear* to be loops
with it.

  See Page 23 of the document, under Figure 6:

  "It is important to point out that the LFB topology here is
   the logical topology that the packets flow through, not the
   physical topology as determined by how the FE hardware is
   laid out."

  What this means is that the even though a port LFB may be both ingress
and egress, there is NO cyclic flow of packets through that LFB, around
& around the model.  That is, at the egress, the packets LEAVE the LFB
model.  There are therefore no cycles.

> Other things:
>
> 1. At the top of page 5: "LFB topology is outside of the LFB
> model, but part of the FE model."  Can this be clarified?  It
> sounds self-contradictory.

  Each individual part in your car can be described in isolation.  Yet
no one claims that the method of interconnecting them to create a "car"
is part of the "engine" concept, or part of the "tire" concept.  That
interconnection is part of the "car" concept alone.

> 2. Section 4.1.2 talks about "Structures."  Are they like 'C'
> structures, whose layout in memory can be compiler-dependent,
> or are they meant to specify a machine-independent layout in
> memory or in a PDU?  This doesn't seem to be clear.

  It's not clear because the document does not yet describe them in
detail.

  The ForCES model group has been working on that part of the document.

>  How are
> they to be used?  If their only purpose is to give names and
> limits to data elements in the abstract, and not to specify
> byte-by-byte organization, that makes sense and I'm fine
> with it.

  I'm uncertain as to how anything will be interoperable if we don't
specify byte-by-byte organization of data within ForCES.

> 3. Section 4.3: the title is "Frame Format," but the description
> talks about packet types -- not formats.
>
> 4. Section 7.2: Can a dropper count packets?  The description
> should probably say so.

  Such comments should be posted to the ForcES list, or to the authors.

> 5. Section 7.3 says the Redirector LFB uses metadata to
> determine where to send each packet.  Why couldn't it use
> packet content as well?

  We have had this discussion ad nauseum in NPF.  Please see historical
NPF discussions as to why we have a seperate "classifier" block, and why
it's not appropriate to have a generic classifier inside of every block.

> 6. Section 7.4 & 7.5, Scheduler and Queue: it may be hard to
> make these work as separate LFBs, because as currently
> written, a scheduler can't see what's in a queue; it can only
> release backpressure and allow a packet to be sent to it.
> Depending on the scheduling algorithm, the scheduler may need
> to see attributes of the queue, such as whether it's empty or
> not and how big the first packet is, without actually moving
> the packet.

  The document is still in progress.  We welcome suggested replacement
text.

> 7. Section 7.6: Must every packet counted actually flow through
> a counter LFB, or can the LFB have implicit connections to
> events in other LFBs without having to direct all packets
> through it?

  Like metadata?

>  Can a counter LFB contain more than one counter,
> and if so, does it use metadata to determine which counters to
> increment?  And why would a counter LFB ever modify metadata?
> I don't understand the last paragraph; it sounds self-contradictory.

  A counter counts events, not the rate of change of events over time.

> 8. 7.7: Shouldn't the description of a Meter LFB say something
> about assigning a "color" to a packet?

  We welcome suggested text.

> 9. 7.8: The Classifier description reads as if it were written
> by two different authors who didn't agree.  First it says a
> classifier has just one output, then in the last paragraph it
> says it can have a different output for each class.  Which is
> true?

  The document is still in development.  Earlier versions of the
document had two classifier LFBs, which have been merged in this
version.  Not all of the relevant text was updated.

>  The next-to-last paragraph seems to be saying that only
> a classifier LFB may make decisions based on packet content
> (is that what "P" means?)

  Yes.  See Section 3.2 "LFB Modelling", where it defines P.

>, and other LFBs are only allowed to
> base decisions on "S, t, and M" (what are those?  I don't see
> them defined anywhere).

  They were defined in an earlier version of the document, and that text
was erroneously deleted.

>  Why must the classifier try to restrict
>  other LFBs in this way?  Turf issue?

  Grow up.  You've been party to NPF discussions where it was made clear
that having a classifier in every block was nonsense.  I suggest you
re-visit those discussions.

> 10. 7.9, 7.10: The Packet Modifier LFB description says there
> will be other LFBs for modifications needed by specific protocols.
> Then there's a Packet Header Rewriter for header modifications.
> All the legitimate packet modifications seem to be covered by
> LFBs that obey the rules of specific protocols, and that's good.
> What's left for the Packet Modifier to do?  It sounds tailor-
> made for hackers!  :-)

  If you say so.

  Alan DeKok.