Subject: RE: [Forces-protocol] issue 1: packet encoding

From: "Putzolu, David" <[email-masked]>
Date: Mon, 8 Mar 2004 22:42:34 -0800

Avri wrote >
> I have a general question about headers, is there any feeling in this 
> group that a common header could not be arrived at.  If not then we 
> could move on to other issues.  The reason I ask is that one 
> can spend 
> a whole lot of time fine tuning a header to be just right.  If there 
> are as of yet unresolved issues on the header, can anyone list them?

I agree with Avri, and like others I am having a hard time 
keeping up with all the different discussions.  So if 
people are comfortable with it, I suggest using a notation 
similar to what Weiming mentioned in issue 100, perhaps 
marking this one as, "Agreed to general outline of common 
header, details to be resolved later" and moving on to
another issue.  Perhaps preserve the last header(s) that 
Jamal and Hormuzd sent as the basis for the later detailed
discussions.

Cheers,
David

_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

---

From: Jamal Hadi Salim <[email-masked]>
Date: 09 Mar 2004 06:10:05 -0500

On Tue, 2004-03-09 at 01:42, Putzolu, David wrote:
> I agree with Avri, 

On the one hand i wanna say lets skip so we can make progress.
OTOH, I am a little worried that the gaps in point of view
are so huge that this will cause problems later. 
The only way we can close faster is if ontopic emails are addressed in
the fastest possible way.

On a personal level i am trying to prioritize responding to things
on this list. But sometime i get a little discouraged. Example my last
emails on topic 0 and topic 1 have not been responded to for at least
24 hours. Actually they have been a response which happens to be off
topic. This worries me because i dont think we will make the deadline.
If theres 10-12 serious issues and we have about 10 days to go
AND we havent closed a single issue up to now --> theres _no way_ 
we can meet the deadline. We need to close 2 issues a day.

Of course a brute force solution is to say theres desire to reach a
compromise and stop there. But this in itself is dangerous and i
would not prefer to go that route.

So at the moment i am at a loss. Maybe the approach of listing issues
which need to be agreed on is not the right one? What thoughts do people
have on this? Other proposals that have been made so far that received
no traction are:
a) each protocol draft to list what they cant live without,
b) Each protocol draft to list their implementation experiences and
say what they found useful and what wasnt.

> and like others I am having a hard time 
> keeping up with all the different discussions.  

Yes, this has been an issue but is general to any email or usent
discussuions - problem is someone starts going off 
topic then other people respond. And the cycle continues. 

The best way to run "meetings" over email are:

Rule 0: have an agenda (list of topics to discuss). We have this
Rule 1 is to have a running topic (eg currently issue 1 and 0 are
ontopic). No other topic is to be discussed. We are trying this.
Rule 2 is not to respond to currently-offtopic emails. This is typically
the easiest rule to break on email or usenet because of human nature.
Naturally this has been the most broken rule. 
Rule 3 is once in a while people need to be reminded they are off topic.
(I have tried to do this in personal emails as well as on the list.)
Rule 4 is if the content does not reflect the subject line, change the
subject line (like i just did with this email).

I could almost say we are getting close to following the above; I
counted and only 2 emails were offtopic out of last 6 as opposed to
6 out 10 before that.

cheers,
jamal

---

From: Alex Audu <[email-masked]>
Date: Tue, 09 Mar 2004 09:39:15 -0600

Jamal, All,

Let Hormuzd moderate the discussion topics.  You have tabled the first 
two issues.
That is fine.  So we discuss
0) Application Addressing and
1) Header Encoding.

Issue 0: Application Addressing--
I think we have some concensus on Application Addressing:
a) We don't address LFBs in the common header, but do so in the 
appropriate TLVs.
     (I believe Jamal and Weiming refered to this as hierarchical 
addressing)
b)  (any more refinements ?? )

Regards,
Alex.

---

From: Jamal Hadi Salim <[email-masked]>
Date: 09 Mar 2004 11:03:32 -0500

On Tue, 2004-03-09 at 10:39, Alex Audu wrote:
> Jamal, All,
> 
> Let Hormuzd moderate the discussion topics. 

Is there a good reason for this? 

>  You have tabled the first two issues.

You are missing a lot of details. Normally, i would have explained
things, but this is one of the reasons we are not moving fast.
Please go back onto the thread and read again then summarize.

cheers,
jamal

---

From: Alex Audu <[email-masked]>
Date: Tue, 09 Mar 2004 10:04:30 -0600

On Issue 1: packet encoding,  it is easy to come to concensus on this 
one.  So far, the train
thoughts is per the attachment to this e-mail.

Issues raised:
1) Avri raised issue of indicating an error with an error flag on the 
header.

Comment:  That is certainly one way to convey error conditions. But 
experience has
shown that if you do that, you force your protocol software to check 
this flag for every
message that comes in (to ascertain if it is error message or not), 
before proceeding. This
is an incredible  wate of processor cycles since an error condition is 
really an exception
condition.

Carrying an error indication with an error TLV is much better.   It is 
like an error color
code; you only do error processing if that color shows up.  And all the 
other messages
are handled similarly.  This could easily be the difference between a 
protocol  that is
twice as fast and efficient  compared to an otherwise poorly designed one.

Regards,
Alex.

>counted and only 2 emails were offtopic out of last 6 as opposed to

I don't know what the flags could be used for. The TypeID could be used for
siganling the type of data encoding explicitly,  (i.e. XML, ASN.1 etc).
My preference will be the following.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                    0               1               2             3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |vers   |eType  | prio| reservd |  msgClass     |   msgType     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       message length                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source xID           | Destination xID               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
1) version # indicates the version of the protocol.
2) the type of encoding comes next.
3) the priority of the message comes next.
4) the command has been divided into message class and type to ease management and handling.
5) the source and destination are now both 16 bits each. This allows up to 64K FEs. That is cool!
6) the length is now 32 bits long. This will accommodate flow measurement messages which
   tend to be huge,  from FE to CE.  It will also accommodate large table dumps from CE to
   FE.
7) then comes the sequence number.

Any comments?

Regards,
Alex.

> Jamal,
>
> Before I give my comments, I would like to say that I appreciate the
> fact that you did not copy/paste the netlink header from your draft over
> here! That is a very positive sign to me, lets try to stick to the best
> technical solution rather than pushing our own protocol implementations.
> That's the best way to make progress on this merger!!
>
> Here are my views on this issue, particularly the common header:
>
> Command: Agree this is needed. We think 8-12 bits will be more than
> sufficient for this depending on whether it is subdivided. We have
> sub-divided this field into Class/type...this is an OO approach, seemed
> pretty neat. However, I am personally fine with having a single field
> for this, no problem with that.
>
> Length: Agree needed and agree with size.
>
> xIDs: Agree this is needed. More detailed comments on length, semantics
> in my previous email.
>
> Sequence No: Agree needed and agree with size.
>
> Flags/Priority: We need 2-3 bits for priority in every message. I don't
> think we need any other flags in all messages.
>
> Typeid: This is one field I don't think is needed in all messages. I am
> not sure why this is needed at all cause, we will be using the Model and
> LFB IDs to address processing functional blocks on the FEs.
>
> Missing field: Version (2-4 bits): This is present in all protocols, and
> is generally included in most IETF protocols. Its usually the 1st field.
>
> General comment: Lets try to be stingy on the size of the header and its
> fields since this will be included in all ForCES messages.
>
> Jamal's text.......
> The Forces Message Header:
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>                     0               1               2             3
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |             Command         |               Length            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                          Source xID                           |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        Destination xID                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        Sequence Number                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |             flags           |             typeid              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> XML encoding:
> XML encoding may be useful in capabilities definition
> (i.e slow path) but not in the configuration of data path tables.
> This is because of its nature to require higher bandwith and
> CPU computational needs.
>
> HK Comment: I think we should stick with a single encoding type, namely
> TLV. This is also what some of the model team folks have mentioned
> before for the protocol. Is there a reason why capabilities cannot be
> expressed using TLVs?
>
>
> Thanks
> Hormu

---

From: Jamal Hadi Salim <[email-masked]>
Date: 09 Mar 2004 11:07:21 -0500

Hi Weiming,

On Tue, 2004-03-09 at 09:49, Wang,Weiming wrote:
> Hi,
> 
> I quite don't agree to limit a message type (or refered as "command")  to only
> "Add/Del/Get".  If we are decided to use a "command" field in the header, I
> think at least as a start,  we should include following message types:

There is no limiting to add/del/get. 
You have 8 bits (although this is not closed) you can therefore
have upto 256 commands. I can express all the commands you posted 
with add/del/get: But thats something we can settle later.
Can we close topic 1?

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 09 Mar 2004 11:16:47 -0500

This is a common trick. I thought both FACT and GRMP have it.
Netlink2 for example has a special command for errors.
The body will contain an error code and the offending original
header (similar to ICMP source quench).

These are issues we can settle. Can we please close topic 1?

cheers,
jamal

On Tue, 2004-03-09 at 11:04, Alex Audu wrote:
> code; you only do error processing if that color shows up.  And all
> the other messages
> ______________________________________________________________________
>

---

From: Alex Audu <[email-masked]>
Date: Tue, 09 Mar 2004 10:33:41 -0600

Hi Jamal,

I  think Hormuzd is a good moderator (from experience in our design 
meetings).  We could
have someone else do it,..if you object. 

The other issue I'd like to raise is please, let us cut through the 
chase and go straight to the
point. Some of the e-mails are really getting too long. We have our 
full-time jobs you know.
You can be brief and be understandable.  I think they call that 
succinctness.

Regards,
Alex.

---

From: Jamal Hadi Salim <[email-masked]>
Date: 09 Mar 2004 11:54:32 -0500

On Tue, 2004-03-09 at 11:33, Alex Audu wrote:
> meetings).  We could have someone else do it,..if you object.  

I dont object to Hormuzd or yourself for that matter.
You are not pointing whats wrong with the current process such that we
need a moderator. 
The main issue as i see it is we have a short period of time.
What we need is fast ontopic responses foremost not a moderator.

> point. Some of the e-mails are really getting too long. 

Thats good feedback. I will try to cut down on the long emails. I will
split my emails  onto different smaller ones whenever i can.
On your part, can you cut down on not syncing up with threads before
pitching in with a sentence that misses the 90% of the email?

> We have our full-time jobs you know.

Trust me as someone who works for a small company in the current economy
i am way overworked;-> But i am still making time for this so we can
make progress.

> You can be brief and be understandable.  I think they call that

I will try my best and so should you.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 10 Mar 2004 15:51:13 +0800

Hi,

I agree to currently close issue 1. I think it is quite probable to reach an
agreement on this issue when we write a draft, because there are no essential
differences among the ideas. I evaluate the result for this issue as "an
ageement can be reached in the future with the probability of 90%".

Now the actual problem lies in the issue 0, that is to use a uniform PID or a
tree structured FE ID: LFB ID: LFB Instance ID resolution for the addressing.
The issue 0 needs more discussion before being closed because the difference
there is very essential for the protocol.

Cheers,
Weiming

----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>
To: <[email-masked]>
Cc: "Putzolu, David" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, March 10, 2004 12:16 AM
Subject: [Forces-protocol] Re: Progress issue 1: packet encoding

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 9 Mar 2004 22:49:01 +0800

Hi,

For FE coarse layer management:
     FE Join or Leave Request Message
     FE Action Manipulate Message
     FE Attribute Manipulate Message
     FE Attribute Query and Response Messages
     FE Event Report Message

For LFB management:
     LFB Action Manipulate Message
     LFB Topology Query and Response Messages
     LFB Attribute Manipulate Message
     LFB Attribute Query and Response Messages

For Datapath management:
      Datapath Manipulate Message
      Datapath Query and Response Messages

I just want to see why such an arrangement is not good.

Yours,
Weiming