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