There's been a whole lot of chatter recently
about whether or not it's sensible to require
balanced peering ratios when selling heavily
unbalanced services to customers.
There's a very simple solution, it seems.
Just have every website, every streaming
service, every bit of consumable internet
data have built-in reciprocity.
You want to stream a movie? No problem;
the video player opens up a second data
port back to a server next to the streaming
box; its only purpose is to accept a socket,
and send all bits received on it to /dev/null.
The video player sends back an equivalent
stream of data to what is being received in.
The server receiving the upstream data stream
checks the bitrate coming into it from the player,
and communicates back to the video streaming
box every few minutes to lower the outbound
bitrate going to the player to match what the
inbound bitrate coming from the client is.
That way, traffic volumes stay nicely balanced,
and everyone is happy. For extra credit, and
to deal with multiple layers of NAT in the v4
world, you could even piggyback on the same
stream, though that would take just a bit more
work.
Mobile apps could be programmed the same
way; you download a certain amount of data,
an equivalent volume of data is sent back
upstream to balance it out, and preserve
the holy ratio. Even web pages could use
javascript footers to send back upstream an
equivalent amount of data to what was
downloaded.
Once and for all, we could put an end to
the ceaseless bickering about ratios, as
everyone, everywhere would be forced
into glorious unity, a perfect 1:1 ratio
wherever the eye should look.
As far as I can tell, this should solve
*everyone's* concerns from all sides,
all in one simple effort.
Matt
You mean consume electricity in cpu cycles on the end devices and all the
network middleboxes in between all over the world/Internet for dud data?
For what? Just to stop a debate instead of resolving it thought
intellectual brainstorming? For one thing it will slow down the TCP
connections as ACKs incur a longer RTT. Then there is the whole question of
managing and lowering power consumption as a green initiative, and
capacity issues are yet another thing.
~Rahul
Congratulations, Matt, on coming up with a proposal that was *stylistically*
in keeping with the one from which you stole the idea for the title. 
Cheers,
-- jra
You can push the stream back to offloaded cloud now:
http://devnull-as-a-service.com/
I agree symmetry alone is a bad metric and efforts to build a service, or
artifically game traffic in order to create symmetry will likely have
negative consequences all around.
I can¹t speak for all situations, but I believe relative ³balance" was
designed to be one of several criteria which outlines the definition of a
³Peer² in the Internet's current two sided market. It is one criteria
which helps define some measure of economic trade of network investment to
carry traffic between respective customer networks and helps avoid
exploitation of the trade relationship.
- Kevin
Actually, pretty focusedly more negative for the middlemen trying to charge for those packets' transit of their networks.
-george william herbert
george.herbert@gmail.com
I agree with Rahul, seems like pointless cycles along the entire path.
Wow nanog, dissecting the architecture of a sarcastic proposal.
Maybe the joke would have been clearer if Matt had used the phrase "a
modest proposal" ..
You shouldn't of stopped them I was eagerly waiting to find out how rtt was going to be increased
-jim
Original Message
1. Take the understanding that the media player will return the stream
it received. For the sake of expediency and avoiding
unnecessary waste (Enhanced efficiency), I suggest the introduction
of a new frame format, the "Null reduced frame" and "Null reduced
IP packet".
This is an IP packet which logically contains N bytes of payload,
that is to be transmitted without its payload, but is to be
"understood" as having contained those N octets of payload data, for
administrative and billing purposes; where N is some number between 1
octet and (2^32 - 1) octets.
The media player can then emit these Null-reduced IP datagrams that
contain no ordinary physically payload --- a flag will be set in the
return packet and the frame when transmitted to indicate, that
although the IP datagram physically contains no actual data, it
MUST be counted on all device interface counters and Netflow reports
as X octets, and treated as having contained N octets for the
purposes of billing and peering negotiations.
Ah! So somebody nudged me and pointed out that this is a reference to a
satirical story and a standard part of the American curriculum.
You shouldn't of stopped them I was eagerly waiting to find out how rtt
was going to be increased 
-jim
Heh. Well I was thinking along the lines of the effect of 100 streaming
users all filling up the router queues in the path to the server, with
full size packets (or replicas of the incoming) where in the normal case a
smaller ACK packet would be sent for every other TCP segment transmitted
by the sender.
Now I get the joke.
Rahul
I can improve on your proposal.
Have the player return four copies of the data.
Put the eyeball networks out of ratio in the other direction,
then charge them using their same logic. Also, congest all
their end user uplinks, which are slower of course, as that is
congestion in their own network they will have to spend money
to fix.