[e2e] t/tcp and web services

[Spencer Dawkins]

--- Michael Welzl <michael.welzl at uibk.ac.at> wrote:
> David,
> 
> Many thanks for your quick reply! It's just the kind
> of answer I was looking for.
> 
> As for persistent connections - I agree that they're
> a good thing, but in the context of web services, I
> guess that they only increase efficency when it comes
> to bulk data transmission (result from a web service,
> or several parameters containing arrays etc.).

Persistent connections are a good thing for all users, but
command pipelining would be a better thing for wireless users
(with high RTTs), and we've done an OK job of specifying this
and a poor job of convincing people to deploy it (not in the
last IE I looked at, in the last NN I looked at, but not enabled
by default, etc.). See next comment for point.
> 
> Still, a web service is mainly a RPC - so there is
> still quite a reason to worry about the single-shot
> requests. Wouldn't a more secure variant of T/TCP
> that utilizes cookies (as in SCTP), nonces and
> such be worth thinking about? Or is that just
> impossible because of T/TCP's very nature?

It had better not be, given the discussions we're having about
multihoming (for SCTP and everything else) on multi6. 

My impression was that the last time we looked at T/TCP
seriously, we were in the middle of "no one developing new
transport protocols, the Internet will run the current
implementations of TCP and HTTP/1.1 forever", and that we
haven't raised the issue for T/TCP since multihoming was added
to SCTP. 

We could do a better job of securing T/TCP, but so far, no one
has cared. If we're really deploying SCTP and/or DCCP in any
significant way, either thinking about SCTP or securing T/TCP is
probably realistic.