Subject: RE: TCPng/ multiple addresses per node (was Re: A follow up question)_

From: <[email-masked]>
Date: Fri, 25 Apr 2003 06:53:14 +0300

Hi Alain,

I agree with your intro (which I clipped to save space), one
comment that I have is:

> There is a proposal to create an API to enable the
> application creating the socket to specify some of the
> properties that it desires/requires. This is a step in the right
> direction, but I'm not convinced this can go far enough.
> So I fully support this idea of lifting the ban on TCPng
> (or any transport layer for that matter) to de-couple
> the abstraction needed by applications to the one required
> by the network. This is in fact introducing some of the semantic
> of a session layer between the application and the network.
> Can this be done at the transport layer in the form of TCPng
> or does this require and actual additional session layer?
> I'm not sure at this point in time.

There already something like this, I'm sure you know - SCTP.
I'm actually not trying to promote SCTP, but it might be interesting,
as we have an RFC that does most of the avove, to look at it
critically & see how it performs.  

SCTP, as a background, uses sets of addresses/ports to identify a
node. In the usual case, one node will pass all of its addresses(& ports)
to its peer & the peer returns its addresses (&ports) for SCTP 
traffic.  The application has the the option to choose the primary
address to be used.  

Right now, SCTP has limited users (Diameter, SIGTRAN and probably a couple
of other protocols).  It would be interesting to see that others
can do with it.

John

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Alain Durand <[email-masked]>
Date: Fri, 25 Apr 2003 16:18:19 -0700

[email-masked] wrote:

>Hi Alain,
>
>I agree with your intro (which I clipped to save space),
>
Thank you!

> one
SCTP does not specify how the 'primary' source & destination are chosen,
nor does it explain how to order those lists once it decides to try 
another pair.

Two possible ways to do that could be:
- use knowledge of the topology, that is pass some of the
   routing information to the end nodes.
- use dynamic measurements.. For example start the connection
   using the initial src & dst, and then send regular probes 
(duplicates?) using
   the other combinations to do measurements and keep statistics.

On top of that you might want to add social/economic information
known by the end points, like this interface is cheap vs expensive
at this particular moment. Similar information for other links
within the network would be valuable but much more difficult
to collect!

Also, there is still a need to enable the application
to specify the desired/required properties of the addresses,
like use temporary vs use stable address, use home address vs
care-of-address,...

SCTP does not do any of that.

    - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 27 Apr 2003 16:08:13 +0200

below...

> SCTP does not do any of that.

SCTP was designed for a specific context, telphony signalling, where
there are many intrinsic constraints and the alternative addresses
will probably be explicitly managed as part of the applications
environment. That's much easier than trying to solve these problems
for the general case. In general, middleware designers simply don't
want to know about such issues, however sophisticated an API they
are offered. Before we go down this path, we would need a deep
analysis jointly with the middleware community, otherwise it will
all be in vain.

    Brian