Subject: [AAA-WG]: Diamter/SCTP: preventing head-of-the-line blocking

From: Jonathan Wood <[email-masked]>
Date: Mon, 30 Apr 2001 13:15:16 -0700 (PDT)

While SCTP has built in support for preventing head-
of-the-line blocking, there is currently no provision
in the diameter spec to utilize this functionality.
This means that Diameter/SCTP at present has the
same head-of-the-line blocking problems as Diamter/
vanilla TCP.

We can easily use SCTP streams to fix this. I propose
the following:

Each diameter node should stripe its messages across
the range of SCTP streams that it and its peer have
agreed upon. (A lost message in one stream will not
cause any other streams to block.) A trivial and
effective implementation of this simply increments
a counter for the stream ID to send on. When the
counter reaches the maximum number of streams for
the association, it resets to 0.

Diameter peers must be able to accept messages on
any stream. Note that streams are used *solely* to
prevent head-of-the-line blocking. All identifying
information is carried within the diamter payload.

SCTP peers can allocate up to 65535 streams for an
association. The cost for idle streams may or may not
be zero, and the cost for non-idle streams is always
greater than 0. So administrators may wish to limit
the number of possible streams on their diameter nodes
according to the resources (i.e. memory, CPU power, etc.)
of a particular node.

Stream IDs do not need to be preserved by proxies. For
example, consider the following case, where B serves
as a proxy between A and C:

A --------------------- B -------------------- C
     1000 streams            2000 streams

  msg 1: str id 0          msg 1: str id 0
  msg 2: str id 1          msg 2: str id 1
   ...                      ...
  msg 1000: str id 999     msg 1000: str id 999
  msg 1001: str id 0       msg 1001: str id 1000

The striping acts sort of like a hash table. It is
possible, yet unlikely, that two messages will end
up in the same stream, and even less likely that
there will be message loss resulting in blocking when
this happens. If it does turn out to be a problem, local
administrators can increase the number of streams on
their nodes to improve performance.

Questions / comments?

Jonathan

---

From: Yiwen Jiang <[email-masked]>
Date: Mon, 30 Apr 2001 16:29:38 -0400

Hi there,

I have a question that has been bugging me from the very beginning regarding
SCTP... 

There is really no stable SCTP implementation out there avaiable for us to
do development on (kernel or user land implementation). In addition, it is
my impression that the RFC is still not that stable (e.g. the recently
discovered Adler32 checksum weakness), why is SCTP a mandate for the
Diameter base protocol? Sure it provides us many desirable features, but if
there is no publicly available implementation out there, how can we support
this? Or is the current mandate only to look at using future possibilities
at a theorotical level?

Cheers,
Yiwen
---
Yiwen Jiang
Mobile IP Networking
Email: [email-masked]
Phone: (613)271-7710

Telecom Innovation Centre
505 March Road
Kanata, Ontario, Canada
K2K 2M5

> -----Original Message-----
> From: Jonathan Wood [mailto:[email-masked]]
> Sent: Monday, April 30, 2001 4:15 PM
> To: [email-masked]
> Subject: [AAA-WG]: Diamter/SCTP: preventing head-of-the-line blocking
> 
> 
>