Subject: [[email-masked]: RE: Re: [AAA-WG]: Questions and comments to Base-07

From: Pat Calhoun <[email-masked]>
Date: Mon, 6 Aug 2001 00:53:45 -0700

Comments below delimited with <prc>

PatC
----
PEER STATE MACHINE

In section 5.3 some scenarios presenting an unsuccessful peer 
connection
establishment are presented, but they are not reflected in 
the peer state
machine (5.6). It seems to me clearer if the state machine 
includes the
cases when the peer connection is refused. 

The race condition mentioned in 5.4 could also lead to 
scenarios like the
one bellow:

Peer1                    Peer2
 |                         |
 |           CER           |
 |------------------------>|
 |                         |
 |                        /|
 |   Request MSG         / |
 |<---------------------/--|
 |                     /   |
 |            CEA     /    |
 |<-------------------     |
 |                         |

In this case the request message receives no answer and a deadlock can
appear at Peer1. How can this be prevented?

<prc>Well, by correctly implementing the state machine :)

The state machine includes the following:

Wait-I-CEA       I-Rcv-CEA        Process-CEA      I-Open
                 R-Conn-CER       R-Accept,        Wait-Returns
                                  Process_CER,
                                  Elect
                 I-Peer-Disc      I-Disc           Closed
                 I-Rcv-Non-CEA    Error            Closed
<==============
                 Timeout          Error            Closed

The Wait-I-CEA is the state that you show in your diagram above. Peer1
is waiting for the CEA from peer2, but instead receives an non-CEA
message. The state machine shows that peer1 MUST close the connection.

Perhaps this is not exactly the best situation, but since the protocol
runs over a reliable transport that also performs message ordering, this
will never occur. </prc>

FAILOVER

In case of failure the requests pending are resent to an 
alternate peer. In
my understanding the duplicate must contain the same end-to-end and
hop-by-hop identifier as the original message. Is this interpretation
correct?

In case of duplicate messages, the only messages discarded are the
duplicated answers meant for local processing (3.0). The 
servers answering
to a duplicate request will set different end-to-end 
identifier for the two
answers. In this case, which scenario could lead to the receiving of a
duplicate reply (with the same end-to-end id and same origin host)?

<prc> The e2e is copied from the request, so this will never be a
problem unless the server misbehaves. </prc>

MESSAGE PROCESSING

PeerA                   PeerB
 |                         |
 |      Request 1          |
 |------------------------>|
 |      Request 2          |
 |------------------------>|
 |                         |
 |        DPR              |
 |------------------------>| 
           (PeerB still processing Requests 1,2)
 |                         |
 
In the scenario above is it mandatory for PeerB to send 
Answers 1,2 before
DPA or is it implementation dependent?

<prc> only as far as it can. If they are available, it would be a good
idea. However, chances are PeerA is shutting down anyways and will not
accept those answers. So, I'm not sure that it makes sense to send them.

What do other folks think?
</prc>