RFC 2549

IP over Avian Carriers with Quality of Service

πŸ“… published April 1999, from ietf

IP over Avian Carriers with Quality of Service πŸ¦‹

Okay bestie, the title block first πŸ’… This is RFC 2549 from the Network Working Group, written by D. Waitzman of IronBridge Networks. It's Experimental (not a standard, obviously πŸ™ˆ), dated 1 April 1999, and it updates RFC 1149. Yes, it's dated April 1st, and yes, we're keeping that energy.

Status of This Memo ✨

This memo defines an Experimental Protocol for the Internet community. It is not an Internet standard of any kind. The authors want your discussion and suggestions for improvement, and distribution of this memo is unlimited πŸ’–

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract 🌸

This memo amends RFC 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers", with Quality of Service information. It's experimental, and it's "not recommended standard" (lowercase, as the original says) 🫢

Overview and Rational πŸ¦‹

Okay so there are four QoS levels: Concorde, First, Business, and Coach πŸ‘‘ Concorde is the expedited delivery class, so it's giving speed. The biggest perk of Avian Carriers is that they're the only networking technology that earns frequent flyer miles 😭 Plus, Concorde and First earn 50% bonus miles per packet. Iconic. Ostriches are an alternate carrier with way more bulk transfer capability, but they're slower and need bridges between domains 🦩

The service level is marked on each carrier with a bar-code on the wing πŸͺ½ One way to do it is to have a bar-code reader scan each carrier as it enters the router, then enqueue it in the right queue. The queue is gated so nobody leaves until the proper time. The carriers may sleep while they wait, which is honestly relatable πŸ’€

For secure networks, carriers can be Prime or Choice πŸ” Prime carriers are self-keying when using public key encryption. Some distributors have been known to falsely classify Choice carriers as Prime, and that's a whole mood πŸ’€

Packets MAY be marked for deletion using RED paint while enqueued 🎨

Weighted fair queueing (WFQ) MAY be implemented using scales, as shown 🧚

                                                  __
                                  _____/-----\   / o\
                                 <____   _____\_/    >--
                 +-----+              \ /    /______/
                 | 10g |               /|:||/
                 +-----+              /____/|
                 | 10g |                    |
                 +-----+          ..        X
               ===============================
                              ^
                              |
                          =========

Carriers that sit in the queue too long may leave log entries, as shown on the scale πŸ“

Here's a plot of traffic shaping, from coop-erative host sites πŸ“ˆ

     Alt |       Plot of Traffic Shaping showing carriers in flight
         |
      2k |           ....................
         |          .                    .
         |         .                      .
      1k |        .                        .
         |   +---+                          +---+
         |   | A |                          | B |
         |   +---+                          +---+
         |_____________________________________________

Avian carriers normally bypass bridges and tunnels, but they'll seek out worm hole tunnels πŸŒ€ When they're carrying web traffic, they may digest the spiders, leaving behind a more compact representation πŸ•·οΈ And yes, the carriers can get confused by mirrors πŸͺž

Round-robin queueing is not recommended. Robins make for well-tuned networks, but they don't support the necessary auto-homing feature 🐦

A BOF was held at the last IETF, but only Avian Carriers were allowed in, so we don't know the results. What we do know is they think MPLS is great πŸ₯Ή Our attempts at attaching labels to the carriers have been met with resistance πŸ™ƒ

NATs are not recommended either. As with many protocols, modifying the brain-embedded IP addresses is difficult, and Avian Carriers MAY eat the NATs 🍽️

Encapsulation may be done with saran wrappers 🌯 Unintentional encapsulation in hawks has been known to happen, and decapsulation is messy with the packets mangled 🫠

Loose source routes are a viable evolutionary alternative, enhanced standards-based MSWindows-compliant technology. But strict source routes MUST NOT be used, because they are a choke-point 🚧

The ITU has offered the IETF formal alignment with its corresponding technology, Penguins, but that won't fly 🐧

Multicasting is supported, but it requires a clone device πŸ‘― Carriers may be lost if they're based on a tree while it's being pruned. The carriers propagate via an inheritance tree. They have an average TTL of 15 years, so using them in expanding ring searches is limited ⏳

Additional quality of service discussion can be found in a Michelin's guide πŸ“

MIB and Management issues 🧾

AvCarrier2 OBJECT-TYPE
  SYNTAX     SEQUENCE OF DNA
  MAX-ACCESS can't-read
  STATUS     living
  DESCRIPTION "Definition of an avian carrier"
  ::= { life eukaryotes mitochondrial_eukaryotes crown_eukaryotes
        metazoa chordata craniata vertebrata gnathostomata
        sarcopterygii terrestrial_vertebrates amniota diapsida
        archosauromorpha archosauria dinosauria aves neornithes
        columbiformes columbidae columba livia }

AvCarrier OBJECT-TYPE
  SYNTAX     SET OF Cells
  MAX-ACCESS not-accessible
  STATUS     obsolete
  DESCRIPTION "Definition of an avian carrier"
  ::= { life animalia chordata vertebrata aves
        columbiformes columbidae columba livia }

PulseRate OBJECT-TYPE
  SYNTAX     Gauge(0..300)
  MAX-ACCESS read-only
  STATUS     current
  DESCRIPTION "Pulse rate of carrier, as measured in neck.
               Frequent sampling is disruptive to operations."
  ::= { AvCarrier 1}

The carriers won't line up in lexigraphic order, but they'll naturally order themselves into a large V shape πŸ”Ί Bulk retrieval is possible using the Powerful Get-Net operator πŸ’ͺ

Specification of Requirements πŸ“œ

In this document, several words are used to signify the requirements of the specification. These words are often capitalized.

  • MUST: Usually.
  • MUST NOT: Usually not.
  • SHOULD: Only when Marketing insists.
  • MAY: Only if it doesn't cost extra.

Security Considerations 🚨

There are privacy issues with stool pigeons.
Agoraphobic carriers are very insecure in operation. Please take this seriously, bestie. πŸ™ˆ

Patent Considerations βš–οΈ

There is ongoing litigation about which is the prior art: carrier or egg πŸ₯š

References πŸ“š

Waitzman, D., "A Standard for the Transmission of IP Datagrams on Avian Carriers", RFC 1149, 1 April 1990.

ACKnowledgments 🫢

Jim.Carlson.Ibnets.com > Jon.Saperia . ack 32 win 123 (DF)
Ross Callon, Scott Bradner, Charlie Lynn ...

Author's Address πŸ’Œ

David Waitzman IronBridge Networks 55 Hayden Ave Lexington, MA 02421 Phone: (781) 372-8161

EMail: djw@vineyard.net

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

πŸ“¦ where this page comes from