Subject: Re: [forces] comments #14

From: "Wang,Weiming" <[email-masked]>
Date: Sun, 9 Oct 2011 11:22:42 +0800

Hi all,

Thanks  to all guys' especially Jamal's contributions, we'v made quite lots of modification since last version of the draft.  I'm going to update  to a new version recent days. 
If you have any more comments, pls just respond to this list.

thanks a lot.
Weiming

----- Original Message ----- 
From: "Chuanhuang Li" <[email-masked]>
Subject: Re: comments #14

> Exactly, the original purpose is letting the LFB support dispatch function according to 
> arbitrary metadata in one BasicMetadataDispatch instance.
> Yes, maybe there is something we haven't considered before. If there are more than 
> one input metadata, how will the LFB do? Which metadata should be used to look 
> up the dispatch table? There is no contraints.
> So i agree to this modification.
> 
> Yours,
> Chuanhuang
> 
> ======= 2011-09-29 17:30:22 Wang,Weiming, wrote: =======
> 
>>Hi Chuanhuang, Jamal and Joel, 
>>
>>We currently only define a single tuple dispatch table for the BasicMetadataDispatch LFB.  For this purpose, I don't see the need for an array in array structure for it. Rather, we may only need to define two component for the purpose, something like below, pls comment it: 
>>
>>***********************
>>      <dataTypeDef>
>>         <name>MetadataDispatchTableType</name>
>>         <synopsis>Type for Metadata dispatch table.</synopsis>
>>         <array type="variable-size">
>>         <struct>
>>            <component componentID="1">
>>               <name>MetadataValue</name>
>>               <synopsis>metadata value.</synopsis>
>>               <typeRef>uint32</typeRef>
>>            </component>
>>            <component componentID="2">
>>               <name>OutputIndex</name>
>>               <synopsis>group output port index.</synopsis>
>>               <typeRef>uint32</typeRef>
>>            </component>
>>         </struct>   
>>           <contentKey contentKeyID="1">
>>           <contentKeyField>MetadataValue</contentKeyField>
>>           </contentKey>
>>         </array>
>>      </dataTypeDef>
>>
>>    <LFBClassDef LFBClassID="16">
>>         <name>BasicMetadataDispatch</name>
>>......  
>>        <outputPort>
>>            <name>ExceptionOut</name>
>>....
>>         
>>         <components>
>>            <component componentID="1">
>>                <name>MetadataID</name>
>>                <synopsis>the metadata ID for dispatching</synopsis>
>>            </component>
>>            <component access="read-write" componentID="2">
>>                  <name>MetadataDispatchTable</name>
>>                   <synopsis>Metadata dispatch table.</synopsis>
>>                   <typeRef>MetadataDispatchTableType</typeRef>
>>            </component>      
>>         </components>
>>       </LFBClassDef>  
>>***********************
>>
>>Accordingly，the description text for the BasicMetadataDispatch LFB is as follows, (Jamal especially) pls help to review it, thanks a lot.
>>
>>---------- 
>>5.5.1. BasicMetadataDispatch
>> 
>>The BasicMetadataDispatch LFB is defined to abstract the process in which a packet is dispatched to some output path based on its associated metadata value. 
>> 
>>5.5.1.1. Data Handling
>>   
>>The BasicMetadataDispatch has only one singleton input known as "PktsIn". Every input packet should be associated with a metadata that will be used by the LFB to do the dispatch. This LFB contains a Metadata ID component a dispatch table named MetadataDispatchTable, all configured by the CE. The Metadata ID specifies which metadata is to be used for dispatching packets. The MetadataDispatchTable contains entries of a Metadata value and an OutputIndex, specifying that the packet with the metadata value must go out from the LFB group output port instance with the OutputIndex. 
>> 
>>Two output LFB ports are defined. 
>> 
>>The first output is a group output port known as "PktsOut". A packet with its associated metadata having found an OutputIndex by successfully looking up the dispatch table will be output to the group port instance with the corresponding index. 
>>   
>>The second output is a singleton output port known as "ExceptionOut", which will output packets for which the data processing failed, along with an additional ExceptionID metadata to indicate what caused the exception. Currently defined exception types include: 
>> o There is no matching when looking up the metadata dispatch table.
>> 
>>As an example, if the CE decides to dispatch packets according to a physical port ID (PHYPortID), the CE may set the ID of PHYPortID metadata to the LFB first. Moreover, the CE also sets the PHYPortID actual values (the metadata values) and assigned OutputIndex for the values to the dispatch table in the LFB. When a packet arrives, a PHYPortID metadata is found associated with the packet, the metadata value is further used as a key to look up the dispatch table to find out an output port instance for the packet. 
>> 
>>Currently the BasicMetadataDispatch LFB only allows the metadata value of the dispatch table entry be 32-bits integer. A metadata with other types of value is not supported in this version. A more complex metadata dispatch LFB may be defined in future version of the library. In that LFB, multiple tuples of metadata with more value types supported may be used to dispatch packets.
>> 
>>5.5.1.2. Components
>> 
>>This LFB has two components. One component is MetadataID and the other is MetadataDispatchTable. Each row of the dispatch table is a struct containing a metadata value entry and the OutputIndex entry. Note that currently, the metadata value is only allowed to be 32-bits integer. The metadata value is also defined as a content key for the table. The concept of content key is a searching key for tables which is defined in the ForCES FE Model (RFC 5812).  See this document and also the ForCES Protocol (RFC 5810) for more details on the definition and use of a content key.
>>---------------------
>>
>>thanks,
>>Weiming
>>
>>
>>
>>
>>----- Original Message ----- 
>>From: "Chuanhuang Li" <[email-masked]>
>>
>>> Array in array, the XML defined as follows:
>>> 
>>> ***********************
>>>     <dataTypeDef>
>>>         <name>MetadataDispatchSubtableEntryType</name>
>>>         <synopsis>Entry type for the subtable of metadata dispatch table.</synopsis>
>>>         <struct>
>>>            <component componentID="2">
>>>               <name>MetadataValue</name>
>>>               <synopsis>metadata value.</synopsis>
>>>               <typeRef>uint32</typeRef>
>>>            </component>
>>>            <component componentID="3">
>>>               <name>OutputIndex</name>
>>>               <synopsis>group output port index.</synopsis>
>>>               <typeRef>uint32</typeRef>
>>>            </component>
>>>         </struct>   
>>>      </dataTypeDef> 
>>> 
>>>      <dataTypeDef>
>>>         <name>MetadataDispatchSubtableType</name>
>>>         <synopsis>Type for the subtable of metadata dispatch table. </synopsis>
>>>         <array type="variable-size">
>>>           <typeRef>MetadataDispatchSubtableEntryType</typeRef>
>>>           <contentKey contentKeyID="1">
>>>           <contentKeyField>MetadataValue</contentKeyField>
>>>           </contentKey>
>>>         </array>
>>>      </dataTypeDef>
>>> 
>>>      <dataTypeDef>
>>>         <name>MetadataDispatchType</name>
>>>         <synopsis>Entry type for metadata dispatch table.</synopsis>
>>>         <struct>
>>>            <component componentID="1">
>>>               <name>MetadataID</name>
>>>               <synopsis>metadata ID</synopsis>
>>>               <typeRef>uint32</typeRef>
>>>            </component>
>>>            <component componentID="2">
>>>               <name>MetadataDispatchSubtable</name>
>>>               <synopsis>Metadata dispatch table.</synopsis>
>>>            <array type="variable-size">
>>>               <typeRef>MetadataDispatchSubtableType</typeRef>
>>>               </array>
>>>            </component>
>>>         </struct>   
>>>      </dataTypeDef> 
>>> 
>>>      <dataTypeDef>
>>>         <name>MetadataDispatchTableType</name>
>>>         <synopsis>Type for Metadata dispatch table.</synopsis>
>>>         <array type="variable-size">
>>>           <typeRef>MetadataDispatchType</typeRef>
>>>           <contentKey contentKeyID="1">
>>>           <contentKeyField>MetadataID</contentKeyField>
>>>           </contentKey>           
>>>         </array>
>>>      </dataTypeDef>
>>> 
>>> Yours,
>>> Chuanhuang 
>>> 
>>> ======= 2011-09-23 10:43:15 Wang,Weiming, wrote: =======
>>> 
>>>>Pls provide a full XML definition so that we can review it again and write the text.
>>>>
>>>>thks,
>>>>Weiming
>>>>
>>>>----- Original Message ----- 
>>>>From: "Chuanhuang Li" <[email-masked]>
>>>>Subject: Re: comments #14
>>>>
>>>>
>>>>> Hi, all
>>>>> I think there is no sparse issue, whatever format we define this table as -- 
>>>>> array in array or just one array. We do not use metadata IDs as table indices.
>>>>> The table indices still are: 1,2,3,...... The metadata ID is the content of the 
>>>>> table (one of the member of the structure.). I prefer to the array in array definition 
>>>>> as Jamal mentioned.
>>>>> 
>>>>> name: MetadataDispatchTable
>>>>> type: MetadataDispatchTableType
>>>>> array of:
>>>>> {
>>>>>    MetadataID /*the ID value of the metadata.*/
>>>>>    array of:  
>>>>>    {
>>>>>       MetadataValue,
>>>>>       OutputIndex /*group output port index*/
>>>>>    }
>>>>> }   
>>>>> we use MetadataValue as the content key in inner table,.
>>>>> we use the value of MetadataID as the content key in outer table.
>>>>> 
>>>>> Yours,
>>>>> Chuanhuang 
>>>>> 
>>>>> ======= 2011-09-22 20:57:31 Wang,Weiming, wrote: =======
>>>>> 
>>>>>>Chuanhuang and Jamal,
>>>>>>
>>>>>>I'm ok with the definition. Moreover, as you mentioned, the MetadataID may have to be defined as a 'content key'. By use of the content key, we may avoid using it is the table index to look up the key, which, as Joel pointed, may not be dense enough.
>>>>>>
>>>>>>How about the solution?
>>>>>>
>>>>>>thks,
>>>>>>Weiming
>>>>>>
>>>>>>----- Original Message ----- 
>>>>>>From: "Jamal Hadi Salim" <[email-masked]>
>>>>>>Subject: Re: comments #14
>>>>>>
>>>>>>
>>>>>>Chuanhuang,
>>>>>>
>>>>>>Based on what Joel said (the sparsity issue) - I am open to leaving it as it was
>>>>>>as long as the text reflects the reasoning.
>>>>>>I will leave it up to the authors to make that call.
>>>>>>
>>>>>>cheers,
>>>>>>jamal
>>>>>>
>>>>>>On Thu, Sep 1, 2011 at 9:11 PM, Chuanhuang Li
>>>>>><[email-masked]> wrote:
>>>>>>> Hi,All
>>>>>>>
>>>>>>> As an alternative, i think we can define MetadataDispatchTable by using table in table as Jamal said.
>>>>>>> Pherhaps, this definition is more convinient.
>>>>>>> name: MetadataDispatchTable
>>>>>>> type: MetadataDispatchTableType
>>>>>>> array of:
>>>>>>> {
>>>>>>> MetadataID /*the ID value of the metadata.*/
>>>>>>> array of:
>>>>>>> {
>>>>>>> MetadataValue,
>>>>>>> OutputIndex /*group output port index*/
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> First, We use the ID value of the metadata to lookup the table (Note, not finding internal index,
>>>>>>> but the MetadataID member in the entry.), and will get a sub-table. Drop if non-existent.
>>>>>>> Next we lookup the sub-table using the metadata value to
>>>>>>> find the OutputIndex. Drop if non-existent.
>>>>>>>
>>>>>>> Yours,
>>>>>>> Chuanhuang
>>>>>>>
>>>>>>> ======= 2011-09-02 00:49:15 Jamal Hadi Salim, wrote: =======
>>>>>>>
>>>>>>>>Those are good reasons - and i will be happy if you kept the
>>>>>>>>representation as is
>>>>>>>>as long as you say something of whats below in the text.
>>>>>>>>
>>>>>>>>cheers,
>>>>>>>>jamal
>>>>>>>>
>>>>>>>>On Thu, Sep 1, 2011 at 10:08 AM, Joel M. Halpern <[email-masked]> wrote:
>>>>>>>>> I am probably missing a bit of context.
>>>>>>>>> As a general rule, we do not use metadata IDs as table indices. The reason
>>>>>>>>> is that they are allocated across all the uses of metdaa, so they are not a
>>>>>>>>> dense set. Using them as an index produces a large, sparse, table. Not
>>>>>>>>> particularly good.
>>>>>>>>>
>>>>>>>>> We can use the values of a metadatum as an index if that particular set of
>>>>>>>>> values is designed to be dense, and start from a very small number (0, 1, or
>>>>>>>>> so). Some metadata are designed that way, some aren't.
>>>>>>>>>
>>>>>>>>> Yours,
>>>>>>>>> Joel
>>>>>>>>>
>>>>>>>>> On 9/1/2011 9:33 AM, Wang,Weiming wrote:
>>>>>>>>>>
>>>>>>>>>> Fixed all except on the following point.
>>>>>>>>>> Chuanhuang,pls double check the possibility to use a table in table here.
>>>>>>>>>>
>>>>>>>>>> thanks,
>>>>>>>>>> Weiming
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Jamal Hadi Salim"<[email-masked]>
>>>>>>>>>>>
>>>>>>>>>>> The table contains entires of a Metadata ID, a Metadata value and an
>>>>>>>>>>> OutputIndex.
>>>>>>>>>>>
>>>>>>>>>>> The LFB uses all existing metadata associated with every input packet
>>>>>>>>>>> with their
>>>>>>>>>>> metadata IDs and metadata values as the content keys to look up the table
>>>>>>>>>>> to find out the relevant OutputIndex.
>>>>>>>>>>> If a packet failed lookup of the table, the packet will just be dropped
>>>>>>>>>>> inside the LFB.
>>>>>>>>>>>
>>>>>>>>>> Ok, now i realize my confusion was technical not editorial. It seems
>>>>>>>>>> sensible that
>>>>>>>>>> we should avoid content keys if we can get away with indexed tables. I am
>>>>>>>>>> sorry
>>>>>>>>>> if i am rehashing past discussion: Why was this not a table inside a
>>>>>>>>>> table indirection?
>>>>>>>>>> First you use the Metadata ID to index into table 1 to find the table for
>>>>>>>>>> that Metadata. Drop if non-existent. Next you lookup the second table
>>>>>>>>>> using the metadata value to find the OutputIndex. Drop if non-existent.
>>>>>>>>>
>>>>>>>
>>>>> 
>>>>> 
>>>>>
>>> 
>>> 
>>>
>

---

From: Kentaro Ogawa <[email-masked]>
Date: Tue, 11 Oct 2011 17:50:43 +0900

Hi Weiming,

I want to commend you for the outstanding contribution you have made.
Jamal, after Weiming updates the draft, can we move into WG last call?

cheers,
Ken

-------- Original Message --------

> From: "Chuanhuang Li"<[email-masked]>
>>> From: "Chuanhuang Li"<[email-masked]>
>>>
>>>>          <synopsis>Type for the subtable of metadata dispatch table.</synopsis>
>>>>> From: "Chuanhuang Li"<[email-masked]>
>>>>>>>>> On Thu, Sep 1, 2011 at 10:08 AM, Joel M. Halpern<[email-masked]>  wrote:

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 12 Oct 2011 09:04:44 -0400

> I want to commend you for the outstanding contribution you have made.

Excellent effort Weiming.

> Jamal, after Weiming updates the draft, can we move into WG last call?

Lets see the shape it is in before we go that path. I would like to see more
review outside the usual suspects. I think it should be in sufficient shape
I can ping some people to take a closer look - and we'll decide from there
if a new revision is needed.

cheers,
jamal

---

From: "Chuanhuang Li" <[email-masked]>
Date: Fri, 14 Oct 2011 10:56:04 +0800

Hi, All
   The attachments are the latest version XML files for LFB lib.
   Jamal, can you help us to check these files, especially the 
synopsis field of all elements. Thank you very much!

Yours,
Chuanhuang

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 14 Oct 2011 07:39:26 -0400

Chuanhuang,

Nothing obvious stand out in a cursory glance. I would say
go ahead and publish the draft and if anything interesting
shows up later we can fix it.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 14 Oct 2011 08:23:47 -0400

One important comment - please make absolutely sure this XML
validates against the Model schema. Quick check indicates it does not.

cheers,
jamal

---

From: "Chuanhuang Li" <[email-masked]>
Date: Fri, 14 Oct 2011 21:16:53 +0800

Thanks! I found one error in each file. That's because i havn't used the 
schema to check when i saved them.

Yours,
Chuanhuang	

======= 2011-10-14 20:24:35 Jamal Hadi Salim, wrote: =======

---

From: "Wang,Weiming" <[email-masked]>
Date: Sat, 15 Oct 2011 15:55:07 +0800

Hi Jamal and all,

When double check the GenericScheduler LFB update as proposed by Jamal as below, I propose to add a "priority" scheduling disipline to the scheduler. We can still make RR the default disipline but with a choice of priority disipline. 

Based on this, the GenericScheduler may be modified as below: 

Components:
(default access property is read-write)

name: QueueCount   /*the number of queues to be scheduled.*/
type: uint32
access: read-only

name: SchedulingDiscipline
defaultValue: 1 - RR
SchdDisciplineType, special value:
{
  1 - Round Robin (RR)
  2 - Priority,
 }

name:  QueuePriority
struct of
{
QueueID,
Priority,
}

name: QueueStats
 struct of
{
   QueueID,
   QueueDepthInPackets,
   QueueDepthInBytes
}

----
----
Capabilities: 

name: QueueLenLimit  /*Maximum length of each queue,the unit is byte.*/

name: DisciplinesSupported /*the scheduling disciplines supported*/
 
----
----
Events:
currently none
----

Note that, the QueuePriority component is effective only when the Priority disipline is selected. 

Pls comment !

thanks,
Weiming

----- Original Message ----- 
From: "Wang,Weiming" <[email-masked]>
>> 51) 5.5.2.1.
>> Dont wanna spend too much time on this, RR is fine - but isnt
>> priority based queueing the scheme defined as a basic scheduler?
>> In the case of IPV4 Tos/DSCP etc (RFC 1812?) is used to select the queue.

> Change the 5.5.2.2 paragraph from 
> The SchedulingDiscipline component is for the CE to specify a scheduling discipline to the LFB. Currently defined scheduling disciplines only include FIFO and Round Robin (RR). When a FIFO discipline is applied, it is requires that there is only one input  port instance for the group input. If the user accidentally defines multiple input port instances for FIFO scheduling, only packets in the input port with lowest port index will be scheduled to output port, and all packets in other input port instances will just ignored. Note that if the generic scheduler LFB is defined only one input port instance, the default scheduling discipline is FIFO. If the LFB is defined with more than one input port instances, the default scheduling discipline is round robin (RR).
> to:
> The SchedulingDiscipline component is for the CE to specify a scheduling discipline to the LFB. Currently defined scheduling disciplines only include Round Robin (RR) strategy. The default scheduling discipline is RR then.
> 
> 
> Chuanhuang, pls doble check it.
> 
>> 
>> 52) 5.5.2.3.
>> "The supported scheduling disciplines types by the FE, currently
>> maximum 6."
>> 
>> Where did the magic number 6 come from?
> 
> I have deleted the item. Chuanhuang, pls make sure. Also, pls double check if the following capabilites are still effect? I know queue number limit for group is decided by the port properties? 
> 
>   o A queue number limit, which specify the limit of the maximum supported number of queues, which is also the maximum number of input port instances.
> 
>   o The queue length limit providing the storage ability for every queue.
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 15 Oct 2011 09:02:51 -0400

Sounds ok to me.
Question: Does RR require specifying the quantum used? At least what the quantum
is needs to be specified i think as a settable component.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 15 Oct 2011 12:17:23 -0400

Round Robin usually has a quantum of 1 packet.  That is not usually setable.
There are other disciplines which use other basis, trying to send 
several short packets if they are on the same queue before moving to the 
next.  But that is not round-robin.

Yours,
Joel

On 10/15/2011 9:02 AM, Jamal Hadi Salim wrote:
> On Sat, Oct 15, 2011 at 3:55 AM, Wang,Weiming<[email-masked]>  wrote:
>> Hi Jamal and all,
>>
>> From: "Wang,Weiming"<[email-masked]>
>>>> 51) 5.5.2.1.
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces

---

From: "Wang,Weiming" <[email-masked]>
Date: Sun, 16 Oct 2011 00:54:47 +0800

If the quantum is considered to be used quite commonly,  we may define a WRR(Weighted RR) as the default discipline. In this way, a RR is a special case of WRR only. 

If we want to define such WRR as the default discipline, we only need  to plus one setable component called QueueWeight as: 

Component name: QueueWeight
struct of
{
QueueID;
Quantum (unit32, in the unit of packets)
}

Note that this QueueWeight component can also be applied  to Priority discipline to make a weighted priority based discipline.

Also note that, althought the quantum and the priority parameters can be put together in one component, it may be better to separate them to two components, for the priority is only for Priority discipline while the quantum will be applied to all types of disciplines, thinking that they may all be set to 1 to make the weights disappear. 

Is above thought feasible?

thanks,
Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 15 Oct 2011 15:19:59 -0400

On Sat, Oct 15, 2011 at 12:54 PM, Wang,Weiming <[email-masked]> wrote:
> If the quantum is considered to be used quite commonly,  we may define a >WRR(Weighted RR) as the default discipline. In this way, a RR is a special case of WRR >only.
>
> Note that this QueueWeight component can also be applied  to Priority discipline to make >a weighted priority based discipline.
>
> Also note that, althought the quantum and the priority parameters can be put together in >one component, it may be better to separate them to two components, for the priority is >only for Priority discipline while the quantum will be applied to all types of disciplines, >thinking that they may all be set to 1 to make the weights disappear.
>

Priority tends to mean "strict" ordering i.e the highest priority
could starve the
lower priority queues. So I dont think it would work for generalizing.
It seems you may end up having the quantum and Priority be a union or
have them as separate components  - likely not something named QueueWeight
for priority case. Ive always thought it would have been sufficient to just
define strict priority (RFC 1812 may be old but i think thats the only queueing
scheme it talks about).

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Sun, 16 Oct 2011 09:12:18 +0800

Hi  Jamal, Chuanhuang, and all,

I agree to limit the priority discipline only to strict priority discipline.  To speed up the discussion, I udate the definition as below: 

Components:

name: SchedulingDiscipline
defaultValue: 1 - WRR
SchdDisciplineType, special value:
{
  1 - Weighted Round Robin (WRR)
  2 - Strict Priority,
 }

name: QueueWeight /*specifically for WRR */
 array of struct
 {
 QueueID;
 Quantum (unit32, in the unit of packets)
 }

name:  QueuePriority /*specifically for Strict Priority */

array of struct
{
QueueID,
Priority,
}

name: QueueStats
 array of struct
{
   QueueID,
   QueueDepthInPackets,
   QueueDepthInBytes
}

----
----
Capabilities: 

-----------

Pls continure to comment. Thanks a lot.

BTW: Chuanhuang, can we save the use of the QueueID, for it seems the QueueID is actually the input port index? If saved, something would be look like: 

name: QueueWeight
 array of 
 {
  Quantum
 }

name:  QueuePriority
array of 
{
Priority
}
Where the array index corresponds to the queue ID as well as the input port index. Is this ok?

Weiming

----- Original Message ----- 
From: "Jamal Hadi Salim" <[email-masked]>
Subject: Re: [forces] comments #14

cheers,
jamal

---

From: "Chuanhuang Li" <[email-masked]>
Date: Sun, 16 Oct 2011 19:55:24 +0800

Hi, All
First, i suggest to keep the "QueueID". That's because QueueID(the inputport index) 
is maintained by FE, not CE. It will be more convinent for CE to set the component value, 
when CE knows the ID explicitly.

If this LFB supports SP scheduling discipline and we define a priority component, we need constrain 
the value of this component. (If user sets different queues with the same priority, how will the scheduler 
work? The things may become complicated. )

When changing the definition of this LFB, We need notice this LFB is a basic definition.  
As the "data handling" section says, "More complex scheduler LFBs may be defined with 
more complex scheduling disciplines by succeeding this LFB.". 

After In-depth consideration, In my mind, i think the definition is as simple as possible. We needn't 
define SP. We only define RR (not WRR). As Joel said, we won't set the quantum (Just specify 
this in the text.) . WRR and SP etc can be expanded by this LFB. 
Sorry, maybe this opinion is different from my previous one. 

Of course, the modified definiton is also no problem to me. 

Yours,
Chuanhuang

======= 2011-10-16 09:12:24 Wang,Weiming, wrote: =======

---

From: "Wang,Weiming" <[email-masked]>
Date: Sun, 16 Oct 2011 22:14:53 +0800

I just see some weakness in current QueueID concept . 

In current text, we say that "Every queue is marked with a queue ID, and the queue ID is exactly the same as the index of corresponding input port instance." By saying this, we actually implicitly mean the QueueID is just the ID of the input port index. Then, in defining some component, we explicitly use the port index as the explicit "QueueID". It seems not a good design to do so.

Two alternative ways to avoid above weakness:

1) implicitly keeping the queue ID as the port index, and keeping it also in the definition of component, i.e., to map the port index to array index to refer to a queue ID, for instance, array[i]  refers to queue[i]. In this way, we done have to mention "QueueID" in any component.

2) explicitly assigning a "QueueID" to a queue. In this way, a "QueueID" can be used in any component. To assign an input queue a "QueueID", a component is needed, something like:

Component name: QueueIDs
read-write;
array of
{
QueueID;
}

or

Component name: QueueIDs
read-write;
array of struct
{
InputPortIndex;
QueueID;
}

thanks,
Weiming

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 16 Oct 2011 20:54:57 -0400

We probably should maintain queueID.  But the reason is more complex.
On some systems, the FE will instantiate all the queues.  In some 
systems they will instanatiate some of the queues, while the CE creates 
others.  and on yet other systems, the CE will completely control the 
queue setup.  So we need the QueueID to be read-write.

Yours,
Joel

On 10/16/2011 7:55 AM, Chuanhuang Li wrote:
>> On Sat, Oct 15, 2011 at 12:54 PM, Wang,Weiming<[email-masked]>  wrote:
>>> If the quantum is considered to be used quite commonly, we may define a>WRR(Weighted RR) as the default discipline. In this way, a RR is a special case of WRR>only.
>>>
>>> Note that this QueueWeight component can also be applied to Priority discipline to make>a weighted priority based discipline.
>>>
>>> Also note that, althought the quantum and the priority parameters can be put together in>one component, it may be better to separate them to two components, for the priority is>only for Priority discipline while the quantum will be applied to all types of disciplines,>thinking that they may all be set to 1 to make the weights disappear.
>>>

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 17 Oct 2011 12:20:19 +0800

Jamal, 

What's your opinion on whether we should define the quantam and the strict priority currently, or just leave it later for extension use of the LFB?

thanks,
Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 18 Oct 2011 11:51:33 -0400

I think we can leave it for later extensions of the LFB. I was even being
more extreme than that - just define a strict prio scheduler (but it is clear
i am not going anywhere with that view ;->).

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 18 Oct 2011 11:54:13 -0400

Chuanhuang,

Another little issue:
You are using a  uint8 type which is not defined anywhere.
Unfortunately, I dont think  tools that do schema validation will catch
such issues or am i mistaken?

cheers,
jamal

---

From: "Chuanhuang Li" <[email-masked]>
Date: Wed, 19 Oct 2011 19:01:47 +0800

I have changed uint8 to uchar. I taked it for granted before. Thanks!

Yours,
Chuanhuang	

======= 2011-10-18 23:55:09 Jamal Hadi Salim, wrote: =======

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 20 Oct 2011 10:31:36 +0800

Thanks  for Jamal's reply. I think the only left question for the Generic Scheduler LFB is how we should define the QueueID.  We were using the inputport index as the default QueueID. Pls comment if we should change it to an explicit way by defining a more component like below:

name: QueueIDs 
array of struct
 {
 InputportIndex;
 QueueID;
 } 

Or, we just leave it as before?

After the issue is solved, I think we can close the issue.

thanks,
Weiming

----- Original Message ----- 

cheers,
jamal

---

From: "Chuanhuang Li" <[email-masked]>
Date: Fri, 21 Oct 2011 10:05:50 +0800

I think we needn't define such component. Just leave it as before.
About the description of "SchedulingDiscipline" component in the text, 
we need add the text like this: If user want to define a complex scheduler,
such as strict priority, weight round robin etc, this LFB will be succeeded, 
at the same time, the type of this component also need to be extended. 
In the scheduler instance, the value of this component must be one of the 
scheduling disciplines supported as showed in the capability.

Yours,
Chuanhuang
======= 2011-10-20 10:33:06 Wang,Weiming, wrote: =======

---

From: "Wang,Weiming" <[email-masked]>
Date: Sat, 22 Oct 2011 15:10:01 +0800

As a result, I propse to have the following definition for the GenericScheduler LFB: 

-------------
Components:

name: QueueStats
 struct of
{
   QueueID,
   QueueDepthInPackets,
   QueueDepthInBytes
}

----
----
Capabilities: 

----
----
Events:
currently none
--------------------

The LFB description is proposed as below: 
----------
1.1.1. GenericScheduler 
 
This is a preliminary generic scheduler LFB for abstracting a simple   scheduling process.
 
1.1.1.1. Data Handling
 
There exist various kinds of scheduling strategies with various implementations. As a base LFB library, this document only defines a preliminary generic scheduler LFB for abstracting a simple scheduling process. Users may use this LFB as a basic scheduler LFB to further construct more complex scheduler LFBs by means of    inheritance as described in RFC 5812 [RFC5812].
 
Packets of any arbitrary frame type are received via a group input known as "PktsIn" with no additional metadata expected. This group input is capable of multiple input port instances. Each port instance may be connected to different upstream LFB output. 
   
Multiple queues reside at the input side, with every input LFB port instance connected to one queue. Every queue is marked with a queue ID, and the queue ID is exactly the same as the index of corresponding input port instance. Scheduling disciplines are applied to all queues and also all packets in the queues.
   
Scheduled packets are output from a singleton output port of the LFB knows as "PktsOut" with no corresponding metadata. 
 
More complex scheduler LFBs may be defined with more complex scheduling disciplines by succeeding this LFB. For instance, a priority scheduler LFB may be defined by inheriting this LFB and defining a component to indicate priorities for all input queues.
   
1.1.1.2. Components
 
The QueueCount component is defined to specify the number of queues to be scheduled.

The QueueStats component is defined to allow CE to query every queue status of the scheduler. It is an array component and each row of the array is a struct containing a queue ID. Currently defined queue status includes the queue depth in packets and the queue depth in bytes. Using the queue ID as the index, the CE can query every queue for its used length in unit of packets or bytes. 
 
1.1.1.3. Capabilities
 
The following capability is currently defined for the GenericScheduler. 
   o The queue length limit providing the storage ability for every queue.
  
1.1.1.4. Events
   
This LFB does not have any events specified.
----------------------------

Pls make the final comment and then Chuanhuang may change the xml file. 

thks,
Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 24 Oct 2011 07:37:32 -0400

Sorry for not responding sooner. At this point my brain cells are not
even focusing
on the little details - I am thinking we should make the change as it is below
and let folks do more intricate reviews after the publication.
If there are no more challenges lets go ahead and publish.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 29 Oct 2011 09:43:43 -0400

Chuanhuang,
There is another issue with the XML.
The xml you sent earlier defined and used QueueDepthType.
But in the draft version 6, QueueDepthType is being used but not defined.

Can you please make sure the two are in sync for next release?

cheers,
jamal

---

From: "Chuanhuang Li" <[email-masked]>
Date: Sat, 29 Oct 2011 23:14:38 +0800

I found the error, Thanks!  That's because of the modification of GenericScheduler definition.
In the BaseType library, 
      <dataTypeDef>
         <name>QueueStatsTableType</name>
         ......
           <typeRef>QueueDepthType</typeRef>
         </array>
      </dataTypeDef>    

should change to:

      <dataTypeDef>
         <name>QueueStatsTableType</name>
         ......
           <typeRef>QueueStatsType</typeRef>
         </array>
      </dataTypeDef>    

Do we need release the new version right now?

Yours,
Chuanhuang

======= 2011-10-29 21:44:37 Jamal Hadi Salim, wrote: =======

---

From: Jamal Hadi Salim <[email-masked]>
Date: Sat, 29 Oct 2011 11:48:54 -0400

No need to release a new version just for that one change.
Maybe we can have the XMLs available somewhere for download.
Just put it in your recipe for next release to always go through the
XML and make sure everything is fine.

cheers,
jamal