Subject: [rtcweb] Question about usage of data traffic

From: Michael Welzl <[email-masked]>
Date: Tue, 12 Jun 2012 11:06:36 +0200

Hi,

Sorry if I'm asking a dummy question... I'm still somewhat new to 
rtcweb, and certainly quite new to this list:

It seems that the group's idea of data traffic is that this would be 
latency-critical traffic, possibly combined with other real-time 
communication. Slide 2 of the slideset at 
http://trac.tools.ietf.org/wg/rtcweb/trac/attachment/wiki/WikiStart/Non-Media%20Data%20in%20RTCWEB.ppt
says:

Use cases:
-Dynamic meta data for Conference and other real-time services
-Gaming data with low latency requirements
-Others?

This makes me wonder: once we have rtcweb in place, what stops a web 
site developer from just providing a web-based file transfer service 
between browsers? And: if that's a possibility, would we even want to 
prevent that? (I'd say no)

Similarly, I can pull files on my Skype to send e.g. photographs to a 
person I'm chatting with. I'd imagine that this sort of thing would also 
be attractive for rtcweb based applications, and I don't see a reason to 
prevent this.

What's different here is that we're in these cases dealing with greedy, 
non-latency-critical traffic, and possibly lots of it. Could this even 
be a new use case?

Cheers,
Michael

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 12 Jun 2012 02:11:09 -0700

> non-latency-critical traffic, and possibly lots of it. Could this even

There is currently a "Simple Video Communication Service with file 
exchange" use case (see Section 4.2.8 in
http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-08). 
Are there additional derived requirements that are needed to support 
this use case?

---

From: Randell Jesup <[email-masked]>
Date: Tue, 12 Jun 2012 05:20:47 -0400

> be attractive for rtcweb based applications, and I don't see a reason to

Correct, support for this is a design goal.

> non-latency-critical traffic, and possibly lots of it. Could this even

This is the reason for the priority fields for the DataChannel objects, 
to allow the application to set the relative priorities of media 
channels and data.  By default, we don't want data channels to starve 
media, but to take a share, so are reasonable for "look at this picture" 
cases.  Large i-don'tcare-when transfers should be given somewhat lower 
priorities, real (low-bandwidth) realtime data should be given higher.

-- 
Randell Jesup
[email-masked]

---

From: Michael Welzl <[email-masked]>
Date: Tue, 12 Jun 2012 11:38:37 +0200

> Are there additional derived requirements that are needed to support 
First: very sorry for missing this one! I looked at this very draft 
again just yesterday, but somehow didn't notice the file transfer bit.
On a side note, when looking through the requirements derived from this 
use case now, I got the impression that it would have been more 
reader-friendly to write:
"In addition to the Simple Video Communication Service use-case, this 
use-case has the following requirements:"  and list just the new ones.

Second: I don't think that there are additional requirements derived 
from that, but it can have architectural implications. (i.e. what is 
derived is, perhaps, a new property).  =>  "file transfer" should then 
be a part of the use cases on the list in the slide set I mentioned.  
(I'm saying that because the slide asks: "others?")

Given that file transfers are "part of the plan", I just think it's 
important for all of us to understand that there may be a lot of data 
traffic too (instead of pictures, people may be sending a movie... or 
you could even have a website offering *nothing but* a file transfer 
service?! I have a feeling that this could even turn into an unintended 
"killer app" for rtcweb  :-)   ).

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Tue, 12 Jun 2012 11:39:25 +0200

On 6/12/12 11:20 AM, Randell Jesup wrote:
> This is the reason for the priority fields for the DataChannel 
> objects, to allow the application to set the relative priorities of 
> media channels and data.  By default, we don't want data channels to 
> starve media, but to take a share, so are reasonable for "look at this 
> picture" cases.  Large i-don'tcare-when transfers should be given 
> somewhat lower priorities, real (low-bandwidth) realtime data should 
> be given higher.
>
I see; thanks. Sounds good to me.

Cheers,
Michael

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 13 Jun 2012 10:16:38 +0200

The reason for the initial data use cases was that we wanted to focus on 
the stuff that *couldn't* be done by bouncing data off a server; 
non-time-sensitive bulk file transfer can certainly be done via a 
server, even though that may not be optimal.

That said, we've always expected that once the data transfer capability 
is in place, we'll have plenty of people wanting to use it in 
"unexpected" ways.
The important RTCWEB-specific requirement from the file transfer use 
case is probably that IF file transfer is done in a peer-to-peer 
fashion, within the RTCWEB context, it MUST be able to run without 
degrading the quality of the real time media.

On 06/12/2012 11:38 AM, Michael Welzl wrote:
> On a side note, when looking through the requirements derived from 
> this use case now, I got the impression that it would have been more 
> service?! I have a feeling that this could even turn into an 
> unintended "killer app" for rtcweb  :-)   ).
>
> Cheers,
> Michael
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Jun 2012 06:14:49 -0700

> degrading the quality of the real time media.

[BA] We need to be careful about the definition of "degrade".   If the goal is to support the best video quality 
possible (e.g. highest frame rate/quality/resolution supportable on the path), then starting a file transfer on 
the same path may require the video to reduce bandwidth usage.  This by itself does not seem problematic. 

However, it would be problematic if the file transfer builds a queue that results in unacceptable latency. A
large file transfer over TCP via the server will tend to do this -- but a file transfer handled over the data channel
should not.