Subject: RE: [Forces-protocol] topic 4c: Common Header

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sun, 2 May 2004 20:31:55 -0700

Hey Jamal,

Glad to see you're back in action ! Also, its good that you brought up
these issues (below), I agree on most points. See my comments below.

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 

BTW, there are a few things we seem to be skipping over - all of which
are important to the header:

- Transactions, definition and scope
- Atomicity of transactions
- batching of messages (maybe transactions)

and this last one i am not one 100% sure, but do we need to have
windowing as well for pipelining? or is batching sufficient?
In other words can we have only a single transaction active at a time or
can we have more running in parallel.

[HK] Yes, I agree these are important and was hoping you will bring this
up :) The Flags field in the header will cover some of these, if needed.
We needed to complete the discussion on the Flags, that we had before
(during Protocol Analysis team).

Responses to your email below:

On Fri, 2004-04-30 at 22:18, Khosravi, Hormuzd M wrote:

> Length : 16 bits
> 
> Command Type : 8 bits (semantics - TBD)

I am still trying to recover from my zone of last week; the commands
will be limited to those 6 or so you posted earlier? [yes]

> Flags: 16 bits, including 1-3 bits for Priority. (The semantics/length
> of Flags and Priority fields is TBD)
> 
> LFB TypeID: TBD, no consensus on whether it is needed or not in the
> header

I think you somehow need to be able to inspect the message and say
clearly who (FE/CE) and what (LFBID) that the message is directed at.
If not for any other reason, this is useful for debugging in the field.
I would like to be able to run a tcpdump session in a box where all
forces messages are mirrored to and debug a race condition for example.
My view would be to have this field to have may be one bit to represent
direction and the rest of the bits to represent they type of LFB being
targetted (set to zero or all 1s if message is not LFB specific)

[HK] Robert had pointed out that he would like to use this field to
address a message to a group of LFBs in different FEs (multicast based
on LFB Type ID). Do you agree with this ? That might be a more
compelling reason to me for having this field. I don't say that
debugging is not important, but we do have sophisticated tools these
days, which can easily look beyond headers into protocol messages these
days. (I believe even tcpdump can do this quite easily.)

> 
> ------------------
> Based on our latest discussion, I think we have decided to use Src ID,
> Dst ID fields in the common header instead of CEID, FEID, where a
> SrcID can be either CEID or FEID, same for Dst ID.
> The only other outstanding issue remaining is LFB Type ID. Could team
> members pls post their thoughts on this ??

I think we may have overlooked the other requirements like atomicity;
better catch them now.

I will share the netlink2 experience maybe we can borrow something from
it:

Batching:
1) We had a flag which indicates "more messages for this transaction are
on their way"
2) We had a command (not flag) which said "all messages are done for
this transaction"

A batch will start with one or more of #1 and end with #2.

Atomicity:
We had a speacial flag which indicated that a transaction or parts of it
are atomic.

The sequence number in our case was a strictly per message value.
A more interesting approach would be to break it into a transaction:msg
sequence.

[HK] We had similar flags/approach for batching/atomicity. The one
question that I have is if this is something which will be needed for
all messages or only for Config message ? If you think we need
Batching/Atomicity for all messages then we need these Flags in the
common header, otherwise we can just have it in the Config message. What
do you think ?

Regards
Hormuzd

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 03 May 2004 11:52:59 -0400

> (during Protocol Analysis team).

Ok, good.

> days. (I believe even tcpdump can do this quite easily.)

I cant remember what Roberts suggestion was; i know its in the archives,
my brain is still slow. I 'll let him explain.

The problem with standadrd sniffers is they need something to latch on
to decide what the packet is. Clearly it is easy to tell the packets is
a forces PL message. Next is you need to tell if it is from a CE or FE
and whether it is going to a CE or FE.
Ok, actually, this may lead back to what Weiming was saying maybe we
should allocate the addressing such that we can tell that the packet is 
for one of those two. Example (I think this has been suggested before),
we could have the most significant bit of the ID being set implying the
address belongs to the CE.
Speaking of which we need to discuss the addressing schemes now (eg
broadcast to all FEs, all CEs, subset etc).
On the content of the message: tcpdump should be able to decode based
on the header if i am not mistaken. But we havent discussed the layout
of the message content closely since last time. 

> all messages or only for Config message ? 

Config messages is all i see rigth now.

> If you think we need

The problem is i am not sure if it would be worth to say flags x only
apply to messages of type y. I am indifferent.

cheers,
jamal

---

From: [email-masked]
Date: Mon, 3 May 2004 23:49:30 +0200

> address belongs to the CE.

I definitely agree with this proposal.  When Weiming first sent it out 
I was trying to form an argument in its favor, then I went invisible 
for a variety of personal reasons (surgery of a family member), plus 
travel.

I think it also adds extensibility to the protocol over time.

a.