Interesting question

[Juli Mallett]

Hi Roy,

Thanks for the good report to the list!

On Sun, Jan 27, 2013 at 4:43 AM, Roy Warner <thisroywarner at gmail.com> wrote:
> Hi Juli (and all)
>
> We were testing the WANProxy in our office (EU and US branches)
> It's working great.
> One thing that we notices (and were very happy with) was the following:
> We have new employee instruction videos on 2 formats:
> 1 - Plain flash/html4 video (mp4) what is known as http progressive download
> 2 - Windows Smooth Streaming (also - on top of HTTP and HTTPS)
>
> What we have noticed was that in both methods, user who use WANProxy (users
> from EU - contents and servers are in USA) get a MUCH better quality, and
> NEVER require buffering.
>
> These were very good news for us, of course, but since I'm not too technical
> in the in-and-out of the WANProxy, I was wondering how does this work? I
> mean - after all - mp4 cannot be compressed any more...

You may be benefiting from the greater buffering done at the WANProxy
side.  This may not always be a good thing due to how TCP works, and
buffer limiting is a long-term feature we need to support, but
sometimes it's helpful.  So, imagine you're streaming a 400MB mp4.
With a normal TCP stack and application, depending on tuning
parameters, the server might be willing to send something like 64KB at
a time to the remote side.  With WANProxy, the server will be talking
to a local proxy that will buffer as much as possible, maybe even all
400MB.  And that server will send larger amounts of data at a time,
and possibly reduce the number of round-trips required to transfer the
data, reducing latency, etc.

That said, if your content is not dynamic, i.e. these are just static
training videos, then you're likely benefiting from deduplication as
well.  Maybe the mp4 cannot be compressed any more, but if it's the
same every time it's downloaded, then the full content only needs to
go across the Atlantic once.  Subsequent times, the US side will just
send references to the previously-sent data across the Atlantic, and
it will be reconstituted on the other side.  So instead of needing to
transfer 400MB across the ocean to send the whole video, you only need
to transfer something like 2MB.  Combined with the greater buffering
this can really reduce latency, too, as the data can be fed to the
client much faster than it needs it from the local WANProxy instance,
rather than the stream falling behind and requiring more buffering.

Even compressed data can be deduplicated if it's compressed the same
every time.  Consider something like deflate.  If I store a file that
has been compressed with deflate, then it is as compressed as it can
get.  But if I copy it across the WAN twice, the exact same data has
to go across each time.  Now, if instead I am doing deflate on the
fly, the boundaries of the data may be different each transfer,
resulting in completely-different output, so it may not be possible to
deduplicate it.  Even in that case, though, extra buffering may be
useful, but know that it may also be problematic.

Glad to hear it's working for you, and hope those explanations are
helpful.  Let me know if not!

Thanks,
Juli.

> If anyone could share his thoughts, that would be great.
>
> Thanks,
> Roy
>
> _______________________________________________
> wanproxy mailing list
> wanproxy at lists.wanproxy.org
> http://lists.wanproxy.org/listinfo.cgi/wanproxy-wanproxy.org
>