Subject: Re: [rtcweb] Contributions for the Interim meeting

From: Dzonatas Sol <[email-masked]>
Date: Wed, 04 May 2011 18:22:23 -0700

Hi,

I've read the acceptance e-mail: 
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg08829.html

"RTP functionalities, media formats, security algorithms are example of
things that commonly need extensions, additions or replacement, and
thus some support for negotiation between clients is required."

At a glance, I thought this sounded like "Real-Time Compositing" from 
the frame and media complexes of IETF VWRAP WG. I'm not immediately 
aware of any web-browser that features hardware-compositors, which would 
help avoid some endless transistions. Hypervisors did come to mind, however.

I'm the scientist, so I can help the doctors on this WG.

Also, this was hinted to me: http://100yearstarshipstudy.com/

.NET version of original UNIX under Hypervisor mode with X Windows seems 
like the bootstrap station for this WG. YMMV...

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 5 May 2011 11:22:16 +0200

> help avoid some endless transistions. Hypervisors did come to mind, however.

To my understanding and I would say intention as I was part of writing
that text line is that it concerns the need for having signalling,
capability and negotiation mechanism for having the peers to agree on
what is to be used.

For example a peer may implement multiple video codecs. They need to
negotiation at least to which is the common set between the peers.

In security one may have several encryption algorithms and key lengths
in a protocol. Even if one selects only one today this is a case where
we know that tomorrow some vulnerability may be discovered and thus
requiring everyone to promptly deploy a new one.

When it comes to VWRAP I think there are some potential overlapp in
underlying technology. Not following VWRAP I don't know if they are
creating something new or are considering RTP for position information
in a virtual world which definitely is a real-time media.

If you believe there is overlap with VWRAP can you please be a bit more
verbose on what that overlap consists of.

I do fail to understand the meaning of the rest of your comments.

Best Regards

Magnus Westerlund

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Dzonatas Sol <[email-masked]>
Date: Thu, 05 May 2011 06:17:19 -0700

Thanks for the reply,

> capability and negotiation mechanism for having the peers to agree on

Yes, given an example of an multiple applications that each support 
RESTful queues and HTTP servers on the same home network, there is 
commercial concern if these too easily breached because the home 
firewall may not be trusted as the commercial firewall. That is subject 
to opinion, yet it is an area that we haven't seen such end to 
negotiation. Thus, more extensions interfere with interoperability, 
especially if the commercial server will ensure assets in the hands of 
the home user.

> in a virtual world which definitely is a real-time media.

VWRAP has gone through few make-overs, already, in concerns of 
architectural WGs. Linden Labs has been key with the VW Second Life, and 
whose original founder worked previously with Real. The Second Life 
application is open source and features media plug-ins (for 
web-media/web-browser on 3D polygons/primitives). The movement away from 
monolithic designs, of both SL and web-browser, has been slow, yet 
effort doesn't stop.

This involves several layers at various scales.

> I do fail to understand the meaning of the rest of your comments.

No problem, as I mainly stated, expectantly, that if we relate to the 
depth at scale given the language used already. Original UNIX is known 
for real-time applications do to its time-slice capabilities. Many have 
emulated UNIX for compatibility, yet they don't guarantee such real-time 
scale or such quantums. We could relate X Windows as "a 3D browser" and 
so further web-browsers on the web make this appears as a browser in a 
browser, and so on.

I think the original UNIX had the right idea to help avoid turtle on 
turtles, yet the hardware-means didn't exist in earlier processors on 
the market. Now they do, and today people use emulated modes within 
emulated modes.

Not that they are wrong in their direction, yet computation power is of 
concern with that trend.

Power effects timing.

--

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 06 May 2011 07:34:57 -0700

Please review the use-case I just posted: 
http://www.ietf.org/mail-archive/web/rtcweb/current/msg00057.html

I'm not sure if you say that as you seen this. If that is not clear 
enough, I can answer more questions off-list.

With that use-case, however, assume there is no specific perspective, 
like page mode or such, so I want to avoid explanation of that 
complexity. With the ReSTful paradigm, we can shift matters that fall 
out of scope into other capabilities.

Thanks.

On 05/06/2011 07:23 AM, Magnus Westerlund wrote:
> Sorry,
>
> I can't make head and tails of your comments. They contain words that
> could be relevant but I can't determine what your actual argument or
> position is from it.
>
> Can you please be more specific and clear on what your point of argument
> is. What is the intention of your comments?
>
> best regards
>
> Magnus
>
>
> On 2011-05-05 15:17, Dzonatas Sol wrote:
>    
>> Thanks for the reply,
>>

--

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 6 May 2011 16:23:59 +0200

Sorry,

best regards

Magnus

-- 

Magnus Westerlund

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 06 May 2011 08:19:24 -0700

I smiled at this one: 
http://tech.slashdot.org/story/11/05/06/122233/A-25-PC-On-a-USB-Stick

Consider the HDMI as optional where-if the media uses USB as transport.

--

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 6 May 2011 17:28:46 +0200

> http://www.ietf.org/mail-archive/web/rtcweb/current/msg00057.html

Yes I saw it. But I still don't understand what you are after. I can't
determine if it is proxying or some write through data manipulation you
want to attempt.

Can you describe this in separate data objects or data stream, nodes
that are involved in communication and existing or desired network
protocol that perform the communication.

> out of scope into other capabilities.

When I brought up perspective, I asked about your motivation and what
capabilities that you see a need that still are within the WG's charter.

Cheers

Magnus Westerlund

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 06 May 2011 10:08:58 -0700

> determine if it is proxying or some write through data manipulation you

What we, in particular, want to do is avoid the current trend that puts 
people into more complicated support over what is suppose to be 
simplified communication through heterogeneous systems. At a glance, 
this WG sounded like "Real-Time Compositing".

> protocol that perform the communication.

Yes. Let's consider that each frame needs composite information for each 
region over each succession of the frame. An example is the Hypervisor 
(as host) that gathers region data sent from guests for frame 
composition. The forward flow is more obvious then the reverse flow, 
where the host only needs to send essentially the same data to each region.

With the Raspberry Pi prototype ( http://www.raspberrypi.org/ ), imagine 
any unit like that where the host is the one with the HDMI connection 
and the guests connect to the USB hub. The guest units would not need 
the HDMI hardware due to virtualization of the host or media thereof on 
the wire. Any new unit plugged into the hub can filter-in the 
"essentially same data" already being sent by the host. Even though the 
"essentially same data" exists, it surely isn't the same outside this scope.

We can apply the same concept to shared-memory, multicasting, 
write-through, etc, at different frame scales, components, 
hardware/software, yet, as noted, we tried to avoid that implementation 
detail.

We can already imagine those with invested interest in star-topologies 
would avoid anything like mesh-networks (and multicasting in general). 
Within the frame (and still technically within scope) and specific to 
each composition, we still need this much more so people are not left in 
continual argument how to negotiate their communication (and whatever 
desire at poly-scale).

--

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 06 May 2011 10:57:55 -0700

We try to filter-in mime-types and capabilities, yet we know now to 
filter-out any leftover flow of RTP in regards to the RTCWEB 
constraints, yet for support, do nothing. Thanks.

On 05/06/2011 10:38 AM, Ted Hardie wrote:
> Hi Dzonatas,
>
> Having read through this thread and visited the prototype site you 
> mentioned, I conclude that the perceived overlap is because each 
> community uses similar vocabulary. �That's an important insight for us 
> as we strive to make our work understood, thanks. �The practical 
> overlap between the efforts seems to be very small, however, at least 
> at this time. �Given the tight time constraints on producing the 
> currently chartered work, we will not be considering expanding the 
> scope at this point.
>
> Thanks and regards,
>
> Ted �
>
> On Fri, May 6, 2011 at 10:08 AM, Dzonatas Sol <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>         �
>             � �
>         �
>     What we, in particular, want to do is avoid the current trend that
>     puts people into more complicated support over what is suppose to
>     be simplified communication through heterogeneous systems. At a
>     glance, this WG sounded like "Real-Time Compositing".
>
>
>
>         �
>     Yes. Let's consider that each frame needs composite information
>     for each region over each succession of the frame. An example is
>     the Hypervisor (as host) that gathers region data sent from guests
>     for frame composition. The forward flow is more obvious then the
>     reverse flow, where the host only needs to send essentially the
>     same data to each region.
>
>     With the Raspberry Pi prototype ( http://www.raspberrypi.org/ ),
>     imagine any unit like that where the host is the one with the HDMI
>     connection and the guests connect to the USB hub. The guest units
>     would not need the HDMI hardware due to virtualization of the host
>     or media thereof on the wire. Any new unit plugged into the hub
>     can filter-in the "essentially same data" already being sent by
>     the host. Even though the "essentially same data" exists, it
>     surely isn't the same outside this scope.
>
>     hardware/software, yet, as noted, we tried to avoid that
>     implementation detail.
>
>     We can already imagine those with invested interest in
>     star-topologies would avoid anything like mesh-networks (and
>     multicasting in general). Within the frame (and still technically
>     within scope) and specific to each composition, we still need this
>     much more so people are not left in continual argument how to
>     negotiate their communication (and whatever desire at poly-scale).
>
>
>     -- 
>     _______________________________________________
>     rtcweb mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--