RFC 218705161
Network Working Group P. Schaefer
E2 Softlinking Division E2 DOG
Request For Comments: 08.12.2004
Status of this memo
This RFC describes an experimental
protocol for audio transmission to be employed by
canines for the transfer of urgent messages. A test of the protocol has been witnessed firsthand by the author. As an
Internet-Draft, it awaits approval by
IETF IAB.
Intent and Scope
In contrast to defining an unyielding dogma, this RFC focuses on an extensible framework for messaging and basic transmission content. Unlike
RFC 1149 and
RFC 2549, which has strictly defined routes, this RFC is considering an informally connected network infrastructure, forming a larger network from
LANs. While variants of this protocol can easily be simulated on the
application layer, the protocol is optimized for acoustic data links.
Why there is a need for such a protocol
Imagine a dog that has been locked up in a car in the summer. It is getting hot, temperature inside the car is rising, the dog is getting
dehydrated and will get a
stroke. Clearly the dog needs to signal to his owner and best friend that it needs help. However, the owner is out of range for direct audio transmission and visual contact is not available. If the owner hears any dog bark, he surely will remember.
Approach
To signal his distress, the dog will start an audio broadcast, which is picked up by other listening dogs in the proximity. Based on the information contained in the transmission, these other dogs will decide whether to act as repeaters for the transmission. The implementation of the decision algorithm is up to the individual dogs, though we expect a standard to emerge soon, which is left to another RFC.
Terminology
- dog
- Any node at the center of a local network with the capabilities for listening and broadcasting.
- sender
- A sender of acoustic messages
- recipient
- The final intended recipient of the message. The sender MAY specify a non-matching recipient signature for the purpose of a network scan.
- repeater
- a dog that received a message and decides to repeat it by broadcasting it on its network.
Message blocks
A message is composed of the following blocks:
- class
- The class of the message. Potential repeaters will use the class to determine whether to repeat the message and the appropriate acoustic level.
- recipient signature
- A signature that describes the recipient. The signature is computed from audiovisual and olfactory cues.
- sender signature
- a unique audio signature of the sender
- orig-from signature(optional)
- The unique audio signature of the initial sender. This SHOULD be modified by distance indicators, when repeated. It is an OPTIONAL field; the repeater MAY omit it if it has determined the message class signals a broadcast.
- end of message indicator
- extensions to the protocol MAY replace this indicator with additional data indicators.
Message Meta Data
Distance can be measured by implementing a built-in element of signal decay, putting transmission errors to good use. Repeaters SHOULD modify the sender signature when repeating the message. Repeaters MAY modify the recipient signature to reflect additional information available to them.
Repeating decision algorithm, minimum requirements
A candidate repeater SHOULD implement a repeating decision algorithm such that the likelyhood of deciding to act as a repeater increases with the probability that the receiver is closer to the repeater than to the sender. This ensures efficiency of the protocol.
These requirements have been chosen to give the additional benefit of being able to scan for the recipient by increasing the frequency and total volume of transmissions near the recipient.
Security
Since this is a public broadcast protocol, there is no expectation of privacy.
Denial Of Service is a serious concern, and is mitigated by delegating the task of deciding which message to repeat to the candidate repeaters. These SHOULD reduce their responsiveness when receiving too many messages of the same class, recipient or senders. Owners of broadcasting dogs not following this rule risk prosecution under 42
United States Code 4901-4918 or similar local laws.
It is recommended that dogs are subjected to scheduled worm cures. Dogs can handle most of the usual dog viruses by themselves, and dog
trojans are virtually unheard of.
Author
P. Schaefer
Barkley Street
17337 Dog's Bay, 100 DB.
Contact: Highlander@everything2.com
Version 2004.1.0
Free replication allowed on electronic media.
Amendment allowed, provided version number is changed.
I realize that this is not as funny as publishing this on the actual RFC mailing lists, like RFC 1149, but I tried to make the best of the idea. In the effort to make this technical, maybe it got too technical. I hope though that someone will appreciate the absurdity of going into the technical details - the algorithm just might work. Scrutinize the id number of this RFC.