Subject: [Forces-protocol] Minutes of ForCES design team phone call #2, May 18 2004.

From: Robert Haas <[email-masked]>
Date: Tue, 18 May 2004 18:56:36 +0200

All,
Here are the minutes from today. I tried to condense the discussions, 
let me know if you have additions to be made. There may be one or more 
Action-Items that are of importance to you, take a look.
Thanks,
-Robert

Participants: Hormuzd, Robert, Ram, Avri, Weiming, Jamal.

Robert is taking minutes.

1) Common Header.

Hormuzd describes the current situation:
Version + subversion 4 b
Source ID 32 b
Dest ID 32 b
Transaction Seq number 32
length 16 b
cmd type 8 b
flags 16 b (priority, batching, atomicity, (n)ack)
LFB type 16 b

Jamal: is 16 bits enough for length ? Cannot be smaller than the TLV length.
Ram: count the length in multiple of 4 bytes.
Avri: message must aligned on double-words (32 bits)
Hormuzd: LFB type 16 bits can be too small. May need to increase to 32 bits.

2) LFB Type.
Robert: used to address LFBs by type instead of by address.
Avri: we should keep a small common header. Only FEs know which LFB 
types they have. So CE must sent the message to all FEs. No LFB Type 
needed in the Common Header, except if all inner TLVs must have it.
Jamal: used for easy debugging purposes.
Hormuzd: LFB Type mcast not suitable for mutliple independent IPv4 LFBs 
instances in same FE.
Weiming: proposes an additional flag to indicate if Dest ID is an FE ID 
or an LFB ID. Might not be possible.
Jamal: virtual instance LFB ID for virtual routers.

Avri, Hormuzd: need to have a picture of the header to discuss.

Action Item: Robert+Jamal+Weiming will finalize the addressing scheme in 
a section, exchanges will be made on the list. Use of LFB Type in the 
Common Header will be reassessed later.

3) HB (heart beat):
Hormuzd: Common Header cmd types defined: setup, event, query, config, 
state maintenance (i.e., active FE, move CE)  (all with their 
responses), packet redirect.
Avri: HB should be as short as possible.
Jamal: should allow a HB for LFB instances (if LFB software crashes).
Robert+Avri: LFBs crashing on the FE should trigger an event to the CE 
(status or alarm message). Use subscribe/unsusbcribe on specific LFBs 
for their livelness attribute.
Avri: a health-check LFB that fires events when LFBs fail, and send a HB 
liveliness status for a specified list of LFBs. HB is only basic FE and 
CE liveliness.
Robert: HB is a short header message, but should be configurable through 
the FE LFB.

Agreement: HB signal is a separate message type. How to configure it 
(i.e., using the FE LFB or new PDUs) remains open. Preferrably using the 
same logic as for other LFBs (Robert and Weiming's preference, to be 
further discussed).

4) Batching and Atomicity:

Ram: 2-phase commit can be done over two different FEs.
Avri: transactions are made of TLV and are either atomic, or batch, or 
do-until.

Avri left.

Action-Item: Ram will clarify the relation between atomicity, 2-phase 
commit, when issuing commands to the same FE or two different FEs. 
Diagrams of transactions.

Weiming: If 3 routes are added with a single TLV, then should we ensure 
atomicity if needed.

Ram left.

Weiming: interleaving commands/TLVs in the same message, some are 
atomic, some not.

Jamal: add subsequence numbers to identifiy independent transactions in 
the same message. Use of window of 1 for PL messages, and use 16 bits 
for 16 subsequence numbers within a PL message for 16 parallelized 
uncorrelated transactions (TLVs).

Action-Item: Hormuzd will post some scenarios and associated diagrams.

Robert: iSCSI (RFC3720) supports a cmd window, so that multiple 
uncorrelated transactions can be sent together without overflowing the 
FE. This could avoid using the subsequence number.

Jamal: a cmd window is tricky with mcast to multiple FEs as they must 
coordinate cmd windows.

No resolution yet on how deep atomicity should go (within TLVs).

5) General

Action-Item: everyone must start writing their section and post a draft 
on the protocol list by May 24th.

after 2 hours 45 min, the conf call ended.

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

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