Tony Finch wrote:
On Thu, 13 Sep 2007, Keith Moore wrote:
Offhand I don't know why it should be necessary to build a mechanism
that spans several transport lifetimes.
TLS session caches. HTTP cookies. FTP control connections.
okay fine (at least for the first two) but should that information be
managed by the application, or at a lower layer? particularly if it
needs to be shared among multiple instances of a service that may reside
on different hosts?
Apps that want to deal with concurrent data streams within one user's
session currently have to establish and authenticate multiple TCP
connections (e.g. HTTP, IMAP) or re-implement TCP's multiplexing and
windowing at the application level (e.g. BEEP, ssh).
I actually don't think that having multiple concurrent TCP connections
between two peers is a bad thing. sure we could have a transport
protocol that provided multiple streams, but why bother when concurrent
TCP connections works pretty well?
A session layer would allow an app to establish a security context once
then re-use it when establishing new transport connections, so that
re-connecting can be cheap and concurrent data streams can be simple.
Unfortunately TCP doesn't share congestion information between
connections, which penalises new bulk-data streams and requires
workarounds at the application level (e.g. HTTP/1.1 persistent
mumble. I don't have a problem with multiple TCP connections, but OTOH
I think that using TCP close for framing is bad application design. so
I don't view persistent connections in HTTP as a workaround, I view it
as fixing a design flaw in HTTP/1.0.
Ietf mailing list