Subject: FW: [NPF-SW-FAPI] RE: [NPF-SOFTWARE] Reminder: FAPI

From: John Renwick <[email-masked]>
Date: Wed, 5 Nov 2003 10:51:25 -0600

Alan,

I apologize for the "turf issues" remark in my earlier email.
I can understand how that's a personal attack, even though I
didn't really mean it that way.  The statement I took issue with,
"...other blocks may make decisions based on the parameters S,
t, and M, but not on P," seems to contradict the previous
paragraph -- unless I understand "P" to mean the LFB examines
the entire packet or major parts of it.  I agree with the
statement in the previous paragraph, "...other FE LFBs MAY
perform simple classification on the packet...."

It hangs on the definition of "simple classification," I guess.
If you regard validating and interpreting one header at a time
as simple classification, then the forwarding plane could be
constructed of protocol-specific processing LFBs without the
need for a classifier LFB.  I'm not sure if the model is allowing
that or prohibiting it.

John

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]]
> Sent: Tuesday, November 04, 2003 2:31 PM
> To: [email-masked];
> "[email-masked]"@thunder.amsl.com
> Subject: Re: [NPF-SW-FAPI] RE: [NPF-SOFTWARE] Reminder: FAPI
>
>
> 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.