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

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

Hi Pat,

> 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. 
I guess it is just not very clear to me why TCP is mentioned in the draft
then. If TCP truely does not satisfy the requirements for Diameter, then
shouldn't the draft focus on SCTP only, and not worry about the watchdog at
all? 

If TCP is discussed in the ID because of the unavaiablility of SCTP
implementations, should there not be a separate section discussing features
required because of TCP, so that later on, when a stable SCTP implementation
is available, it would be easier to remove these additional features?

Or am I completely off the base here?

---

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

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

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.

http://people.cs.uchicago.edu/~piggy/sctp_chicago_il_us/
	Userland / Kernel hybrid, runs on FreeBSD

http://playground.sun.com/sctp/
	Solaris kernel

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

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.

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

---

From: jonathan wood <[email-masked]>
Date: Wed, 02 May 2001 17:26:52 -0700

The WG consensus so far seems to be that we need to include TCP at
least for a transition to SCTP.

But I would like to echo Yiwen's question: how should we spec out
Diameter over TCP and SCTP? Should we have different sections (or
drafts??) for Diameter over XXX mappings?

Or perhaps a simpler approach would be, as Yiwen suggests, to write
the protocol spec to SCTP, and then have a section stating what
extra stuff is needed for Diameter over TCP...

This would, of course, entail more draft editing (sorry Pat).

What does the WG and the chairs think?

Jonathan