below...
Alain Durand wrote:
>
> john.loughney@nokia.com wrote:
>
> >Hi Alain,
> >
> >I agree with your intro (which I clipped to save space),
> >
> Thank you!
>
> > 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.
> >
> 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.
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