Re: [rtcweb] PseudoTCP implementation (Re: realiable data service)

[Justin Uberti <[e-mail]>]

On Fri, Jul 22, 2011 at 7:33 PM, Cullen Jennings <[e-mail]> wrote:

>
> On Jul 20, 2011, at 8:37 , Justin Uberti wrote:
>
> >
> >
> > On Wed, Jul 20, 2011 at 9:15 AM, Harald Alvestrand <[e-mail]>
> wrote:
> > On 07/20/11 03:13, Cullen Jennings wrote:
> > On Jul 18, 2011, at 15:11 , Randell Jesup wrote:
> >
> > All that said - yes, there are complexity issues to consider, which was
> why I was suggesting leveraging
> > an existing tunneled protocol like SCTP or even TCP-over-UDP.
> > I agree with bunch of what you are saying but the previous several times
> I've seen the use SCTP over UDP conversation, it usually ends about the
> point the we ask for a user land implementation. Whatever we do more or less
> has to be user land or already exist in the OS that people run browsers on.
> >
> > If someone has a user land implementation of SCTP or TCP, I imagine that
> might change the outcome a bit from previous times. I have not looked at the
> TCP over UPD library Justin mentioned but, at casual glance, I noticed is
> around 400 lines of code which is very small, which is cool. But given the
> lines of code in say the BSD TCP stack, it does make me wonder what's
> missing. That said, I don't think we need something with the perforce of the
> BSD TCP stack as long as what is there is TCP friendly and robust.
> > I believe this is the current URL:
> >
> >
> http://code.google.com/p/libjingle/source/browse/trunk/talk/session/tunnel/pseudotcpchannel.cc(500 or so lines).
> >
> > The real protocol implementation is here:
> >
> http://code.google.com/p/libjingle/source/browse/trunk/talk/p2p/base/pseudotcp.cc
> > which is another 1000 lines (not counting the various .h files).
> >
> > We're not THAT good at writing compact code :-)
> >
> > Yes, I was going to send a similar email. There are some
> deficiencies/optimizations for the fact it runs over ICE-UDP - doesn't do
> path MTU discovery, no checksum, no OOB data - but it is based on TCP and
> implements slow start and other congestion avoidance mechanisms, and is
> actively used by a number of applications where reliable transfer is
> important, such as file transfer and remote desktop applications.
> >
> >
>
> It would be really interesting to see someone write a draft that subsets
> TCP to make it
>
> 1) still be congestion safe and TCP friendly
>
> 2) be valid TCP from point of view nats and firewalls
>
> 3) match an implementation like the one you have here.
>
> Most our use cases do not need OOB data. A subset protocol that was missing
> something like path MTU discovery might be slower than full blown modern TCP
> but again, most out use cases would still work just fine. As much as the
> IETF hates sub setting protocols, having something concrete and in hand like
> this would be a pretty useful thing. As well as being useful for the wwebrtc
> work, something like this would be useful for very constrained systems such
> very cheap sensor networks. I'm seeing lots of really minimal subset of TCP
> being done for these very low end system.
>

Interesting. From the webrtc context, the requirements are a little
different - e.g. when we're running as TCP/UDP, we don't need the port or
checksum, as those are handled by the UDP layer.

So the goal would become two specs:
(1) minimal subset of TCP
(2) adaptation of #1 to run over UDP instead of IP

Who can speak to what requirements/RFCs should constitute #1? We could
certainly make a proposal based on what we've implemented, but if it's going
to be used more broadly, I'm guessing a LOT of folks will care about these
details.

For #2, in addition to the work we've done with what we call PseudoTcp, I've
noticed these two other drafts on TCP/UDP, which are very similar to
PseudoTcp. The first gives a very good treatment (in Section 8) of why a
PseudoTcp-like approach is the best way for reliable p2p data transfer.

http://tools.ietf.org/html/draft-baset-tsvwg-tcp-over-udp-01
http://tools.ietf.org/html/<http://tools.ietf.org/html/draft-denis-udp-transport-00>
draft-denis-udp-transport-00<http://tools.ietf.org/html/draft-denis-udp-transport-00>