Subject: [AAA-WG]: Questions and comments to Base-07

From: [email-masked]
Date: Fri, 3 Aug 2001 13:06:25 +0300

Hi!
 
I have some comments to the base protocol draft 07. Could you, please,
clarify these things?

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?

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

Regards,

Adrian Constantin

------------------------------
Adrian Constantin

Software Engineer
Nokia Networks, IP Mobility Networks

Takomotie 1/1b22, 00380 Helsinki, Finland

Phone +358 718061689
Mobile +358 40 8386127
Fax. +358 9 51168770

---

From: Jacques Caron <[email-masked]>
Date: Fri, 03 Aug 2001 19:45:31 +0200

>The race condition mentioned in 5.4 could also lead to

Not possible. The messages are sent over TCP or SCTP which both guarantee 
ordered delivery.

>hop-by-hop identifier as the original message. Is this interpretation

The End-to-End identifier indeed does not change. The hop-by-hop one is 
local to a connection, so can be different.

>duplicate reply (with the same end-to-end id and same origin host)?

The End-to-end identifier in the answer is copied from the request, so in 
the worst case the client just receives exactly the same answer twice, and 
ignores the second one.

Jacques.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: [email-masked]
Date: Fri, 3 Aug 2001 21:35:53 +0300

Thanks for the answers. See comment bellow.

> -----Original Message-----
> From: ext Jacques Caron [mailto:[email-masked]]
> Sent: 03. August 2001 20:46
> To: Constantin Adrian (NET/Helsinki)
> Cc: [email-masked]
> Subject: Re: [AAA-WG]: Questions and comments to Base-07
> 
> 

I agree that the scenario cannot appear if TCP is used. But I knew that in
SCTP the delivery order is guaranteed only within streams. In this case the
scenario is possible if Request and CEA are sent on different streams. On
the other hand it might be possible for the Diameter to reorder the messages
at arrival. Should this be specified in the base protocol document?

---

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

> Not possible. The messages are sent over TCP or SCTP which 

I agree that the scenario cannot appear if TCP is used. But I knew that
in
SCTP the delivery order is guaranteed only within streams. In this case
the
scenario is possible if Request and CEA are sent on different streams.
On
the other hand it might be possible for the Diameter to reorder the
messages
at arrival. Should this be specified in the base protocol document?

<prc> Yes, I suppose this is then possible, which will cause the
connection to be dropped, according to the state machine. So, we have
two options:
1. limit the streams initially used, or
2. put safeguards in the state machine.

I'd vote for 2.

PatC