Subject: [Dime] transport directorate review of draft-asveren-dime-cong-00.txt

From: <[email-masked]>
Date: Thu, 16 Nov 2006 08:26:52 +0200

Hi all,

Some comments from the Transport Directorate.  The transport area
general is concerned about congestion issues, so an analysis of 
this document was requested.

Tolga didn't have time to discuss this at the last IETF document,
but it would be good for the wg to read the draft and comment
on the importance of this issue.  

thanks,
John 

>-----Original Message-----
>From: Bernard Aboba [mailto:[email-masked]] 
>Sent: 13 November, 2006 19:01
>To: Magnus Westerlund
>Cc: TSV Dir
>Subject: Re: [tsv-dir] [Fwd: I-D ACTION:draft-asveren-dime-cong-00.txt]
>
>I agree that this document is insufficiently specified and could lead
to 
>interoperability problems as well as operational issues.   
>
>Diameter is different from RADIUS in that the failover and 
>load balancing behavior is specified in "AAA Transport 
>Profile" RFC 3539. 
>
>Diameter deployments typically involve many clients, so that 
>load balancing can be achieved by distributing the clients 
>between the Diameter servers.  
>Schemes which move clients to "unloaded" Diameter servers (as 
>this document does) can result in load oscillations unless the 
>algorithms are carefully specified, which this document does not do. 
>
>Also, this document relies on explicit congestion signalling, 
>rather than piggybacking on existing exchanges (e.g. the 
>watchdog specified in RFC 3539):
>
>   A diameter node SHOULD send a CM to its
>   neighboring peers when it determines that its congestion level
>   changes.  
>
>In the situation where a node is congested, adding additional 
>load in the form of Congestion Messages is not helpful. 
>
>Also, it is not clear from the document how the congestion 
>states interact with the state machine specified in RFC 3539:
>
>   CONGESTION_LEVEL_0     0
>
>      This value indicates that the load on the sender node is below
the
>      manageable limit and the node are ready to handle new messages.
>
>   CONGESTION_LEVEL_1     1
>
>      This value indicates that the node can still handle messages but
>      if there is an alternative node, it SHOULD be preferred when
>      sending requests.
>
>   CONGESTION_LEVEL_2     2
>
>      This value indicates that no new requests SHOULD be sent to the
>      node.  A node in this state MAY drop request messages.  However,
>      answer messages still SHOULD be sent to the node.
>
>   CONGESTION_LEVEL_3     3
>
>      This value indicates that no new messages (neither requests nor
>      answers) SHOULD be sent to the node.  A node in this state MAY
>      drop any received message.
>

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 16 Nov 2006 11:22:11 -0500

A few comments/questions/ are below for people which are interested in this
topic.

   Thanks,
   Tolga

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, November 16, 2006 1:27 AM
> To: [email-masked]
> Subject: [Dime] transport directorate review
> ofdraft-asveren-dime-cong-00.txt
>
>
> Hi all,
>
[TOLGA]We thought that it could be better to decide for local congestion by
local policy. Especially for the cases where multiple
application/functionalities are running on the same node, it could be quite
difficult to tie congestion levels just to Diameter related parameters. I
agree that deciding for congestion levels should be done in a decent way on
each node (like providing hysteresis etc..). We can specify guidelines the
nodes should follow. I am also interested to hear more about what else could
be done on Diameter level about this issue.
> >load in the form of Congestion Messages is not helpful.
[TOLGA]The idea was to signal congestion before it reaches a level where it
impacts the operation of the node significantly. We can explore piggybacking
strategies as well. We may send congestion information in DWR/DWA but they
are not exchanges when traffic is flowing between two nodes. We may define
an AVP to communicate congestion information, which can be piggybacked to
any message, but this would be useful only as long as a message is sent from
the congested node to its neighbor. To me -at least for now-, an explicit
congestion message still seems more attractive because it commnicates
congestion information whenever congestion status changes without relying on
some other event happening.
> >      drop any received message.
[TOLGA]We may clarify this further.