Subject: Re: WG question: Accept draft-yang-forces-model-02.txt as WG doc?

From: "Yang, Lily L" <[email-masked]>
Date: Mon, 28 Jul 2003 10:38:26 -0700

I think mostly to ensure packet are properly sequenced without any race condition. 

> -----Original Message-----
> From: Steven Blake [mailto:[email-masked]]
> Sent: Monday, July 28, 2003 9:23 AM
> To: Forwarding and Control Element Separation
> Cc: Yang, Lily L
> Subject: Re: WG question: Accept draft-yang-forces-model-02.txt as WG
> doc?
> 
> 
> On Sun, 2003-07-27 at 18:09, Yang, Lily L wrote:
> 
> > Hi, Weiming --
> > Thanks for your comments. 
> > Regarding your comment #1) below, I think you are right 
> that we didn't pay > close attention to the intersected 
> connectionin in Fig 3(a). What is funny 
> > was that at Vienna during the FE model discussion, some poeple
> > including myself objected Zsolt&Steve's statement in their 
> draft that
> > "the model allows for connecting more than one LFB output 
> to a single
> > LFB input" but I guess I didn't realize that we are doing 
> exactly that
> > in our own draft!
> > I think we need to put a mux block there to connect the two 
> outputs from
> > two blocks into one input for classifier.
> >  
> > Thanks for catching this!
> > Lily
> 
> I don't understand what problem a mux block is supposed to solve.
> 
> 
> Regards,
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Steven L. Blake               <[email-masked]>
> Ericsson IP Infrastructure                +1 919-472-9913
>

---

From: Steven Blake <[email-masked]>
Date: Mon, 28 Jul 2003 15:06:17 -0400

> I think mostly to ensure packet are properly sequenced without any race

We are talking about topological abstractions, so without defining some
behavior on the part of the mux, I don't see how it is going to help one
way or another.

Here are the two alternatives:

a) +---+        +---+
   | A |------->| C |
   +---+   +--/ +---+
           |
   +---+   |
   | B |---+
   +---+

b) +---+        +---+      +---+
   | A |------->|Mux|----->| C |
   +---+   +--->|   |      +---+
           |    +---+
   +---+   |
   | B |---+
   +---+

Could you illustrate an example where packets could get resequenced in
(a) that is solved by (b)?

Regards,

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Jul 2003 15:21:01 -0400

> behavior on the part of the mux, I don't see how it is going to help one

  I agree.  However, if we do not have an explicit MUX, then we will
have no way of being able to configure or control the process of merging
multiple packet streams into one.

  In other words, implicit ordering is bad.  It's non-configurable, it
can't be modelled, and it's variable across implementations.

...
> (a) that is solved by (b)?

  In (a), with the MUX, you can *guarantee* packet sequencing.  In (b),
without a MUX, you cannot.

  A simple example would be a MUX variant which has the concept of
"priority".  Packets from input 'i' are preferred over packets from
input 'i + 1'.  This concept cannot be modelled without a MUX.

  Alan DeKok.

---

From: Steven Blake <[email-masked]>
Date: Mon, 28 Jul 2003 15:54:05 -0400

> input 'i + 1'.  This concept cannot be modelled without a MUX.

Implicit in your response are the assumptions that different paths
through the forwarding graph model have different forwarding latencies
associated with them, that latency difference might exceed the minimum
inter-packet interval, and hence that there may be more than one packet
flowing through the LFB topology at any given instant.  Some
implementations may need to model this, but some will not (e.g., those
that are single threaded or are strictly pipelined).

To really solve the sequencing problem, the mux in your implementation
will need a scheduling algorithm, and queues (and queue management
parameters) associated with each input, so the LFB model for this
assemblage won't be simple.

I would still prefer that the model schema permit multiple inputs to mux
onto a single output, just to avoid the need for an otherwise useless
FIFO mux LFB, and of course to provide the LFBs necessary to correctly
model a packet stream mux with scheduling and queueing for those
implementations that need it.

Regards,

---

From: Alan DeKok <[email-masked]>
Date: Tue, 29 Jul 2003 11:29:00 -0400

> that are single threaded or are strictly pipelined).

  I agree.

> assemblage won't be simple.

  There are already queue blocks in the model, so that may be modelled.

> implementations that need it.

  The purpose of the model is to model FE hardware.  I'm unaware of any
hardware where you can simply tie N lines together, and feed it into one
chip.  If there are multiple data streams, then there are multiple
inputs to the chip, or the chip has one input, and there is an external
MUX.

  My concern here is again that having an *explicit* model is better
than a model with implicit information.  We can always update the
explicit model to remove things which aren't necessary.

  But the details of the blocks are a matter for continued discussion.
I will add your comments to the draft as "matters to resolve".

  My reason for putting *more* blocks in the document, rather than
fewer, was to highlight the uncertainties and disagreements surrounding
the modelling concepts.  If there is consensus that some blocks are
unnecessary, or that they should be changed, then the model document can
be updated to reflect that consensus.

  Alan DeKok.

---

From: Alistair Munro <[email-masked]>
Date: Tue, 29 Jul 2003 16:43:48 +0100

Hi Alan,

>   The purpose of the model is to model FE hardware.

I have to disagree with this. It is an abstraction that lets a CE
communicate with a FE across boundaries of location and address space.

I don't believe it can model my hardware, especially as my FE is software...

Regards,

Alistair

--
Alistair Munro,
Principal Engineer, U4EA Technologies Ltd.
City Point, Temple Gate, Bristol, BS1 6PL, U.K.
E-mail: [email-masked]
Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile)
+44-7974-922-442;
Fax: +44-117-373-6751
Web: http://www.u4eagroup.com

---

From: Alan DeKok <[email-masked]>
Date: Tue, 29 Jul 2003 12:07:13 -0400

> I don't believe it can model my hardware, especially as my FE is software...

  OK, that statement was a little narrow.

  The purpose of the model is to model FE functionality.

  Alan DeKok.