Subject: Re: [forces] Comments: draft-haleplidis-forces-packet-parallelization-01

From: "Haleplidis Evangelos" <[email-masked]>
Date: Mon, 1 Apr 2013 17:12:30 +0300

Greetings,

Thank you for the comments.

Please see inline.

Regards,

Evangelos Haleplidis.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dave Hood
Sent: Sunday, March 17, 2013 6:22 PM
To: [email-masked]
Subject: [forces] Comments:
draft-haleplidis-forces-packet-parallelization-01

The use case for chunk processing is not obvious, and the references section
does not obviously cite a place where such a use case might be described. An
example would be helpful.

Some documentation of cilc (is that correct?) should also appear in the
references. 

[ΕΗ] One use case for chunk processing could be calculating a Hash list in
parallel, we will add this in the references, as well as for cilc.

In ParallelLFBType

<snip />

<component componentID="5">

<name>AllowedParallelAfters</name>

<synopsis>List of LFB Classes that this parallel LFB

class can follow in a parallel pipeline</synopsis>

<snip />

<component componentID="6">

<name>AllowedParallelBefores</name>

<synopsis>List of LFB Classes that this LFB class can

follow in a parallel pipeline</synopsis>

<snip />

Presumably the first synopsis should read precede, rather than follow?

[ΕΗ] Yes, you're right, thank you.

Tunneling metadata in case of nested parallelization: this would presumably
require the complex metadata proposed in
draft-haleplidis-forces-model-extension-01? . which therefore should also be
cited in the text and listed in the references. Would a tunneledMetadata
typedef be needed? 

[ΕΗ] Not necessarily. Metadata is defined for LFBs that consume/produce
metadata. Since tunneling metadata is not produced/consumed in tunneling it
does not need to be defined. Such an implementation could be done either by
passing metadata along with each packet/chunk as is. However now that you
mention it, in order to identify level of tunneling in case we have multiple
nesting parallelization we could add a nesting level metadata - the merger
should consume the metadata with the larger value of the nesting level. The
splitter when seeing parallel metadata will create metadata with +1 nesting
level.

Dave