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 On Fri, May 16, 2014 at 10:56 AM, Matthew Petach <mpetach@netflight.com>wrote:
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
-- ~~~~~~ Regards Rahul
I agree with Rahul, seems like pointless cycles along the entire path. On Thu, May 15, 2014 at 11:35 PM, Rahul Sawarkar <srahul.in@gmail.com>wrote:
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
On Fri, May 16, 2014 at 10:56 AM, Matthew Petach <mpetach@netflight.com
wrote:
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
-- ~~~~~~ Regards Rahul
-- Phil Fagan Denver, CO 970-480-7618
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" .. On Saturday, May 17, 2014, Phil Fagan <philfagan@gmail.com> wrote:
I agree with Rahul, seems like pointless cycles along the entire path.
On Thu, May 15, 2014 at 11:35 PM, Rahul Sawarkar <srahul.in@gmail.com<javascript:;>
wrote:
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
On Fri, May 16, 2014 at 10:56 AM, Matthew Petach <mpetach@netflight.com<javascript:;>
wrote:
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
-- ~~~~~~ Regards Rahul
-- Phil Fagan Denver, CO 970-480-7618
-- --srs (iPad)
You shouldn't of stopped them I was eagerly waiting to find out how rtt was going to be increased :) -jim Sent from my BlackBerry 10 smartphone on the Rogers network. Original Message From: Suresh Ramasubramanian Sent: Friday, May 16, 2014 11:26 PM To: Phil Fagan Cc: nanog@nanog.org Subject: Re: A simple proposal 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" .. On Saturday, May 17, 2014, Phil Fagan <philfagan@gmail.com> wrote:
I agree with Rahul, seems like pointless cycles along the entire path.
On Thu, May 15, 2014 at 11:35 PM, Rahul Sawarkar <srahul.in@gmail.com<javascript:;>
wrote:
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
On Fri, May 16, 2014 at 10:56 AM, Matthew Petach <mpetach@netflight.com<javascript:;>
wrote:
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
-- ~~~~~~ Regards Rahul
-- Phil Fagan Denver, CO 970-480-7618
-- --srs (iPad)
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. On Sat, May 17, 2014 at 8:11 AM, <deleskie@gmail.com> wrote:
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
----- Original Message -----
From: "Matthew Petach" <mpetach@netflight.com>
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.
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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
On Thu, May 15, 2014 at 10:26:02PM -0700, Matthew Petach wrote:
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.
You can push the stream back to offloaded cloud now: http://devnull-as-a-service.com/ -- Brandon Ewing (nicotine@warningg.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 On 5/16/14, 12:05 PM, "Brandon Ewing" <nicotine@warningg.com> wrote:
On Thu, May 15, 2014 at 10:26:02PM -0700, Matthew Petach wrote:
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.
You can push the stream back to offloaded cloud now: http://devnull-as-a-service.com/
-- Brandon Ewing (nicotine@warningg.com)
On May 16, 2014, at 9:28 AM, "McElearney, Kevin" <Kevin_McElearney@cable.comcast.com> wrote:
will likely have negative consequences all around.
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 Sent from Kangphone
On Fri, May 16, 2014 at 12:26 AM, Matthew Petach <mpetach@netflight.com> wrote:
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.
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. -- 2. Excellent. Especially if the video player receives streams over UDP and doesn't verify the source IP address before sending the stream back, what could possibly go wrong?. 3. On second thought.... why not send the return stream to another subscriber? Stream the thing only to buffer the content to a subset of the users' media players. The users' media players then shape the return stream in order to distribute the content ----- they could even SEND more data back to the content provider than they receive, if this benefits the content provider in peering negotiations. -- -JH
On May 16, 2014, at 12:26 AM, Matthew Petach <mpetach@netflight.com> wrote:
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.
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. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
participants (11)
-
Brandon Ewing -
deleskie＠gmail.com -
George William Herbert -
Jay Ashworth -
Jimmy Hess -
Leo Bicknell -
Matthew Petach -
McElearney, Kevin -
Phil Fagan -
Rahul Sawarkar -
Suresh Ramasubramanian