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

[Harald Alvestrand]

On 02/27/11 03:51, Silvia Pfeiffer 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.
I think we all agree that media-over-TCP is necessary as a fallback, and 
that therefore, we have to include it in our charter.

Now to craft language ... in conversations with Magnus this week, Magnus 
made some suggestions in this area.

                   Harald