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

[Silvia Pfeiffer]

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.


Cheers,
Silvia.