Subject: [forces] Comments on draft-haleplidis-forces-packet-parallelization-00.txt

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 10 Oct 2012 06:38:40 -0400

Comments:
Generally, this is a useful extension

1)It is feasible to have a petri net kind of approach where
multiple packets or chunks are sent to parallel LFBs and the
merge proceeds after the first "success". Maybe make this a
capability on the merge LFB. You specify whether the merge should wait
for one or all LFB responses; you dont specify what the conditions
for proceeding are.

2) You say the merger will merge multiple packets/chunks.
If i am doing parallel TCAM lookups - I dont think i am looking
to merge packets. I am looking to collect results (with the single copy
of the packet).

3) Sentence which begins with "The FEObjectLFB must be able to specify for
the LFB to be used in a parallel mode:" is confusing. It makes it appear
like you are defining things - when in reality they already exist in the
FEObject today. I think you need to say something like
"The FEObject LFB currently specifies the LFBtopology to constitute of
blah... In order to support the parallelization, the following additional
componets are needed: ..."

4) ParallelType seems to have semantics for a config component as opposed
to a metadatum. Why should i care if it is a packet or a fragment of?
The "1 of N" semantics already tell me if i am receiving one or more
packets.

5) ParallelID seems to be what would be commonly be called a (transactional)
cookie. Why invent new nouns?

6) The granularity of the "valid" metadatum seems to need more than just
being a boolean. Could you make it 32 bit and have it carry one of the
pre-defined ForCES error codes?

7) I think you need to have use cases of real world use for both the
flood vs split processing. Figure #2 is a good start but seems problematic
with a meter LFB being run in parallel with a classifier; typically
those are run in series. A parallel set of TCAMs or regex engines will
be a good example
of either modes (shows the same LFB class in parallel but different instances).

cheers,
jamal

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Thu, 11 Oct 2012 00:57:48 +0300

Greetings Jamal,

Thanks for the comments.

Please see inline.

Regards,
Evangelos Haleplidis.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jamal Hadi Salim
> Sent: Wednesday, October 10, 2012 1:39 PM
> To: Haleplidis Evangelos
> Cc: Joel Halpern; [email-masked]
> Subject: [forces] Comments on draft-haleplidis-forces-packet-
> parallelization-00.txt
> 
> Comments:
> 1)It is feasible to have a petri net kind of approach where multiple
> packets or chunks are sent to parallel LFBs and the merge proceeds
> after the first "success". Maybe make this a capability on the merge
> LFB. You specify whether the merge should wait for one or all LFB
> responses; you dont specify what the conditions for proceeding are.
> 

[ΕΗ] Currently that is defined as a component in the Merger (MergeWaitType).
You can actually configure the Merger LFB on what you want it to do. Wait
for the first or wait for all. The first "success" would mean the first
valid I guess, therefore you must set the InvalidAction to 1 (continue merge
on invalids). Does this cover your use case?

> If i am doing parallel TCAM lookups - I dont think i am looking to
> merge packets. I am looking to collect results (with the single copy of
> the packet).
> 

[ΕΗ] There two cases in this situation:
1. In the case of chunks you have a merge for sure. All the chunks have to
merged to the original packet.
2. In the case of packets, I think it's still a kind of a merge. Getting
packets from all LFB instances in the parallel paths and you see that they
are all the same so you just keep one. 
Unless I'm confusing terms.

> 3) Sentence which begins with "The FEObjectLFB must be able to specify
> for the LFB to be used in a parallel mode:" is confusing. It makes it
> appear like you are defining things - when in reality they already
> exist in the FEObject today. I think you need to say something like
> blah... In order to support the parallelization, the following
> additional componets are needed: ..."
> 

[ΕΗ] Thanks, will change the text accordingly. What the text means is that
the LFBTopology will show the parallelization paths and the Supported LFBs
show supported LFBs and their relationship, but we need additional
information to specify which LFBs can be parallel with which LFBs and the
order of LFBs in a parallel.

> 4) ParallelType seems to have semantics for a config component as
> opposed to a metadatum. Why should i care if it is a packet or a
> fragment of?

[ΕΗ] It depends on what you want to do. Parallel Type is used in both the
Splitter and the Merger.
The Splitter gets it as a metadata to notify how the specific packet is
supposed to be processed - split into chunks or send the same packet in all
instances. The reason we opted for having the ParallelType as metadata is
that it is more generic. Each packet can be treated differently based in the
ParallelType. It can be done as a configurable component but that would
leave the type of parallelization same to all packets and up to the CE. What
would be the best option?

In the case of the Merger, as all packets enter from the same group input,
it is required by the merger to distinguish chunks from packets to correctly
perform the merging.

> 5) ParallelID seems to be what would be commonly be called a
> (transactional) cookie. Why invent new nouns?
> 

[ΕΗ] ParallelID seemed semantically better than the word cookie. 

> 6) The granularity of the "valid" metadatum seems to need more than
> just being a boolean. Could you make it 32 bit and have it carry one of
> the pre-defined ForCES error codes?
> 

[ΕΗ] I guess you mean the RESULT-TLV result values. I don't think that using
the pre-defined error codes are a useful thing to do. Unless we define a
subset of those errors, and even then I don't think we'll be able to cover
all cases. 
My concern is, is the error code valuable for the Merger? What would the
Merger do with such an information. Would it affect the merging process? Do
we need to define which error cases do not invalidate the merging process
and which do?
	
> flood vs split processing. Figure #2 is a good start but seems
> problematic with a meter LFB being run in parallel with a classifier;
> typically those are run in series. A parallel set of TCAMs or regex
> engines will be a good example of either modes (shows the same LFB
> class in parallel but different instances).
> 

[ΕΗ] Ok, thanks for the use cases. We will change the figures and text
appropriately.

> cheers,
> jamal
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 11 Oct 2012 07:37:43 -0400

Greetings Evangelos,

> on invalids). Does this cover your use case?

Maybe. I need to think about it a little more with some use case.
I think if you returned an error code instead, it should certainly cover it.

> Unless I'm confusing terms.

I was thinking of this from an implementation perspective:
The use cases playing in my head dont modify the packet - and the parralell
LFB instances are running look-aside interfaces; so the copy of the packet
stays with the sourcing LFB and the sourcing LFB also receives the responses
back (i.e it contains both the split and the merge functionality).

> order of LFBs in a parallel.

You also need to describe that the parallelized LFBs need to understand the
different metadata (valid in particular) and set them.

> instances.

Gets it from what? I think a use case would be useful - I dont see one.

>The reason we opted for having the ParallelType as metadata is
> that it is more generic.
>Each packet can be treated differently based in the
> ParallelType.

My view is the splitter would be very specific to one type or another.
There is nothing intelligent along the path which will set this metadata.
Only the splitter needs it.

>It can be done as a configurable component but that would

Refer to the above.

> it is required by the merger to distinguish chunks from packets to correctly

You have the count with "This is 1 of N"  semantics.
If there was only one chunk N == 1

> [ΕΗ] ParallelID seemed semantically better than the word cookie.

It doesnt sound better to me ;-> But: your call.

> [ΕΗ] I guess you mean the RESULT-TLV result values.

yes. They are standardized already.

> I don't think that using

It may not cover all cases - but will cover more than a boolean value.
When failure occurs knowing what happens as precisely as possible is useful.

> we need to define which error cases do not invalidate the merging process

Are you trying to save on bits?
When the ForCES error codes were being standardized I was against using
merely error codes - I wanted a string to describe what the error was
to accompany
the error code. My experience is when there are errors,
you need as much details as you possibly can get. Allows for ease of debugging.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 11 Oct 2012 08:01:29 -0400

Hi Joel,

On Wed, Oct 10, 2012 at 6:13 PM, Joel Halpern <[email-masked]> wrote:

> There is an important reason for looking at it as a merge even when it was multiple copies of the same packet.
> In many cases, we will get metadata from several branches.  We need to pass on all the metadata.  This does
> not apply if the processing rule is just "pass the first, drop the others", but is otherwise necessary.

Refer to the use case I provided in the earlier email (which is
derived from implementation experience).
I think your current underlying assumption is that the merging LFB
instance will need to do "something"
with the packet. In my use case the important detail is the metadata
(and if the model says the merger
received a packet that is fine too).

> There are some pieces we need to add:
> 1) When merging (slices or packets) if we get metadata from different packets with different values for
>the same metadatum, what will ther merger do?

There is one use case where different values of the metadata are a good thing.
There may be need to have a "list of metadata" merged/accumulated
(maybe that can be part of the earlier draft on complex metadata?).
Ex: If i took a packet and split it to several regex match LFB
instances, the merger may get metadata
"matched foo at offset X"  from all merged points. Something needs to
aggregate that info so it could be
used downstream.

> 2) We need to note that "pass the first, drop the others" still requires that the merger keep state (but not content)
>just as it would for a merge, since it needs to have the state for handling the later arrivals.

indeed.

cheers,
jamal

---

From: Joel Halpern <[email-masked]>
Date: Wed, 10 Oct 2012 18:13:24 -0400

In line for context... 

> From: Haleplidis Evangelos [mailto:[email-masked]] 
> Sent: Wednesday, October 10, 2012 5:58 PM
> To: 'Jamal Hadi Salim'
> Subject: RE: [forces] Comments on 
> draft-haleplidis-forces-packet-parallelization-00.txt
> 
> Greetings Jamal,
> 
> Thanks for the comments.
> 
> Please see inline.
> 
> Regards,
> Evangelos Haleplidis.
> 
...
> > merge packets. I am looking to collect results (with the 
> single copy 
> > of the packet).
> > 
> 
> 1. In the case of chunks you have a merge for sure. All the 
> chunks have to merged to the original packet.
> 2. In the case of packets, I think it's still a kind of a 
> merge. Getting packets from all LFB instances in the parallel 
> paths and you see that they are all the same so you just keep one. 

There is an important reason for looking at it as a merge even when it was multiple copies of the same packet.  In many cases, we will get metadata from several branches.  We need to pass on all the metadata.  This does not apply if the processing rule is just "pass the first, drop the others", but is otherwise necessary.
There are some pieces we need to add:
1) When merging (slices or packets) if we get metadata from different packets with different values for the same metadatum, what will ther merger do?
2) We need to note that "pass the first, drop the others" still requires that the merger keep state (but not content) just as it would for a merge, since it needs to have the state for handling the later arrivals.

...

Yours,
Joel