Subject: Re: First draft of ForCES protocol from the protocol design team

From: Alex Audu <[email-masked]>
Date: Sun, 27 Jun 2004 20:18:04 EDT

Hi All,

I was able to get to the draft-fpteam-forces-protocol-00.txt draft this past
weekend. However,
I am only half way through. These are my comments:

1) General comments:  I like the preambles in the early sections. However, I
am not sure
    if it is necessary to draft real-estate discussing how the design team
was created in
    section 1. Introduction. I think we can remove the following text from
the document:

..............................................................................
...........................................
   The team was created by the WG chairs of the ForCES group in
   consultation with the Routing Area ADs after the authors of the
   various qualifying drafts, i.e.  drafts submitted by the deadline
   which met the essential requirements outline in [RFC3654], reached
   consensus on being able to develop a common protocol proposal.

   While this draft has rough consensus within the design team, there
   are still issues that need to be resolved.  These issues will
   continue to be discussed within the protocol design team and
   hopefully, on the general ForCES WG email list.

   The protocol design team was defined by the WG chairs to be composed
   of seven participants includes two representatives from each of the 3
   protocol proposals and 1 participant who had not contributed to the
   proposed protocols.
..............................................................................
.............................................

2) Section 3.3.2 FE Protocol Object
  It is not clear to me what the use or intent of the protocol object
concept.  It borders
  a lot on implementation detail at least in my mind.

3) Section 3.3.3 Scaling by Concurrency
  The concept advocated here seems to be a complex one.  How about relying on
a
  simple  request/response/ACK based system? This basically adapts to the
underlining
   network's speed adaptively. "The sooner I get an ack/response to my
previous request,
   the sonner I can make another request",..and the quicker the job will be
done. I believe
   this is the essence of flow-control.

4) Section 4. TML Requirements:
  I believe the TML should be as transparent to the CE and FE as much as
possible.
  As such I am not in agreement with the following as stated in the draft:
..............................................................................
..................
     2.  Security
       TML provides security services to the ForCES PL.  TML layer
       should support following security services and describe how they
       are achieved.
       *  Endpoint authentication of FE and CE.
       *  Message Authentication
       *  Confidentiality service
..............................................................................
.............................

Security is an end-to-end problem.  Having to go through an intermediary will
necessitate
that entity to have a security handshake with both endpoints trying to to
cumminicated.
This essentially doubles the handshaking that needs to take place.
For example A <-------->B<-------------->C   requires B to make two
handshakes (one each
with A and C, before A and C can communicate.  But if  we have
A<-------------->C, with
B being transparent, then only one handshake is needed, and the
authtentication process
becomes much quicker.

Also, keeping TML transparent as much as possible makes TML much simpler.
Else,
it has to be made a stateful entity, when it really doesn't need to be. In
short, TML should
be viewed as a transport medium. It should get involved in stateful matters
only when
absolutely necessary (for example when providing reliability over a
non-reliable medium).

5) Section 5. Common Header
The following seems to suggest that CEs and FEs are exposed to the internals
of the
 addressing scheme.  I thought the TML was supposed to abstract this from the
end
 users,..no?
..............................................................................
.............

      C.  Special IDs are reserved for FE broadcast, CE broadcast, and
          NE broadcast.
      D.  Subgroups of FEs belonging, for instance, to the same VPN, may
          be assigned a multicast ID.  Likewise, subgroups of CEs that
          act, for instance, in a back-up mode may be assigned a
          multicast ID.  These FEs and CE multicast IDs are chosen in a
          distinct portion of the ID address space.  Such a multicast ID
          may comprise FEs, CEs, or a mix of both.
..............................................................................
....................................

In the same section, we find the folloing:

..............................................................................
....................................
   Flags(32 bits):
   Identified so far:
   o  ACK indicator(2 bit)
      The description for using the two bits is:
      'NoACK' (00) | 'SuccessACK'(01) | 'UnsuccessACK'(10) | 'ACKAll'
      (11)
   o  Priority (3 bits)
      unknown/undecided.
   o  Throttle flag?
   o  batch (2 bits)
   o  Atomicity (1 or 2 bits)
..............................................................................
.......................................
To me this makes message handling way too complex. It is just nightmarish to
think
of all those flags to be set/tracked for all messages. Utter wast of CPU
cycles. This
will lead to an inefficient and sluggish protocol in my view.

6) Section 6.1.3 Association Teardown Message

I cringed when I read the following in the draft:
..............................................................................
...
   Message Header:
   The Message Type in the header is set MessageType= 'Asso.
   Teardown'(TBD?).  The ACK flag in the header is always ignored,
   because the teardown message will never expect to get any response
   from the message receiver.
..............................................................................
.....................
Now, a protocol designed this way will NEVER work.  The ACK is very much
needed when
tearing down an association.  Consider the following scenario:

                                 +------------------FE1
                CE ------------|
                                 +------------------FE2

CE is the contol active control element with FE1 the active FE and FE2 the
standby unit.

    1) FE1 is now sent a command to go down (by craft person via management
interface).
    2) FE1 sends association-teardown request to CE.
    3) CE gets this important information and quickly activates FE2 to assume
FE1's
         responsibilities.
    4) FE2 acknowledges this activation to CE.
    5) CE can then acknowledge FE1's request to leave or go down.
    6) FE1 leaves, and FE2 assumes FE1's traffic duties.  Hurray!,.. NO
TRAFFIC OUTAGE.

Now, if we take away steps 3,4, and 5, then FE1 can just leave at will, and
the result WILL
BE AN OUTAGE. At least until an alternative FE becomes the active one.  This
is not
a 5-9's reliability compliant protocol.

That is how far I have read,..and I'll post more later.

Regards,
Alex.

---

From: Robert Haas <[email-masked]>
Date: Mon, 28 Jun 2004 16:49:27 +0200

Alex,
I assume that you have now finished reading the draft. Do you still have 
issues with the FE Protocol Object or did it get clearer in the meantime ?
Regarding your question 5) on the transparency of the TML wrt broadcast 
and multicast IDs: the TML takes care of mapping those IDs to the right 
IP addresses, connections, etc. So the transparency is maintained at the 
PL layer. This is similar to sets as previously proposed in FACT.

Regards,
-Robert

Alex Audu wrote:

> Hi All,
>  
> I was able to get to the draft-fpteam-forces-protocol-00.txt draft 
> this past weekend. However,
> 1) General comments:  I like the preambles in the early sections. 
> However, I am not sure
>     if it is necessary to draft real-estate discussing how the design 
> team was created in
>     section 1. Introduction. I think we can remove the following text 
> from the document:
>  
> .........................................................................................................................
> ...........................................................................................................................
>  
>   The concept advocated here seems to be a complex one.  How about 
> relying on a
>   simple  request/response/ACK based system? This basically adapts to 
> the underlining
>    the sonner I can make another request",..and the quicker the job 
> will be done. I believe
>   I believe the TML should be as transparent to the CE and FE as much 
> as possible.
> ................................................................................................
>      2.  Security
> ...........................................................................................................
>     
> Security is an end-to-end problem.  Having to go through an 
> intermediary will necessitate
> that entity to have a security handshake with both endpoints trying to 
> to cumminicated.
> Also, keeping TML transparent as much as possible makes TML much 
> simpler.  Else,
> it has to be made a stateful entity, when it really doesn't need to 
> be. In short, TML should
> be viewed as a transport medium. It should get involved in stateful 
> matters only when
> The following seems to suggest that CEs and FEs are exposed to the 
> internals of the
>  addressing scheme.  I thought the TML was supposed to abstract this 
> from the end
>  users,..no?
> ...........................................................................................
>  
> ..................................................................................................................
>  
> ..................................................................................................................
>    Flags(32 bits):
>    Identified so far:
>    o  ACK indicator(2 bit)
> .....................................................................................................................
> To me this makes message handling way too complex. It is just 
> nightmarish to think
> of all those flags to be set/tracked for all messages. Utter wast of 
> CPU cycles. This
> .................................................................................
>    Message Header:
> ...................................................................................................
> Now, a protocol designed this way will NEVER work.  The ACK is very 
> much needed when
> CE is the contol active control element with FE1 the active FE and FE2 
> the standby unit.
>  
>     1) FE1 is now sent a command to go down (by craft person via 
> management interface).
>     3) CE gets this important information and quickly activates FE2 to 
> assume FE1's
>          responsibilities.
>     6) FE1 leaves, and FE2 assumes FE1's traffic duties.  Hurray!,.. 
> NO TRAFFIC OUTAGE.
>  
> Now, if we take away steps 3,4, and 5, then FE1 can just leave at 
> will, and the result WILL
> BE AN OUTAGE. At least until an alternative FE becomes the active one. 
>  This is not

-- 
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

---

From: [email-masked]
Date: Mon, 28 Jun 2004 12:55:33 -0400

On 27 jun 2004, at 20.18, Alex Audu wrote:

>     section 1. Introduction.

This section was put in for this draft only to give the background on 
this first version of the draft.  It seems very reasonable to remove it 
before the next revision, especially if this is the draft chosen for WG 
draft status.

a.