[RTW] Realtime communication over HTTP (Re: Baseline in or out of scope)

[Justin Uberti]

On Sat, Feb 26, 2011 at 6:51 PM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com>wrote:

> On Sun, Feb 27, 2011 at 10:37 AM, Harald Alvestrand
> <harald at alvestrand.no> wrote:
> > (Changing subject again, since this has strayed from the baseline thread)
> >
> > On 02/26/11 19:47, Bernard Aboba wrote:
> >>
> >> Silvia Pfeiffer said:
> >>
> >> "I doubt both of these statements about HTTP are true any longer."
> >>
> >> [BA] In fact, they haven't been true for quite a while.
> >>
> >> Every day users participate in interactive sessions over
> >> HTTP, largely in circumstances where use of UDP media is
> >> not possible.  Because of the prevalence of highly restrictive
> >> enterprise firewalls that do not permit passing of UDP,
> >> the ability to support realtime communications
> >> over HTTP is now considered a practical requirement for
> >> business-oriented services, such as web conferencing.
> >>
> >> Although realtime communications over HTTP is largely used
> >> as a fallback, measurements show surprisingly high
> >> audio quality in the majority of sessions, probably because
> >> many sessions take place over well-provisioned enterprise
> >> networks.
> >>
> > The Google Talk numbers I've seen published elsewhere are that ~5-10% of
> > sessions run over TCP, relayed through a server, because UDP doesn't get
> > there.
> >
> > The reasons to prefer point-to-point UDP if possible include:
> > - Much lower delay when the endpoints are close to each other,
> network-wise
> > - Much cheaper provisioning for the service provider
> >
> > The lower delay is the factor with the largest impact on comfort of
> > conversation, I think; as long as we don't encounter congestion, the
> audio
> > quality shouldn't be that much different.
> >
> > When we encounter congestion, audio-over-TCP will experience this as
> jitter,
>
> Most of the implementations I have seen will simply go into buffering
> mode when they run out of data and then delay the display of that data
> until they are pretty sure they can play continuously for a bit. With
> HTTP adaptive streaming, the server would be notified of the problem
> and start pushing lower bandwidth packets that are then less likely to
> cause buffering mode again.
>
> The buffering approach is certainly more easily usable in
> broadcast-type applications rather than meeting-type applications
> where all participants need to receive the audio (and video) in
> real-time to be able to reasonably partake. This can, however, also be
> achieved with HTTP adaptive streaming if the byte range requests are
> small enough and can be cancelled to be replaced by a request to the
> next required time.
>
> This link has a paper with an interesting read in this space and
> analysing some of the problems with HTTP adaptive streaming:
>
> http://blog.streamingmedia.com/the_business_of_online_vi/2011/02/new-data-released-on-the-performance-of-adaptive-streaming-over-http.html
>
> I'm aware that HTTP (or TCP) is not typically the best protocol to do
> RTC. What I am trying to say though is that we should not completely
> discout TCP (and therefore HTTP).
>
> > while audio-over-UDP will experience this as packet loss, so the
> experience
> > may be different.
> >
> > There are many tricks available for lessening the impact of both.
>
> I agree and I'd hate us to exclude TCP (and therefore HTTP) from our
> discussions.
>

Agree. It's important to provide the best possible performance, but more
important to ensure that things work at all.

So I think that means we'll prefer to run over UDP, possibly provide a
fallback to TCP/HTTPS, and ultimately fallback to WebSockets. I say
possibly, for TCP, since I'm not yet sure whether it would provide a
significantly better outcome than using WebSockets.

>
>
> Cheers,
> Silvia.
> _______________________________________________
> RTC-Web mailing list
> RTC-Web at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtc-web
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110301/70a4ce4c/attachment.html>