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 <philfa...@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...@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 > > <mpet...@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)