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

[Harald Alvestrand <[e-mail]>]

On 07/22/11 22:33, Cullen Jennings 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.
ObNitpick: TCP doesn't have OOB data.

What it has is an "urgent data downstream" pointer, which the Unix 
implementors used to pick the byte pointed to out of the data stream and 
deliver it "urgently" as if it was OOB data.
I exchanged mail with Jon Postel about this in 1984, and he confirmed 
that if a TCP protocol stack gets 2 TCP segments with different URG 
pointers, a TCP implementation can merge them and only deliver the 
latest URG pointer - which means that delivery of the OOB data is 
unreliable if you have more than 1 in flight at any one time; you might 
get the byte inband, and you might get it out of band.

This conflict of viewpoints between the protocol design and the API 
design has, I believe, rendered the TCP URG pointer useless for all 
practical purposes.

Returning to more relevant stuff: I think we need to handle PMTU issues 
somehow. This may be hard.

                   Harald