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

[Justin Uberti <[e-mail]>]

On Sun, Jul 24, 2011 at 8:20 AM, Harald Alvestrand <[e-mail]>wrote:

> 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<harald@alvestrand.**
>>> no <[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<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<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.
>

The easy way may be to do what we're likely to do for RTP data: assume a MTU
of 1280 (IPv6 minimum MTU) and packetize as such, leaving PMTU discovery as
a future optimization.


>
>                  Harald
>
>
>