Re: A simple proposal

[deleskie () gmail com]

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)