Subject: [rtcweb] Non-media data service consensus and requirements

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Jun 2011 09:36:30 +0200

WG,

At the interim it was planned to have a bit discussion on the datagram
service for RTCWEB. The first question to try to resolve if there
is consensus for including some form of non real-time media (i.e. not
audio, video) service between peers. This is a bit tangled with the
actual requirements and use cases. But there was views both for it and
against it on the mailing list. So lets continue and try to come to a
conclusion on this discussion.

The use cases mentioned on the mailing list are:

- Dynamic meta data for Conference and other real-time services

- Gaming data with low latency requirements

Does anyone like to add additional use cases?

Based on my personal understanding this points to primarily have the
RTCWEB provide a unreliable datagram service. This clearly needs
additional requirements to be secure and safe to deploy, but more about
this below. I still like to ask the WG here a question.

Are you supporting the inclusion of a unreliable datagram service
directly between peers? Please provide your view and any additional
statements of motivation that you desire to provide.

Secondly, there is a question if there needs to have something that
provides reliable message (of arbitrary size) or byte stream oriented
data transport between the peers. I personally foresee that people will
build JS libraries for this on top of a unreliable datagram service. If
you desire reliable data service as part of the standardized solution
please provide motivation and use case and requirements.

I also want to take a stab on what I personally see as the requirements
that exist on unreliable datagram service in the context of RTCWEB.

- Unreliable data transmission
- Datagram oriented
   * Size limited by MTU
     - Path MTU discovery needed
   * Fragmentation by the application
- Low latency, i.e. Peer to Peer preferable
- Congestion Controlled, to be
   * Network friendly
   * Not become a Denial of Service tool
- Security
  * Confidentiality
  * Integrity Protected
  * Source Authenticated (at least bound to the signalling peer)
  * Ensure consent to receive data

Please debate the above. This is an attempt to ensure that we can
establish WG consensus on both data service and any requirements.

cheers

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: Emil Ivov <[email-masked]>
Date: Mon, 27 Jun 2011 14:34:16 +0200

> Does anyone like to add additional use cases?

- File transfer? Skype, Google Talk, Windows Live, and pretty much any
existing service has it so I suppose it is reasonable to assume that
people using rtcweb would like to add the feature to their web applications.

- Transferring input events (e.g. pressed keys and mouse clicks) in
desktop sharing applicaitons?

> statements of motivation that you desire to provide.

Yes. Requirements and code necessary to support a generic datagram
service would hardly differ from those we have for RTP and it would
definitely help a lot in the use cases described above.

> please provide motivation and use case and requirements.

I definitely think it would be a great idea for the IETF to specify a
datagram based reliable service similar to Google's pseudo TCP. Whether
or not this happens in RTCWEB is of course a different matter. As I
wrote above many applications are likely to need such a think and I am
not sure that the flexibility we'll get by leaving this to JS libs is
worth the interoperability nightmare it would imply.

Emil

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[email-masked]                        PHONE: +33.1.77.62.43.30
http://jitsi.org                       FAX:   +33.1.77.62.47.31

---

From: Manuel Simoni <[email-masked]>
Date: Tue, 28 Jun 2011 16:18:45 +0200

> Does anyone like to add additional use cases?

Hello,

I don't understand the networking details, but I am sure that people
will want to transfer files between peers, and if only an unreliable
service is provided, people *will* implement it on top of the
unreliable service. Badly, probably.

Manuel Simoni

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 28 Jun 2011 16:33:05 +0200

> please provide motivation and use case and requirements.

When it comes to reliable data I interpret you being a supporter for it.
However, can you elaborate on any usages you see for reliable object in
web-applications to try to see if there are any requirements we are
missing.

Cheers

Magnus Westerlund

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 Jun 2011 15:45:52 -0400

Here are some thoughts on additional use cases:

* information on congestion and receiver side environment for purposes 
of improved sender rate adaptation

* active speaker indications

* real-time text (along the lines of 
http://datatracker.ietf.org/doc/rfc5194/)

* video controls - application driven intra-frame requests, for example

* floor control requests/grants

All of these share the common property of being latency sensitive, and 
thus more appropraite for p2p vs. server mediated. The other driver for 
p2p data transport is cost reduction, to avoid the need for server 
mediation for transfer of data. File transfer is the main example of this.

I view the latency-sensitive use cases as a higher priority for us and a 
better match to the work we're doing here.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   SkypeID: jdrosen
Skype Chief Technology Strategist
[email-masked]                              http://www.skype.com
[email-masked]                            http://www.jdrosen.net

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 28 Jun 2011 13:48:26 -0700

Please consider something like "augmented waypoints" for evacuation 
systems (might help resolve stampedes).

On 06/28/2011 12:45 PM, Jonathan Rosenberg wrote:
> thus more appropraite for p2p vs. server mediated. The other driver 
> for p2p data transport is cost reduction, to avoid the need for server 
> I view the latency-sensitive use cases as a higher priority for us and 
> a better match to the work we're doing here.
>
> Thanks,
> Jonathan R.
>
>> F�r�gatan 6                | Mobile +46 73 0949079

-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant

---

From: Randell Jesup <[email-masked]>
Date: Wed, 29 Jun 2011 00:12:19 -0400

> of improved sender rate adaptation

Aka active bandwidth adaptation.  This will generally be better over 
RTCP or other unreliable-but-low-latency channel.

One thing we may want to address is handling congestion across a set of 
streams, instead of only a single stream.  Current mechanisms are 
stream-oriented, which both can cause unexpected conflicts between 
related streams (audio and video for example), and also allows 
"cheating" congestion rules by opening multiple 'connections' (streams).

This was one thing that RTMFP got right, along with allowing reliable 
datagram services.  As mentioned, if it's not provided then N*M people 
will try to implement reliable transport over whatever streams we give 
them (including random RTP streams), and as someone said, they'll make 
mistakes.

> * video controls - application driven intra-frame requests, for example

I suspect these should be dealt with using normal rtcpfb mechanisms, 
there there may be needs for a reliable transport of this request.

> * floor control requests/grants

And as was mentioned user input events in a VNC/RDP-type remote 
browser-sharing.  (and yes, there are security issues here!)  These are 
both latency-sensitive and must be reliable (or at least a subset of 
events must be reliable, and probably all do).

> a better match to the work we're doing here.

To be clear: I'm in favor of considering non-media unreliable and 
reliable transports.

-- 
Randell Jesup
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 29 Jun 2011 09:39:25 +0200

Hi,

As an individual.

> of improved sender rate adaptation

I believe it is important that we have congestion control for the point
to point flows for both RTP and non-media data that are implemented and
enforced in the browser. This is a pure security and personal hygien
question. A rouge application should not be able to consume completely
unproportional bit-rates between two peers and be able to starve out
applications sharing the bottleneck.

Having said that there can clearly be need for application level signals
for changing behavior and adopting to what bit-rate or delay
characteristics that are available. Especially if you have star or other
multi-hop topologies in the application interconnections. For RTP we
already propose some such signals like TMMBR [RFC5104] in our RTP for
RTCWEB document.

Cheers

Magnus Westerlund

---

From: Manuel Simoni <[email-masked]>
Date: Wed, 29 Jun 2011 14:52:37 +0200

> When it comes to reliable data I interpret you being a supporter for it.

Yes.

> web-applications to try to see if there are any requirements we are

A use case would be an audio/video chat program, with the ability to
transfer files/documents between peers without needing server-side
storage.

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 29 Jun 2011 07:27:36 -0700

> applications sharing the bottleneck.

I would suggest instead of "for purposes of improved sender rate 
adaption" to "for purposes of manifold adaption", yet that may confuse 
people that relate usage outside such interface topology.

> already propose some such signals like TMMBR [RFC5104] in our RTP for

I couldn't find the link off-hand, yet there exists successful non-stop 
busy intersection simulations. The downfall with those simulations 
happens when they assume every vehicle is signal aware. Such simulations 
do not include trains or multi-trailers. This relates, however, in 
multi-hop when viewed from intersection to intersection. One may want to 
demand multi-hop to relieve traffic congestion, which may involve 
disconnection from star-topologies. What star-topologies want is how to 
keep-alive the physical tether (simulated or not) through such temporal 
disconnection. Each star-topology has one centralized physical tether no 
matter how they divide the coverage (cellular). Besides credit systems 
for that temporary digital-divide (gap), the best use-case I have seen 
for such physical tether is games that require centralized physic 
simulation to avoid cheaters (or train wrecks). The law of conservation 
is the alternative for less-than-best credit conversion (since the size 
of each bit is unknown to the observer) while disconnected. ;)

--

---

From: Christopher Blizzard <[email-masked]>
Date: Wed, 29 Jun 2011 22:48:34 -0700

> Does anyone like to add additional use cases?

For web browsers we'd (Mozilla) like to see it as a more generic 
transport service for applications.  As part of our web-as-applications 
work we'd like to break some of the assumptions about how applications 
are built.  In particular, having standalone apps that are downloaded 
and installed, but built on web technologies where clients can connect 
with each other is something that's interesting.  (HTTP and WebSockets 
both require connecting via a server intermediary.)  If we had a peer to 
peer connection service, with or without video services, we would be 
able to connect applications together without servers involved, aside 
from initial set-up.  Bringing back the end to end principle actually 
matters for our apps strategy.

And yes, this is different than what other people are doing.  But it's 
one of the reasons why I've been insistent on data transmission as part 
of the peer to peer APIs and protocols.

So if I put my use case down it would be:

- Baselevel communications protocol for application to application 
communication in browsers.

And yes, that's vague.  I could use better words there.

> please provide motivation and use case and requirements.

I think that for the app to app case I have to imagine that the most 
common use case will be reliable transport with both messages and 
entities being sent back and forth.

But the file transfer use case, as well as trying to provide some level 
of congestion control around audio & video sessions would seem to 
indicate that we might want to have both, tbh.

But I haven't thought deeply on this particular aspect of the 
discussion.  So I'm easily swayed.

--Chris