Re: [AVT] Comments on draft-boyaci-avt-app-sharing-00

[Randell Jesup <rjesup at wgate.com>]

Colin Perkins <csp at csperkins.org> writes:
>On 14 Nov 2008, at 19:52, Cullen Jennings wrote:
>> I like the idea of an applications share protocol that can be set  up
>> over SIP and glad to see this submission.
>>
>> Few comments
>>
>> At a high level, why not just standardize something like VNC. It  seems
>> like this would be better than inventing something new.
>>
>> I also wondered about why run it over RTP vs just be it's own
>> protocol. It was not clear that RTP was a good match.
>
>This was the main issue raised back at IETF 62 when this was last
>discussed. The minutes from the AVT meeting back then state:
>
>    draft-lennox-avt-app-sharing-00.txt
>    draft-schulzrinne-mmusic-sharing-00.txt
...
>    After a number of questions for clarification, there was  considerable
>    discussion of the "big picture" open issues. Carsten Bormann  wondered
>    if this is now the right time to solve the problem, and if AVT is  the
>    right home for the work? Carsten was unconvinced by the arguments  for
>    using RTP: there are definitely some requirements for real-time  data,
>    but general remote access is not always perceived as a real-time
>    application (indeed, the protocol uses RTP over TCP). The landscape
>    of requirments varies: some applications have latency and timing
>    constraints, particularly for input; others do not. It is not clear
>    that the appropriate trade-off has been made, or that we have a good
>    handle on the problem space. Carsten also noted that different types
>    of operating system have become more similar over time, so the  problem
>    might be easier than when previous solutions were last developed,  and
>    that now might be a good time to attempt a new solution.

App-sharing can make sense to setup with SIP.  The data streams are or can
be a mixed bag - the primary ones are not or should not have much in common
with what we do in AVT (i.e. RTP and the like).  Some of the data streams
do map over (video and audio); hopefully those can make use of existing
payload formats.  Some might map over in that there's timing info, though
other transport protocols probably make more sense (mouse, keyboard, etc).

So my question for this is what form would the audio and video channels
take (when active).  For the main UI imagery, I would use some other
transport than RTP/AVP in the SDP media lines.  It doesn't *have* to be
TCP-based - UDP has some advantages in high loss/long-delay/etc situations,
so long as each packet (or at least small group of packets) are
self-contained *and* you have a robust recovery mechanism.  But normally
TCP would be prefered, and is certainly a lot simpler to implement.  The
protocol should include NTP timestamping so the UI (and input streams like
mouse and keyboard) can be synchronized with each other and audio/video
streams.

>    Keith Lantz expressed similar concerns: this is clearly an important
>    problem to solve, but he is not sure this is the right  architecture and
>    AVT may not be the right home. Perhaps we need to better  understand the
>    architecture to know if this is the appropriate solution?
>
>    Some interest was also expressed in scaling one small screen  devices,
>    although it is unclear how that use case fits into this model.

That seems to be a application/client UI issue.

>That previous work wasn't adopted in AVT, due to those concerns, and  I
>don't see anything in the current draft that addresses them either.

Pretty much I agree.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt