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