
Sequenced Packets Over Ordinary TCP - colinprince
http://urchin.earth.li/~twic/Sequenced_Packets_Over_Ordinary_TCP.html
======
tonyg
The urgent pointer mechanism is not reliable or well-implemented enough for
widespread use.

Excerpts from RFC 6093 (from 2011,
[https://tools.ietf.org/html/rfc6093](https://tools.ietf.org/html/rfc6093)),
"On the Implementation of the TCP Urgent Mechanism", which examines current
implementation practices in detail, and ultimately "recommends against the use
of urgent indications":

    
    
       Unfortunately, virtually all TCP implementations process TCP urgent
       indications differently. (sec. 3.1)
    
       All the popular implementations [...] interpret the semantics of the
       TCP Urgent Pointer as specified in Section 3.1 of RFC 793.  This means
       that even when RFC 1122 formally updated RFC 793 to clarify the ambiguity
       [...] this clarification was never reflected in actual implementations
       (sec 3.2)
    

Because implementations just never bothered to implement RFCs 1011 and 1122's
update, later in the document they _retract_ the advice given by RFCs 1011 and
1122, _overriding_ the earlier overriding of RFC 793, effectively returning to
RFC 793's definition for the urgent pointer! (!)

There's more:

    
    
       [...] an application might be unable to interoperate with itself if both
       the TCP sender and the TCP receiver are running on the same host. (sec 3.2)
    
       [S]ome middleboxes clear the urgent indications by clearing the URG
       flag and setting the Urgent Pointer to zero. (sec 3.4)
    

Ultimately: don't do it. You will not have a fun time.

    
    
       As a result of the issues discussed in Section 3.2 and Section 3.4,
       new applications SHOULD NOT employ the TCP urgent mechanism. (sec 5)
    
       Additionally, applications that still decide to use the urgent
       mechanism need to be designed for correct operation even when the URG
       flag is cleared by middleboxes. (sec 6)

~~~
twic
The idea in the article was to assign entirely new semantics to the fields
involved in the urgent mechanism, so the brokenness of existing endpoint
implementations doesn't matter.

Broken middlebox implementations, however, are one of the several reasons why
this idea is useless.

~~~
tonyg
I didn't get that from the article: I understood the idea to be to use the
existing implementations of the urgent pointer, in context of the BSDish
socket APIs we have, as message boundary markers. And, if that is done, we end
up in the mess that RFC 6093 clearly describes.

------
convolvatron
sctp
([https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...](https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol))
has both reliable delivery and transport level message framing. multistream,
multipath, and linux and bsd support.

not much uptake though. maybe if the quic people had built on it instead of
udp

~~~
peterwwillis
> maybe if the quic people had built on it instead of udp

I've noticed that all modern protocols are designed by lower-tier engineers in
teams in departments in corporations that want new functionality in some
product they make, but can't wait to propose a modification to an internet or
web standard that will take 5 years to get adopted by all the vendors and
service providers they want to use it, and they refuse to make a native app to
do it. This gives you protocols like WebSockets, WebRTC, QUIC. On the
application side you get things like WebAssembly.

So a few companies are slowly cobbling together their distributed operating
system for web applications called a "web browser". I think the unspoken plan
is to subvert all native computing platforms by evolving web browsers into a
reinvented Java-esque application platform. But ironically I don't think this
was intentional. I think everyone's just lazy and reinventing every wheel to
fit their niche, which just happens to be web apps. In 10+ years there may be
a new platform and paradigm, and all this stuff will be obsolete, even though
it'll do basically the same things.

~~~
dagenix
I don't see how any of this is true. The problem with SCTP is that middleboxes
don't understand it and tend to drop it. This create an unfortunate situation
where middleboxes refuse to support it because no-one uses it and no-one uses
it because middleboxes refuse to support it. You can't just create a standard
that says everyone should support SCTP and make everyone do it - standards
already say that middleboxes should support it and they don't.

Its bizarre that you picked WebSockets, WebRTC, and QUIC as examples of how no
one supports the standardization process. WebSockets were standardized via RFC
6455 in 2011, WebRTC via W3C, work with starting in ~2011, and QUIC
implemented in 2012, with IETF standardization currently underway. These are
all 6+ year investments by their sponsors.

~~~
wtallis
The sane development path would have been to build QUIC as a thin layer on top
of SCTP, with a fallback to UDP implemented only if it proved necessary. I
don't think the middlebox problem is a showstopper for a limited-audience
experimental protocol like QUIC, and a successful QUIC-over-SCTP experiment
could have gotten rid of the middlebox worries (by either motivating people to
get rid of the broken middleboxes, or by proving they weren't common enough to
care about), in much the same way that Apple's limited deployment of ECN has
eliminated the worries about middleboxes that kill ECN flows.

As for WebSockets, WebRTC, and WebAssembly, the fact that they've been
standardized within their insular niche says nothing about the extent to which
they duplicate functionality that has long existed outside the browser as part
of the host OS or as libraries that use the low-level networking constructs
that any native application has access to (but JavaScript didn't).

~~~
dagenix
The "sane" thing to do is to complicate the protocol by building it on top of
both SCTP _and_ UDP? How is it the "sane" thing to do to make the protocol
more complicated with a fallback that easily allows the middleboxes to just
ignore the SCTP option knowing that UDP will work? That wouldn't have
accomplished anything, except re-affirming that middleboxes tend to reject
SCTP at rates that make it unrealistic to adopt it at scale. What they did
accomplish, however, is getting an open protocol to the IETF for adoption that
works on the actual internet. I fail to see how that is some sort of
conspiracy or incompetence. And that isn't even taking into account that
building on top of SCTP would have made some of QUIC's goals hard / impossible
such as eliminating the penalty for establishing encrypted connections -
something which benefits the internet at large.

What open protocols / standards duplicate WebSockets, WebRTC, or WebAssembly?
TCP is kinda like WebSockets - but, giving any random JavaScript the ability
to open TCP connections is a bad idea - nevermind that WebSockets provides are
variety of useful abstractions such as messages. I'm not sure what you are
saying duplicates WebRTC - there are a bunch of proprietary protocols, I
guess, but, I'm not aware of anything open that its competing with. As for
WebAssembly, it explicitly works with JavaScript providing significant
efficiencies for certain types of code.

Google, Microsoft, etc have their faults. But, picking out instances of when
they have worked together, in the open, to create free, open standards that
benefit everyone to complain about is just super bizarre.

~~~
wtallis
> What open protocols / standards duplicate WebSockets, WebRTC, or
> WebAssembly?

Those aren't duplicating open protocols, they're just re-inventing the
operating system inside the web browser, but with more overhead and fewer
features and generally not even working as well as Java. The Web-* standards
just make it possible to do things inside the browser that are already
possible outside the browser, and are a bad idea to do inside the browser.
Their only advantage is that it makes it a bit easier for the developer to
deliver the "application", but it usually also results in the developer
leaving out a lot of functionality and refinement that a native application
would have.

------
gwbas1c
Just send either a 16-bit or 32-bit packet length before sending a packet.
Much easier than abusing the protocol, and the reader knows how large of a
buffer to allocate.

------
jrockway
I feel like when you start using protocol features you heard about from an
RFC, you just get disappointed, because they never work as well as the author
of the RFC envisioned.

Certainly if you have two nodes both using software that you control,
everything is going to be great. But that never happens. Someday, someone is
going to want a load balancer in the middle. Does your favorite load balancer
read the urgent flag in the TCP packet? Probably not. So now you are shaving
that yak, or rewriting your app when you don't actually control the code
(think cloud providers), wasting time and money because you read something you
thought was "neat".

If you want records in your TCP connection, define the first n octets of your
stream to be a record length. Read the length, then read that many octets off
the stream. There's your record. The next n octets of the stream are the
length of the next record... and so on. This will work with every TCP stack
everywhere, forever. Done.

As for RFCs, I've recently been working on an aggregator for syslog messages.
I read the RFC, and the protocol sounds quite nice, well-defined positions in
the stream for all sorts of relevant data like the time, hostname, and even
arbitrary structured data. Back in the real world, though, nobody read the RFC
and a syslog message looks like "'<' <some numbers that are supposed to be the
priority, but nobody can decide what the priority means so it's just some
digits that you throw away> '>' <arbitrary bytes that have no standard
meaning, sometimes there's something that looks like a timestamp or a
hostname, but really trusting a device to know its own name is way too much to
ask, and timestamps... don't get me started>". Sometimes the message ends with
a \n, but I wouldn't count on it.

TL;DR: it's nice that you read the RFC. Too bad nobody else did.

------
est
How am I supposed to work with it?

    
    
        s=socket.socket(socket.AF_INET, socket.SOCK_SEQPACKET)
        [Errno 43] Protocol not supported

~~~
lallysingh
You don't. Only the popular parts of TCP/IP are reliably implemented and
relatively bug free. Use those, ignore the stuff in this article.

