[anti-censorship-team] Turbo Tunnel: let's build a sequencing/reliability layer into our circumvention protocols

[Roger Dingledine]

On Mon, Aug 12, 2019 at 12:58:30PM -0700, David Fifield wrote:
> In short, I think that every circumvention transport should incorporate
> some kind of session/reliability protocol???even the ones built on
> reliable channels that seemingly don't need it.

Thanks for the discussion David! I agree with most of your points and
look forward to seeing where this goes.

Two hopefully useful follow-up thoughts:

> I've done a little survey and identified some suitable candidate
> protocols that also seem to have good Go packages:
>  * [QUIC](https://quicwg.org/) with [quic-go](https://github.com/lucas-clemente/quic-go)
>  * KCP with [kcp-go](https://github.com/xtaci/kcp-go)
>  * [SCTP](https://tools.ietf.org/html/rfc4960) with [pion/sctp](https://github.com/pion/sctp)
> 
> I plan to evaluate at least these three candidates and develop some
> small proofs of concept.

This seems like a great next step. In terms of the goal here, I was
originally thinking "but how shall we pick the one we tell everybody
to use?" and then I realized that another approach would be to set up
a framework where we describe what properties we want, and provide a
few approaches that satisfy them, and now it wouldn't have to be the
case that everybody uses the same one. Which world we want to live in
will depend in large part on how your evaluation goes -- i.e. if you
find that several of them are plausible candidates, don't be afraid to
recommend all of those. :)

> Q: You're proposing, in some cases, to run a reliable protocol inside
> another reliable protocol (e.g. QUIC-in-obfs4-in-TCP). What about the
> reputed inefficiency TCP-in-TCP?
> 	A: Short answer: don't worry about it. I think it would be
> 	premature optimization to consider at this point. The fact that
> 	the need for a session/reliability layer has been felt for so
> 	long by so many systems indicates that we should start
> 	experimenting, at least. There's contradictory information
> 	online as to whether TCP-in-TCP is as bad as they say, and
> 	anyway there are all kinds of performance settings we may tweak
> 	if it turns out to be a problem.

I agree with your suggested plan of not letting future concerns slow
down the experimenting now. But I wonder if there are ways to position
ourselves so we are able to recognize when this issue has become a
problem. In particular, if we put this issue aside for now, and move
forward with encouraging everybody to have a sequencing layer, and then
down the road somebody using this approach is unhappy with the performance
of their pluggable transport, is there anything we can/should do in the
near term that will help that developer in that future situation? For
example, are there some warning signs we can list now, that people can
look for later, that will help them realize that it's time for them to
resume being suspicious of tcp-over-tcp? Or are there some tools we can
imagine building, even if we don't build them now but just put them on
a wishlist somewhere, that will help those future people understand and
debug their performance issues?

--Roger