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

From: Pat Calhoun <[email-masked]>
Date: Tue, 1 May 2001 06:37:34 -0700 (PDT)

> > Well, what are the options for a Diameter transport?
> > o TCP: doesn't meet all the transport requirements
> > o roll-yer-own: this would probably delay diameter by at least a year
> > o or SCTP: meets all the transport requirments, and is farther along
> >   than diameter in the standards process.
> But from the I-D, it talks about the fact that TCP is insufficient for
> timely detection of failed or unresponsive peers, and hence, SCTP. But as
> you pointed out in your original mail, isn't this what the watchdog timer is
> used for? Or am I misinterpreting???

TCP implementations that support the Congestion Manager would "probably" work,
but what SCTP does provide is a way to retrieve information from the transport
for specific sessions, such as RTO. This information is used by the
application to detect whether a failover should occur.

The failover section is in dire need of a re-write. I believe that once the
new draft is available, support for watchdogs will become more obvious. 

If not, then additional clarifying text will be added.

PatC

---

From: Yiwen Jiang <[email-masked]>
Date: Tue, 1 May 2001 09:09:18 -0400

Hi Jonathan,

> >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
> 
> That depends on your definition of stable. For development purposes,
> I would say that the following publicly available implementations
> are stable enough:
> 
> http://www.sctp.de/
> 	Userland, runs under Linux, FreeBSD and Mac OS X and 
> supports IPv4
> 	and IPv6.
I spent some time looking at this user land implementation. It does not
cover many error conditions. I was told by Michael Tuexen that him and
Andreas were only interested in the protocol itself, rather than error
handlings of the software. For example, up until their latest release,
(sctplib-1.0.0-pre9) if both peer are trying to initiate a connection at the
same time, one peer will be successful, the other will return fail. Of
course, this bug will probably be fixed in the next release, but this tells
me something about the implementation. 

In the mean time, I'm not a believer of using a user land implementation for
level 3 protocol..

> http://people.cs.uchicago.edu/~piggy/sctp_chicago_il_us/
> 	Userland / Kernel hybrid, runs on FreeBSD
> http://playground.sun.com/sctp/
> 	Solaris kernel
These are on my investigation list.... I think Piggy's version also runs on
Linux (kernel) as well.
 
> >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?
> 

Yiwen

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