Hacker News new | past | comments | ask | show | jobs | submit login
RFC-1149: IP over Avian Carriers (wikipedia.org)
186 points by scottlocklin on June 5, 2019 | hide | past | favorite | 82 comments

Someone implemented it, too


64 bytes from icmp_seq=0 ttl=255 time=6165731.1 ms

I think more interesting than this RFC is the United States Army Pigeon Service. During WWII the force consisted of 54,000 pigeons. Over 90% of US Army messages sent by pigeons were received.


They must've implemented RFC 2549:


I remember reading that thinking "You know, you've taken a good joke a bit too far."

Or just TCP/IP/Pigeon

or IP over TCP (two carrier pigeons)

Well, at least sending data via flash-cards and pigeons isn't a joke.

"If 16 homing pigeons are given eight 512 GB SD cards each, and take an hour to reach their destination, the throughput of the transfer would be 145.6 Gbit/s, excluding transfer to and from the SD cards."

Today we have 1TB microSD cards, they only weight an 8th of an SD card.

If the capacity of a pigeon is 8 SD cards (1290,24cm³) then it can carry 64 microSD cards (1049,6cm³).

This means the capacity is now 64TB instead of 4TB. and the throughput would be 18,6 Tbit/s.

"Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway."

I think you should include the time to copy the data to the SD cards as a 1Tb copy is significant time.

At 170MByte/s that's another 100 minutes to get the data off a 1 TB microSD card using a Sandisk proprietary reader. You would need 64 of them working in parallel.

Here, an up-vote for you good Sir.

Please don't do this here.

I found HN during Lent this year. I’m not religious, but had been toying with the idea of leaving R quite for some time. Your 5 words express my exact sentiment, and exactly why I find HN so refreshing.

World's is going to shit anyways...so whatever you say :)

> Rafting photographers already use pigeons as a sneakernet to transport digital photos on flash media from the camera to the tour operator.[7] Over a 30-mile distance, a single pigeon may be able to carry tens of gigabytes of data in around an hour, which on an average bandwidth basis compares very favorably to current ADSL standards, even when accounting for lost drives.

> Inspired by RFC 2549, on 9 September 2009, the marketing team of The Unlimited, a regional company in South Africa, decided to host a tongue-in-cheek "Pigeon Race" between their pet pigeon "Winston" and local telecom company Telkom SA. The race was to send 4 gigabytes of data from Howick to Hillcrest, approximately 60 km apart. The pigeon carried a microSD card and competed against a Telkom ADSL line. Winston beat the data transfer over Telkom's ADSL line, with a total time of two hours, six minutes and 57 seconds from uploading data on the microSD card to completion of download from card. At the time of Winston's victory, the ADSL transfer was just under 4% complete.

See also the famous quote about the bandwidth of a pickup truck filled with magnetic tape... The modern equivalent would be AWS Snowmobile [0] which is described as follows:

> Each Snowmobile is a secured data truck with up to 100PB storage capacity that can be dispatched to your site and connected directly to your network backbone to perform high-speed data migration

A Wired article [1] calculated the San Francisco to New York bandwidth of a full Snowmobile as just under 5 Tbps which is pretty damn impressive, although the offload network connection on the truck is (only) a 1 Tbps connection. And it gets quite pricey, a fully loaded Snowmobile is USD 500K per month, plus the 350 kW of electricity it needs.

According to the FAQ, if you need more bandwidth, you can operate the Snowmobile trucks in parallel to get multi Exabyte scale data transfers, but I have difficulty imagining any of the use cases that would require that as a solution...?!?

0. https://aws.amazon.com/snowmobile/faqs/

1. https://www.wired.com/2016/12/amazons-snowmobile-actually-tr...

See also IP over Xylophone Players (IPoXP), which we actually built:

ACM DL: https://dl.acm.org/citation.cfm?id=2212785 Open PDF: http://stuartgeiger.com/papers/ipoxp-archive.pdf

Another gem from back when the internet was fun:

HTTP Status 418: I'm a teapot - https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418

Wasn't there also a protocol for checking vending machines for cold drinks?

You're probably thinking of 'The "Only" Coke Machine on the Internet'


I was at CMU '83 to '87. It saved us time to check if there was the proper kind of coke in the machine and if it was cold before we walked down to the room with the machine. It was cheaper than the University's vending machines. And it was in classy glass bottles.

Trivia: It was (I was told) using experimental 3Mbps Ethernet, the predecessor to the 10Mbps Ethernet that has grown to 10Gpbs+ now.

I forward this discussion to my sons saying that there is a story about coke machine. Here you go. Thanks.

Considering we actually have internet connected teapots now, I wonder if any mass market products have implemented this.

It's always been my dream to build one. Now that we have things like Raspberry Pi zero W, I want to hack up my Kuerig and make that internet connected

IIRC Ultimaker 3D printers do implement this

Nope, they recently removed that status code.

Only from clients supporting HTTP only. Note that RFC 2324 [0] defines the Hyper Text Coffee Pot Control Protocol or HTCPCP, which is an extension of HTTP and implementors of clients for this are free to return 418 if necessary. Also, RFC 7168 [1] which extends the protocol as HTCPCP-TEA now fully supports teapots, and is probably a better choice for modern clients. Also of interest is the SNMP MIB for remote management of 'Drip-Type Heated Beverage Hardware' which is defined in RFC 2325 [2] although this does not appear to have been updated with teapot, samovar, urn or other non-filter-coffee management data...

Implementing tea making device remote management would probably be a good candidate for a GSoC project or even a startup if you can find a VC gullible enough to fund you!

0. https://tools.ietf.org/rfc/rfc2324.txt

1. https://tools.ietf.org/rfc/rfc7168.txt

2. https://tools.ietf.org/rfc/rfc2325.txt

From the spec. Teapots or any other devices are free to send it anyway

Which is actually used in a few places. Google always return it from https://www.google.com/teapot, and Binance uses that status code if you've been IP-banned for exceeding rate limits.

I've worked on several big SaaS platforms, and all of them have at least one easter egg in there that returns teapot ;-)

Mandatory reading:


npm implemented it in their server last year!

Our team got hit by that issue. I slapped by head when I saw the error code, having come across it before. How am I meant to debug something that's literally a joke and isn't meant to be used in production :(


Still remember the day 30+years ago using my 2400 baud to connect to internet and discovered FYI articles and the zen of internet.

Much better than reading ICL and IBM manual (red book ok but no fun) I supposed and debug 370 assembler Abend code etc.


I wonder if someone fill the column and it is not empty say 1 bottle left. Then it is still not cold if someone else got say the 2nd one. Any source code available to check :-)

haha.. those were the days.. where you would get someone's resume over finger :)

I love it when a new generation finds all the fun RFCs.

The company I'm at hires a lot of interns, and it's always fun to see years old jokes make it into slack from people being exposed to it for the first time. The classic Little Bobby Tables XKCD was recently discovered. Makes me feel a little better about them trampling on my lawn.

Indeed, it’s a classic XKCD-1053 — https://xkcd.com/1053/

This reminds me of the old saying "never under estimate the through-put of a station wagon full of hard drives". It looks like it has disappeared from the internet but at one time someone had a calculator where you could enter the number of hard drives your station wagon could hold, the size of the hard drives and the time it took to drive across town from data center A to data center B and would tell you what bandwidth you would need to transfer the same amount of data using FTP. I suppose you could make the same calculation if you could make the MTU size larger that the carrier pigeon was carrying.

This is still true in astronomy. Data between radio telescopes for VLBI or the EHT is shipped in disk packs. I am not sure how Ice cube gets their data back from antartika, but I don't think it is over the thin and expensive satellite internet. Data from the gamma ray telescopes HESS and Magic are transported to their data centers on tapes.

EHT uses the next iteration of these, I believe: https://conduant.com/products/product/mark5c/

A talk I attended by Heino Falcke stated that each site is now recording data at 64Gbps. Astounding metrics. https://www.ast.cam.ac.uk/sites/default/files/talk_archive/H...

And clearly it still holds true because things like AWS Snowmobile[1] exist.

[1] https://aws.amazon.com/snowmobile/

I had an occasion 20-ish years ago to deliver a few DLT tape drives and a bunch of cartridges to a Customer. Before I left we calculated the capacity of a 1995 Geo Metro as a unit of backup media, and the effective throughput from our shop to the Customer at various driving speeds in bits-per-second. It was an odd trip thinking about my speed in Mbps.

Today, or course, it would be a Chevy Spark stuffed with micro-SD cards... >smile<

EvanAnderson: Hello Officer what the problem?

Cop: I clocked you at 532 Mbps, this is a 400Mbps zone.

EvanAnderson: Oh I didn't see the sign.

Cop: License and registration.

A similar calculator exists here! https://cable.ayra.ch/pigeon/

I seem to remember that the old saying comes from Tanenbaum's "Operating Systems Design and Implementation".

Or not?


> Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.

— Tanenbaum, Andrew S. (1989). Computer Networks. New Jersey: Prentice-Hall. p. 57. ISBN 0-13-166836-6.

Ha ! I own that book, that is where it wormed into my brain from :) Thank you!

Ahhh, you are correct. Thanks!

The wikipedia article on April 1 RFC's generally, is a treacherous time-sink of hilarity: https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for...

The good ol' days. Reminds me of this gem; a book review from 2000 of the book Ping The Duck on Amazon: https://www.amazon.com/review/R2VDKZ4X1F992Q

Disappointed that the link is to wikipedia and not the actual RFC. I think there's more value in reading the RFC first, specially if you don't immediately realize that "avian carriers" really does refer to pigeons.

Inspired by this, ~12 years ago we actually discussed encrypted reed solomon encoded Fedex UDP as a method for index updates instead of buying new fiber lines. Index update latency is a bit faster now.



   The IP datagram is printed, on a small scroll of paper, in
   hexadecimal, with each octet separated by whitestuff and blackstuff.
   The scroll of paper is wrapped around one leg of the avian carrier.
   A band of duct tape is used to secure the datagram's edges.  The
   bandwidth is limited to the leg length.  The MTU is variable, and
   paradoxically, generally increases with increased carrier age.  A
   typical MTU is 256 milligrams.  Some datagram padding may be needed.

   Upon receipt, the duct tape is removed and the paper copy of the
   datagram is optically scanned into a electronically transmittable

This is an abomination on mobile. Who can fix this presentation trap sooooo many people fall into?

Discussing RFC-1149 with Jon Postel is one of my favorite Internet memories... makes me think of him everytime this RFC is mentioned.

I am very (too) proud to have written Dr. Postel's favorite RFC.

-david waitzman author rfc1149 and rfc2549

Can you share anything about the discussion?

Don't forget the updated RFC: "IP over Avian Carriers with Quality of Service"


During the last 20 years, the information density of storage media and thus the bandwidth of an avian carrier has increased 3 times as fast as the bandwidth of the Internet.

RFC April Fools' jokes are good for a few laughs.


From the good old times, when IT people were allowed to laugh.

> In 2019, Cellular Tracking Technologies of Rio Grande, NJ demonstrated VultureNet, a component of the Internet of Wildlife. VultureNet is a system that uses very small tags ... on small birds and animals, and these are detected by receivers in devices on larger animals and birds ... data was transmitted from the device on the vulture to the Internet using the cellular network.

A store and forward network could be implemented on that.

I am all in favor of Plague-DSL: Municipal broadband by rat. The speed is not great, but bandwidth is and at least you get 100% coverage.

Wasn't there also a DARPA failsafe communication protocol painting digits on the sides of tanks?

Text of the RFC, which is one of the classic "April Fools" ones that the IETF does every year: https://tools.ietf.org/html/rfc1149

I just stumbled over this gem:

Internationalizing IPv6 Using 128-Bit Unicode

> This new 128-bit Unicode code point space can be leveraged by the IETF to address one of the lingering issues with IPv6: there's not much left to standardize. With the changes described in this document, the IETF will be kept busy for decades to come. It also enables new features and market opportunities, to help the global economy. This in turn will increase tax revenues for governments, which eventually may lead to increased funds for combating global warming. Therefore, the ultimate goal of this document is to reduce global warming.

Fun fact: I ported "IP over Avian Carriers" over to the web.


What with the NSA and colleagues ramming their noses into everything, this protocol has a future.

What if used bees instead of birds?

It would make it either much easier or much harder to implement a honeypot.

Also, combining the two into a "birds and bees" protocol might be idea for some kinds of traffic.

Considering I learnt this week bees have been shown to understand numerical symbols to the point of accociating them with quantity, using bees might be getting a little too close to Turing Complete for my liking. I mean, we all know how badly that turned out with PDFs, right?


> using bees might be getting a little too close to Turing Complete for my liking

Doom on bees. NetBSD on bees. Linux on bees. TensorFlow on bees. Software as a hive. Bees as a service.

All of that would be... the bee's knees.

Bees as a service has existed for quite a long time and is a pretty interesting business:


PDFs are not Turing complete (PostScript is).

I knew about postcript (who doesn't lock up office printers by rendering mandlebrot sents?) but was absolutely convinced PDFs were as well. They're not and it seems they quite deliberately weren't as well. [1] - thanks for setting me straight :)

[1] https://www.cs.odu.edu/~zeil/cs390/latest/Public/turing-comp...

Actually, you can have Javascript in PDF nowadays, so...

How about both? Birds and the bees.

"What kind of swallow?"

If you could load a few pigeons with microSD cards that would be something. The latency might be rough but the bandwidth would be killer!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact