Subject: [AAA-WG]: Transport draft -02 posted

From: Bernard Aboba <[email-masked]>
Date: Fri, 18 May 2001 05:43:37 -0700 (PDT)

For discussion at the Interim meeting, I've made a copy of the -02 version
of the transport draft at:

http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-02.txt

comments welcome.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 18 May 2001 08:38:51 -0700

Speaking of the interim, is there an agenda available yet?  How about a
schedule (what time do we need to show up at Nortel)?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Bernard Aboba
> Sent: Friday, May 18, 2001 5:44 AM
> To: [email-masked]
> Subject: [AAA-WG]: Transport draft -02 posted
>
>

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 18 May 2001 08:34:29 -0700

> schedule (what time do we need to show up at Nortel)?

Given the amount of work on our plate, I vote for 8 (sorry Glen :)

PatC

---

From: David Mitton <[email-masked]>
Date: Fri, 18 May 2001 12:21:01 -0400

I'm going to need some time to figure out the situation with the room
first thing Monday morning.

Show up at 9am.  Don't be too surprised if you get redirected.

A notice will be posted later today.

Dave (up to my eyeballs in insanity)

> > > http://www.drizzle.com/~aboba/AAA/draft-ietf-aaa-transport-02.txt

----------------------------------------------------
David Mitton                            978-288-4570
Advisor, Nortel Networks
[email-masked]   or      [email-masked]

---

From: jonathan wood <[email-masked]>
Date: Fri, 18 May 2001 15:21:21 -0700

Bernard,

In general, this document provides good coverage of AAA transport isses
and solutions, but is very TCP-specific. There are a number of places
where things are a bit different for SCTP. Here are some:

5.2 App layer heartbeats
SCTP has transport layer heartbeats. What more do app-layer heartbeats
buy you? (If you can answer this before Monday, we will have one less
thing to discuss at the interim meeting :)
By and large you are repeating all the work that SCTP heartbeats are
doing at the app layer.
Additionally, since SCTP is multihomed, you
will also need to transmit app-layer heartbeats to each peer address
in the association.

5.3 Nagle
SCTP does not use the Nagle algorithm (see the SIGTRAN archives for a
lengthy
discussion on why this is).

5.8 Invalidation...

Heartbeats (app or transport layers) will keep RTT and RTO information
up-to-date. Congestion info, as you point out, is not kept current.

SCTP congestion control is based upon number of *bytes* outstanding,
not packets, so if your requests are small, you can certainly fit many
of them into a CWND. So your example of it taking 6 RTTs to send 35
AAA requests may not be valid. Also the CWND can increase by as much as
a factor of two per SACK if you have your CWND filled (and indeed that's
when you really care about fast start-up), so a better estimate would be
something like 2-3 RTTs for 35 requests.

This also pertains to 5.9, Inability to use fast-retransmit: the CWND
may, but
probably won't, prevent fast-retransmit when using SCTP.

Also, on Allison's reccomendation to reset the RTO after congestion
window,
this could be OK for the transport protocol to do, but I really wouldn't
want an upper-layer protocol doing this. In fact, I can't imagine
transport
protocol implementations providing an interface for ULPs to tweak the
RTO.
It might be best to omit this from this document.

5.10 Head-of-the-line blocking

I proposed on aaa-wg a method for using SCTP streams to prevent
head-of-the-
line blocking (indeed this is why SCTP has streams). When using SCTP,
this
method should be simpler and more efficient than limited transmit and
load balancing (which are still useful for TCP, however).

A nit on 4.5: Duplicate detection
If duplicate are put on the wire due to spurious retransmits by the
transport
protocol, the recveiving end of the transport protocol (be it TCP or
SCTP)
will detect this and not pass the duplicates up to the app. This means
that
all duplicates at the AAA layer will have been generated by the AAA
protocol,
not spurious retransmits.

Jonathan

---

From: Allison Mankin <[email-masked]>
Date: Fri, 18 May 2001 20:08:32 -0400

Jonathan,

Bernard or I will discuss your app versus SCTP heartbeat point and
others in a subsequent message, but here's a reply to one of your points

> load balancing (which are still useful for TCP, however).

Yes, this is exactly why SCTP is the recommended transport, required of
all servers along with TCP, and why the recommendation says that TCP
may be phased out in future.

Allison

---

From: jonathan wood <[email-masked]>
Date: Fri, 18 May 2001 17:02:21 -0700

> may be phased out in future.

The problem is that there is currently no provision in any AAA
protocol for using SCTP streams. If implementations just use one
stream, they are no better off using SCTP than TCP. If they do
try to use streams and there are no ground rules in the IETF
specs, there will be interoperability problems.

I think for this document it is sufficient to say something like
"When using SCTP, AAA protocols SHOULD take advantage of SCTP
streams to prevent head-of-the-line blocking".

For specific AAA protocols (like Diameter), we need to say a bit
more (but not much more) to ensure interoperability.

Jonathan

---

From: Allison Mankin <[email-masked]>
Date: Fri, 18 May 2001 21:11:27 -0400

> streams to prevent head-of-the-line blocking". 

I agree.

> more (but not much more) to ensure interoperability. 

Could you suggest text?

Allison

---

From: jonathan wood <[email-masked]>
Date: Fri, 18 May 2001 17:24:46 -0700

> > more (but not much more) to ensure interoperability.

Sure. Here's what I suggested previously with regard to the
Diameter spec:

1. For interoperability: All Diameter nodes MUST be prepared to receive
   Diameter messages on any SCTP stream in the association. 
2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP 
   streams available to the association to prevent head-of-the-line
blocking.    

Jonathan

---

From: David Frascone <[email-masked]>
Date: Fri, 18 May 2001 21:39:35 -0500

You should include the simple algorithm that you posted in another 
message too.  It was a nice example of one approach to allocating streams.

---

From: jonathan wood <[email-masked]>
Date: Fri, 18 May 2001 18:58:08 -0700

> message too.  It was a nice example of one approach to allocating streams.

Here it is again -- it might help to make things clearer:
(sorry about the indentation; it's from the archives.)

                              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