A simple proposal

Jimmy Hess mysidia at gmail.com
Sat May 17 03:05:39 UTC 2014

On Fri, May 16, 2014 at 12:26 AM, Matthew Petach <mpetach at 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.


More information about the NANOG mailing list