[RTW] Baseline in or out of scope (Re: WG charter, take 4)

[Silvia Pfeiffer]

On Sat, Feb 26, 2011 at 8:02 PM, Harald Alvestrand <harald at alvestrand.no> wrote:
> Changing subjects to reflect main point, as usual....
>
> On 02/26/11 04:16, Silvia Pfeiffer wrote:
>>
>> I agree with basically all of these things. More concrete comments below.
>>
>>
>> On Sat, Feb 26, 2011 at 2:01 AM, Magnus Westerlund
>> <magnus.westerlund at ericsson.com>  wrote:
>>>
>>> Hi,
>>>
>>> Sorry for not having produced these charter comments earlier as most
>>> would apply to earlier versions also. However, I do have a number of
>>> comments on it and think the charter could be restructured to become a
>>> much better charter. But lets start with the different comments.
>>>
>>> The most fundamental issue with the charter is that it contains to much
>>> technical solution candidates, rather than talking about the goals and
>>> and general direction for achieving them. I think one needs to extract
>>> the few higher level goals from this list and work them into the charter
>>> in other ways. Certain things we likely can select, like RTP. But there
>>> is clearly a question on what profile and extensions that should be
>>> supported.
>>>
>>> I also think one of the biggest uncertainties and fuzziness in the
>>> charter is because the model isn't agreed on. The discussion about the
>>> session management is clear due to that the model for the work aren't
>>> agreed on. I see two ways here. Either we manage to lock down the model
>>> prior to the chartering, or we have a charter that included this model
>>> discussion. Frankly I see the later as most likely as agreement on the
>>> model will require agreement with IETF's partner in this work. Thus the
>>> charter should take a bit more height for having such model discussion.
>>>
>>> It is already obvious that any codec selection for this is going to be a
>>> difficult and possibly take time. To avoid this from de-railing the
>>> truly fundamental parts of the RTC-WEB solution, I am suggesting that
>>> this should be taken in its own WG, or if not possible at least as a
>>> separate WG item, with its own deadlines, so that it doesn't hold up
>>> the main work. That is likely anyway a good idea for long term purpose,
>>> so that only the codec selection part can be updated, and not the
>>> fundamental part when the set of codecs become out-dated.
>>
>> I had already lost interest in this group because I thought it would
>> just end up in endless baseline codec discussions. I agree with
>> removing the baseline codec from the charter, if only to enable the
>> group to move forward at all.
>>
>> I am not sure I agree though with creating a separate WG for it.
>>
>> Instead I think it would make much more sense to accept that we will
>> always have a heterogeneous codec world and create a simple codec
>> negotiation protocol.
>
> I think we have consensus that we will have codec negotiation in any
> realistic scenario (whether the actual negotiation protocol is in scope or
> out of scope is a current matter of debate).
>
> I think we need a baseline codec set, for all the normal reasons. I think
> that among us, we have experience enough in managing working group
> discussions that it's possible to discuss things one subject at a time.
>
> Developing yet another protocol suite that requires external profiling in
> order to achieve interoperability is something I find deeply distasteful.


With a codec negotiation protocol, you don't need a profile to clients
interoperable: either the clients support a common codec or they
don't. In latter case no communication is possible.

I agree that the goal of a common baseline codec across all
applications is an ideal to aspire to. However, experience from HTML5
shows that unless all vendors are on the same page, you can end up in
endless discussions about this topic without any real effect. The
choice of codec seems to be more of a business issue than a technical
interoperability issue.


>>> I still don't understand the diffserv based QoS. This seems very
>>> unrealistic to be usable from a web-browser perspective. This as no
>>> device in any setting other than being an ISP controlled device is
>>> likely to be allowed to set DSCP. I think QoS can be excluded at this
>>> stage completely. Especially as there are a lack of methods for
>>> providing end-point devices with a traffic class to DSCP mapping valid
>>> in the currently attached network.
>>>
>>> The charter could also be clearer on the need for basic datagram and
>>> byte stream functionality between two peers. The higher motivation for
>>> it is there, but not requirements. Where I see rate control and
>>> security of those channels being the most important ones.
>>>
>>> I am also missing a clear requirement for enabling future extensions of
>>> functionality of the RTC-WEB components in the browser.
>>
>> That was another key issue I also have with the charter - I was under
>> the impression the group is there to solve the RTC communication on
>> the Web (!), i.e. in Web browsers using HTML5 and HTTP. The charter
>> is, however, so much wider and I am starting to wonder if we are
>> trying to create an unwieldy solution to an unclear problem.
>
> I am sorry that you have misunderstood. The effort was started in order to
> enable real-time browser-to-browser communication, which HTTP is
> fundamentally unsuitable for; HTTP-server-mediated communication is (to a
> large degree) possible to achieve without standardization.

I doubt both of these statements about HTTP are true any longer.
During the time of creation or RTP/RTSP, I would have agreed. However,
with HTTP streaming through byte ranges and with Web sockets that keep
connections open, I wonder if these claims about HTTP are so true any
more. I can understand that you want to allow the use of RTP/RTSP as
well, seeing as that's been the traditional way of doing live
streaming. However, I would want us to keep an open mind about the
actual protocols and technologies being used. The Web runs after all
over HTTP and if HTTP turns out to be usable for this use case - even
if there may be some disadvantages to it - I would not want to exclude
it. My main interest in this activity is to see RTC work with HTML5.

Cheers,
Silvia.