
NoTCP - rcoppolo
http://notcp.io/
======
StephenFalken
A bit of UDP history by its creator [1]:

    
    
      Actually, UDP was "un-designed" by me and others.By this I mean that 
      UDP was the final expression of a process that today we would call 
      "factoring" an overcomplex design. Originally, the ARPANET end-to-end 
      protocol NCP was a "kitchen sink" oriented toward providing remote 
      teletype-centric access using the "telnet" protocol and the "FTP" 
      protocol to remote machines over a packet network.
    
      A group of us, interested in a mix of real-time telephony, local area 
      networks, distributed operating systems, and communications security, 
      argued for several years for a datagram based network, rather than a 
      virtual circuit based network. The group involved me, John Schoch and 
      Yogen Dalal of Xerox PARC, Danny Cohen of ISI (now at Caltech, I think), 
      and Steve Crocker, with Jon Postel as a supporter, and Vint Cerf and Bob 
      Kahn as neutral referees.
    
      UDP was actually "designed" in 30 minutes on a blackboard when we decided 
      pull the original TCP protocol apart into TCP and IP, and created UDP on 
      top of IP as an alternative for multiplexing and demultiplexing IP 
      datagrams inside a host among the various host processes or tasks. But it 
      was a placeholder that enabled all the non-virtual-circuit protocols since 
      then to be invented, including encapsulation, RTP, DNS, ..., without having 
      to negotiate for permission either to define a new protocol or to extend 
      TCP by adding "features".
    

[1] "udp and me" [http://www.reed.com/blog-
dpr/?page_id=6](http://www.reed.com/blog-dpr/?page_id=6)

~~~
chetanahuja
Exactly. For those of us who like to play around with protocols over the real
Internet, availability of UDP as basically a proxy IP protocol is a godsend.
Well what _really_ matters is that a few uses of UDP over the internet are
well established (DNS, VOIP etc.) and that makes it hard for ISP's and middle-
boxes to block arbitrary UDP ports. And _that_ makes UDP the perfect conduit
to invent custom protocols.

------
derefr
Yes, this is a joke, but it's a ha-ha-only-serious kind of joke.

A rhetorical question: if other protocols are better at this or that, what
forces have made TCP the only transport protocol of note for so long?

Well, in TCP, _window scaling_ needs to be OS-global to avoid flapping. This
means TCP lives in the kernel. And _this_ means, if you want a protocol with
any property similar to window scaling, it _also_ needs to live in the kernel.

Which is to say, if you want your protocol to do anything that requires
machine-level resource pooling, it has to be machine-global, not app-local.

This is true trivially if your protocol wants to live in layer-4; anything
peer to TCP or UDP has to have its own kernel driver in every major OS, and in
every major firewall/load-balancer/NAT appliance.

But even when you build on top of UDP on "layer 4.5", you're still under the
same constraint. Even if you're not in the kernel, you still need a single-
instance-per-machine daemon or somesuch. You still need to install something
as root. The 1993-era user story of "my ISP just told me to enable something
called NetBEUI!?" still applies.

The reason much of this will be decreasingly relevant?

Unikernels.

If your app has guaranteed 1:1 ownership of a "machine", then your app can
speak whatever wire protocols it likes; an app-level resource pool _is_ a
global resource pool.

Unikernels _talking to other unikernels_ can easily make use of new layer-4
protocols. That's exciting!

Combined with the coming wave of "cloudlets" (small VMs paired to an
individual customer of a device manufacturer or ISP, where the customer's
mobile devices and home network use the cloudlet as a featureful VPN proxy),
these new layer-4 protocols can be tunneled out to customers, too, avoiding
any and all intervening muck.

The next 10 years of networking will be interesting!

~~~
fmstephe
Can you expand on why "window scaling needs to be OS-global to avoid
flapping". I have googled it and a I got to

[http://en.wikipedia.org/wiki/Route_flapping](http://en.wikipedia.org/wiki/Route_flapping)

and I couldn't work out how this related to TCP living in the Kernel.

Not trolling, real question. Thanks in advance.

~~~
KaiserPro
the TCP stack is controlled entirely by the kernel. so it handles things like
requesting dropped packets and rate limiting.(which relates directly to
"packets in flight")

with UDP, that layer of ACK, ordering and rate limiting is gone.

if you want to send a million packets a second to 56k modem, sure the kernel
isnt going to stop you.

Whilst it might be possible to have per TCP connection windowing parameters, I
doubt it'd be very efficient.

~~~
haberman
> Whilst it might be possible to have per TCP connection windowing parameters,
> I doubt it'd be very efficient.

If you had kept going here and explained why you doubt that, you would have
answered the parent's post.

------
eloff
Aeron from Martin Thompson of mechanical sympathy fame uses a custom, reliable
protocol over UDP to achieve much lower latency than is possible with TCP
solutions. There seems to be a growing awareness that one-size fits all
protocols like TCP don't necessarily offer the best tradeoffs, even when you
need reliability. [https://github.com/real-
logic/Aeron](https://github.com/real-logic/Aeron)

------
tcgarvin
There is no better way to get to the top of HN than by writing something so
deadpan sarcastic that all parties think you're secretly on their side.

------
ianamartin
I completely lost it when I got to this line: "So suppose we’re
conscientiously setting artisanal timeouts for all our TCP messages."

Well done.

~~~
jcoffland
Yeah that line bothered me too. Still I thought the content of the article was
valid.

------
eeZi
TCP has an advantage over UDP which hasn't been mentioned yet in this thread:
it effectively prevents source IP spoofing. This is a huge issue for some UDP-
based protocols, since it allows an attacker to send a packet with a spoofed
source IP address. The response is then sent to that IP address. Protocols
like DNS and NTP, which send large answers for comparatively small requests,
can be misused for DDoS attacks this way (amplification).

~~~
gnopgnip
This is a solved problem with BCP38. By filtering ingress traffic that does
not originate from the networks they claim to be from handshakeless protocols
are possible and abuse is prevented.

~~~
PhantomGremlin
A quick read of Wiki tells me that BCP 38 was introduced by RFC 2827 in May
2000. But it's still not a "solved problem" since many ISPs and companies
don't implement it.

How do you get more widespread adoption? It's been 15 years.

------
andrewmcwatters
This is not new. This is an attempt to make something that has existed for
decades seem new, hip, and edgy. Prefixing "no" to existing traditional
technologies does not make something new or cool.

The only people who would buy into this are people who have no experience with
networking, and thus this would only affect their probable usage of libraries
down the road with the wrong intentions.

Hell, I don't even know who this is really suppose to address. My best guess
is people with very little knowledge of network protocols and their usages.

~~~
amyjess
This is a joke. They're making _fun_ of NoSQL and its ilk.

~~~
golanghacker4
I don't think they are. Other than the first paragraph, with its self-
deprecation and references to Node.js and NoSQL, which seems intended to head-
off the derision such a hipsterish manifesto would rightly incur, the rest
seems entirely serious.

~~~
nemo
The very last link in their "are you serious?" section is the sentence "Or
maybe you have some clue about how the internet actually works, and you don’t
need a manifesto to tell you what you already know" with a link to an article
titled "TCP doesn't suck, and all the proposed bufferbloat fixes are
identical." I read the whole thing as a joke, and I don't see anything that
suggests otherwise anywhere in it.

Seriously, how can you read "just as the Reactive Manifesto reminded us that
new branding can give a youthful glow to decades-old ideas" as anything but
funny?

------
hueving
Holy shit this trolled me hard. I was raging reading about how people were too
dumb to understand how to handle TCP failures but were apparently smart enough
to re-implement re-ordering and error recovery in their own manner.

Well done.

------
kstrauser
I couldn't agree more. TCP is wonderful _when you need it_ , but you very
often don't need it (and pay a heavy price for features you don't need).

I wouldn't want to write HTTP over UDP, but neither would I want to send
telemetry data ('{"timestamp":343821902, "value": 43}') over TCP. UDP is
brilliant for systems where you're more concerned about tracking the current
state of things than accurately replaying the last n set of transactions.

~~~
lechuga
Disagree. In most cases you want TCP. Rarely do applications gracefully deal
with loss.

~~~
fla
Simple example: Player positions in a FPS.

Would you rather wait for a transmission of the missing position update 1 sec
ago or just forget about it and continue processing the next one ?

In this context, you'll prefer the second option. It will probably cause a
visual glitch but the game can go on, and players will say "lag" :)

~~~
lechuga
Yes. You can show me a relative corner case. But in most cases you want TCP.

~~~
fla
It's far from being a corner case. UDP is commonly used in multiplayer games
to provide a channel for unreliable data.

------
istvan__
"yet another hipster technology manifesto" so good content. I guess it is a
good summary what is wrong with the tech industry (lots of "solutions" are
abused, built for different era, etc.) and also bashes a bit on technology
like node.js but not too much. Entertaining read.

~~~
2times
This is the best summary of what it is, and indeed an entertaining read.

------
amyjess
I lost it at "renaissance of artisanal protocols".

------
chetanahuja
I honestly can't make out if the author is trying to be serious or sarcastic.
For instance:

 _" We follow in their Chukka-booted footsteps by challenging the comforts of
the ubiquitous Transmission Control Protocol and recognizing the well-deserved
renaissance of artisanal protocols built on UDP. We didn’t start this fire,
we’re just calling it what it is: the NoTCP movement"_

I'd admit to being too dumb to parse the exact sentiment behind that
paragraph. Though it does sound somewhat like sarcasm to me.

Then in the rest of the paragraphs, he actually goes on to make a pretty good
case of why one might want to get rid of TCP (especially from under the
complex beast that HTTP/2.0 is with it's own flow-control, multiplexing etc.)

For what it's worth, I wrote my own manifesto against using TCP in all cases a
few weeks ago. But this one is geared very specifically towards the needs of
mobile native apps.

[https://packetzoom.com/blog/](https://packetzoom.com/blog/)

------
jchrisa
If you like the idea of REST over UDP
[http://coap.technology/](http://coap.technology/) has been around a while,
seems to have traction.

------
zw123456
One serious argument for using a connectionless protocol is mobile. The reason
is that mobile networks have a MAC/RLC layer (talking 3G/4G here, e.g. LTE)
and those layers have ARQ (in other words retrans). At times, those re-trans
can spike (sudden Signal drop for example). That will blow the RTO on TCP and
you get needless TCP retrans. This is where you have to competing retrans
mechanisms flapping. The obvious fix would be for the mobile operators to
terminate the TCP flow at the base station and use the Hybrid ARQ mechanism,
although that could happen eventually, but would mean a lot of re-design for
them i.e. cost. So if your app is going to be on mobile, it might perform
better using a connectionless protocol depending on the situation.

------
deutronium
I like the irony of serving the message via TCP

~~~
corysama
From their twitter account
([https://twitter.com/notcp](https://twitter.com/notcp))

> Sign the manifesto: [http://notcp.io](http://notcp.io) . If you can figure
> out a way to sign it using UDP, let us know.

It's pretty clear they know they are being ridiculous.

That said, it is nice to have reminders that there are alternatives to the
overwhelmingly popular default. Kids these days grow up using TCP so much they
become devs who can't conceive of whole categories of software that don't
happen to line up with the tradeoffs designed into TCP. Heck, seems like most
people have a hard time remembering that there's more to the Internet than
HTTP.

~~~
takeda
I personally prefer it to being that way.

UDP while is very simple from design point of view is actually very
complicated to use if you plan to do something more than just send few
packets.

The issue is primarily, that you don't have a feedback loop that tells you the
rate at which you should send the data. Also badly written applications that
use UDP can create congestion collapse in a network (no congestion
control/avoidance).

------
nosideeffects
I don't know if the actual post is funnier, or the fact that this is just
satire went over so many people's heads.

------
jcoffland
This article has a ring of truth. With HTTP/2 gaining traction I cannot help
but wonder if a lot problems could be solved by going down a level of
complexity instead of stacking more layers on top of TCP.

For example why not allow UDP from Javascript in the browser with CORS like
protections to limit DOS attacks. I.e., only allow UDP connections back to the
origin unless the server explicitly allows non-origin access from the
requesting domain.

This approach seems a lot simpler and opens the doors to all kinds of
improvements not just those designed into HTTP/2.

------
Sami_Lehtinen
Tons of discussion and nobody mentioned this:
[https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protoco...](https://en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol)
Reason for using TCP is that using UDP requires application specific
implementation and making it good and efficient would require more work than
making rest of the software. That's why the applications only use UDP where it
really does make difference. Others just won't bother.

------
pyre
Notably, ICQ was implemented over UDP, though IIRC they basically implemented
most of the features of TCP on top of UDP when creating their protocol.

------
verbatim
What ever happened to SCTP, anyway?

~~~
wmf
It was designed by telcos for telcos; I don't know if they ever got around to
using it. It can't be used in the normal Internet because it doesn't pass
through NATs.

~~~
noselasd
You interact with it every day if you use a cell phone. The control plane of
the nodeb/enodeb(or "cell towers") and further into the core network in
UMTS/LTE is using SCTP. Control messages for voice calls and SMS is carried a
top of SCTP. Control plane interconnect between carriers for roaming is done
over SCTP.

(Though there's still plenty of gear still using TDM or ATM)

------
kazinator
The only problem is: good luck getting corporate firewalls to support
connection state tracking for your custom UDP-based protocol, and getting IT
managers to turn this on.

------
jokoon
I don't see the point of the joke/sarcasm. UDP has its use if you want to have
real time stuff and more granular and fine-controlled data. TCP is just for
larger batches.

Of course UDP is useless in many cases, but it does have its uses.

It looks like this is just mocking people who can't follow the "don't reinvent
the wheel" rule, but why assume that all types of wheel are already invented?
P2P networking needs fine control. Bare metal is not here for nothing.

------
peterwwillis
Once the non-TCP protocol has been written, we'll need to make sure it's
portable through corporate and ISP firewalls, so we should write an HTTP
extension that tunnels the non-TCP protocol over HTTP proxies without using
CONNECT, and on port 80. We'll need to patch the proxies and the browsers and
the web servers, of course, but it's all in the name of a better, newer
protocol that doesn't have the clunky overhead of TCP.

~~~
zokier
I thought Googles experiments have showed that this is less of an issue that
what people generally think. Most networks pass UDP traffic just fine. And
most failures occur early phase enabling reasonable fallback policy to TCP

~~~
peterwwillis
Most networks aren't what you think they are.

For example, most modern-day commercial firewalls more closely resemble a NAT
machine than anything else. All your packets may be changed as they pass
through in order to verify their authenticity and integrity once they return.
And if the protocol isn't supported, it may not be passed through at all.

If you want to support existing networks, it has to be either TCP or UDP. In
order to support next-generation firewalls, you also have to use the OS's
tcp/ip stack. In order to support typical commercial network/proxy
configuration, you have to use a higher level protocol like HTTP. And this
isn't even talking about the "features" of the different protocols and how
they're handled.

A replacement for TCP has to be done by a standards body and accepted by
vendors, or [at least] half of the world will never be able to use it.

------
snowy
From Article:

"are you serious?

Oh, absolutely. There are plenty of successful, purpose-built protocols that
used UDP before it was cool: DNS, NTP and RTP, to name a few."

DNS and NTP are built over UDP because they are light weight applications. RTP
is built over UDP because you don't care about loss. Hell even DNS still uses
typically uses TCP when doing zone transfers between DNS servers because of
the amount of data involved.

What point is the author trying to make with this statement?

------
tylermauthe
Kind of tired of the "your technology is Hipster swill" parodies.

All technology is a tool, use the right tool for the job and move on.

------
citrin_ru
It seems to be they don't understand TCP. Indeed, TCP has drawbacks, but
without studying TCP they probably repeat old mistakes and will add new ones
(not present in TCP).

------
avodonosov
Good thing (as well as in-process TCP stack implementations). One note: text
of black color would be much easier to read than this light gray.

------
fegu
abou Quic: "you probably haven't heard about it". Gives the true condescending
hipster feel :)

------
jessaustin
Why the hell is wnevets' comment flagged? Does this just happen automatically
when enough downvotes pile up? If "flagged" is a separate thing for really
objectionable stuff then it doesn't make sense in this case.

~~~
wnevets
my comment was flagged? hmm.

~~~
jessaustin
Yes the "how cute" comment is still displayed to me as "[flagged]", as well as
being completely grayed out.

~~~
jessaustin
Oh this is nice. Simple points of order concerning HN operation are downvoted
now? (Hint for drive-by downvoters: if you don't know what we're talking
about, you probably have "showdead" set to "no".)

~~~
wnevets
>you probably have "showdead" set to "no".)

I did but I can still see my comment as normal.

~~~
jessaustin
Open the page in an incognito tab, so HN won't know who you are. (or log out
if you prefer) I expect that your original comment will no longer be visible.
This appears to be similar to the hellban functionality, in that it's hiding
from you the fact of flagging this one comment. Although I have no problem
with the use of hellbanning, I don't see how the behavior we see here, with
respect to a mildly sarcastic response to more strident sarcasm in TFA, could
be considered a good thing. Hmm, maybe I'll write a Chrome extension to remove
this misfeature.

~~~
wnevets
thats what it sounds like, whats kinda funny it had 3 points before getting
flagged.

------
ilaksh
I think they are actually serious. And it makes sense. TCP is holding back a
lot of stuff. Its a legacy thats grandfathered in and we can do better both in
terms of general purpose and specific needs.

------
cwh
i read this website as "not cpio"

------
jwr
Tiny type, disabled zoom. Hipster indeed.

------
facepalm
But is it web scale?

------
jjar
I read this as Not CP...

------
me_bx
These guys should make their site's even text smaller, thinner, and lighter in
color.

For the moment, we still notice that there's something that we're supposed to
read.

[http://contrastrebellion.com/](http://contrastrebellion.com/)

Sorry for the rant, that's the final straw...

~~~
jcoffland
I have found that high contrast is actually bad for my eyes. I regularly spend
8+ hour stretches programming. If my screen is black on white my eyes get
tired after about 6 hours. If it's white on black I get similar but less
pronounced results. However, if I use a light grey on a dark grey, with
moderate contrast, I can work indefinately, or at least my eyes are no longer
the limitation.

~~~
mikeash
Rather than have web sites alter their color schemes to suit you, and cause
trouble for others in the process, why not turn down the contrast on your
screen?

~~~
Avernar
I have my monitor calibrated for photo editing. I'm not going to mess with the
brighhtness and contrast because some site is using a hard to read colour
combination.

If it's a site that's worth reading I'll overide the CSS with Stylish
otherwise I'll just not bother reading the site. It's funny how many sites
fall into the later category.

~~~
mikeash
Good answer! It didn't occur to me that there might be useful calibrations
where, say, pure black on white is hard to read, but you still want pure black
and white to be at those levels for other purposes.

------
Nadya
I'm scared to click the link because of the URL. ... ... ...

~~~
vezzy-fnord
Don't worry, it's just "yet another hipster technology manifesto" (their
quotation).

------
gtrubetskoy
"UDP" would have been a better name than "NoTCP". (Because non-TCP would also
include ICMP, for example). Also, why not just go to IP, rather than UDP? Much
more flexible than UDP and even more efficient.

------
golanghacker4
"Oh yes indeed. Just as Node.js and NIO proved to the world that bare-metal
performance is always worth the consequent unreadable code"

Node.js is hardly bare metal and non-blocking IO is hardly new; Unix
programmers have been writing select()/event-loop and poll()/epoll() servers
for decades. The presentation of this false dichotomy between Node.js
representing "bare-metal" at one end and readable code at the other suggests
the author is some type of opinionated Ruby/Rails hipster programmer upset
that his pet language and framework is falling out of favor, and in no small
part because of its abysmal performance.

~~~
AceJohnny2
I'm not sure, but I think the author was being sarcastic?

I mean, I can hardly imagine "node.js" and "bare-metal performance" being in
the same phrase and not being sarcastic.

~~~
golanghacker4
No, I think the author genuinely views Node.js/NIO as a bad
performance/readability trade-off that was over-hyped and inferior to other
existing platforms.

~~~
EdwardDiego
Well, they're right that NIO code is pretty low level and hard to read. But
then, 95% of Java devs won't need to touch NIO, they'll just use Netty which
does all the NIO for them.

------
Navarr
This is too low level for me.

I don't care. I don't care about TCP, I don't care about UDP, I only care
about QUIC because I'm a Google fanboy.

I shouldn't have to care about this. All I want is some very fast, very
reliable underlying protocol for my web apps and api endpoints to run on.

~~~
tjbiddle
Hacker News caters to a wide audience. While it may not be of interest to you,
someone else is geeking out over it.

