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

From: Cullen Jennings <[email-masked]>
Date: Wed, 6 Jul 2011 21:57:27 -0600

On Jun 27, 2011, at 1:36 AM, Magnus Westerlund wrote:
> 
> Does anyone like to add additional use cases?

BFCP 

I'm interested in the use cases that have real time requirements and latency is an issue.

> 
> 
> Are you supporting the inclusion of a unreliable datagram service
> directly between peers?
yes

> 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 don't have a big need for this but don't have a problem with it if others need it 

> 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
+1 

> - Datagram oriented
>   * Size limited by MTU
>     - Path MTU discovery needed
+1

>   * Fragmentation by the application
+1

> - Low latency, i.e. Peer to Peer preferable
+5

> - Congestion Controlled, to be
>   * Network friendly
+1
>   * Not become a Denial of Service tool
+1

> - Security
>  * Confidentiality
+1
>  * Integrity Protected
+1
>  * Source Authenticated (at least bound to the signalling peer)
+1 - I might phrase this a bit differently but I think we are getting at the same thing. If we are going to have encryption, there no point in encrypting something if you have no idea you our sending encrypted data to and from. We need some sort of identity / autehntication

>  * Ensure consent to receive data
+5

In addition to your, I'd like to add that I am trying to maximize the odds of it making though the various NATs and Firewalls involved with and enterprise or home user. 

Cullen in my individual contributor role.

---

From: Randell Jesup <[email-masked]>
Date: Thu, 07 Jul 2011 01:15:41 -0400

>> Are you supporting the inclusion of a unreliable datagram service

I support it as well.

> I don't have a big need for this but don't have a problem with it if others need it

I think we need to provide at least unreliable datagram service, and 
probably reliable datagram service.

>> please provide motivation and use case and requirements.

I'd rather have one well-debugged standard reliable datagram service 
than N so-so debugged 3rd-party services, which might not "play well 
together".

>> - Congestion Controlled, to be

And I'd say (generally to all the part of rtcweb) Unified Congestion 
Control of all streams that are part of the same session.

> +1 - I might phrase this a bit differently but I think we are getting at the same thing. If we are going to have encryption, there no point in encrypting something if you have no idea you our sendi…

I'm not sure I agree on Integrity Protection and Source Authentication.  
There are use cases where we want to have a private conversation (no 
eavesdropping or video leaked to Youtube!), but don't care if someone 
can block or disrupt the call.  (Someone with control of a link or 
midbox can do that already.)  I think those are important optional services.

+5

-- 
Randell Jesup
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 13 Jul 2011 17:57:47 +0200

Hi,

I have reviewed the input both the last 2 weeks and the discussion back
in April.

I see a strong support but with at least 2 people disagreeing to a basic
p2p datagram functionality. The use cases are various and some just
state that they see it as important functionality to provide to empower
the web application.

Based on this I declare a rough consensus on that we should provide a
non-media data service that is unreliable datagram oriented directly
between the peers.

One of objections against this was lack of clear requirements for what
the service. The straw men requirements I included has gotten some
discussion. Mostly support for them, but it is clear to me that we need
to further develop them. I would recommend the proponents for driving
proposals towards meeting this functionality to further discuss the
requirements taking the input so far into consideration.

When it comes to reliable data transfer between peers there has been 4-5
that wanted the functionality, 2 additional that explicitly stated they
where okay with it. No additional that has stated against it.

My interpretation is that we are close to having a rough consensus for
reliable data service, but we have so far seen no proponent willing to
suggest a solution for this. I would also note that a solution is likely
a functionality block that isn't dependent on more than the
signaling/negotiation and the NAT traversal and thus can be added a
later stage or be worked on with a completion date further into the
future than other pieces already.

So for reliable data I would recommend that someone takes on the role of
proponent and provides a draft with their perceived requirements and a
straw man proposal for how to solve these requirements so we have
something more tangible to discuss.

Cheers

Magnus

On 2011-06-27 09:36, Magnus Westerlund wrote:
> 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
> 
> 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.
> 
> directly between peers? Please provide your view and any additional
> data transport between the peers. I personally foresee that people will
> 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]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 

-- 

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: Wed, 13 Jul 2011 10:08:15 -0700

Instead of "NAT traversal", can we reduce-reduce that term to 
"synopsis". I've deleted my justification for that several times.

On 07/13/2011 08:57 AM, Magnus Westerlund wrote:
>> F�r�gatan 6                | Mobile +46 73 0949079

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

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 13 Jul 2011 11:28:40 -0700

One more thing, the constraint on that reduce-reduce is the high path.

P.S. "noise-reduction", we do not get upset over "soft" patents for 
noise reduction, please do...

--

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 13 Jul 2011 15:12:05 -0700

Updated: medium path flow called either "petrifaction" or "cloud". I 
know there are better words, oh ya, "traits".

Trinary machines... enjoy.

--

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 Jul 2011 09:15:25 +0200

> "synopsis". I've deleted my justification for that several times.

Dzonatas, your comments doesn't make sense to me. We need to use terms
that are as commonly well understood as possible.

Cheers

Magnus Westerlund

---

From: Dzonatas Sol <[email-masked]>
Date: Thu, 14 Jul 2011 07:32:54 -0700

My bad for thinking out-loud about star-topology.

--

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 15 Jul 2011 08:51:54 -0700

I'd like to push back on the reliable service. I've yet to hear a use case for it that was real time. It's very hard to do a reliable real time protocol and we have seen zero proposal for this. For non real time data, just dump it in dropbox of whatever your equivalent is and don't do it peer to peer. Unless someone has a real need, and wants to put forward a proposal, I don't see a need to focus energy on this right now. I'd rather work on the thing everyone agrees they do need which is the unreliable transfer. 

Cullen <in my individaul contribut role> 

>> establish WG consensus on both data service and any requirements.

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Tim Panton <[email-masked]>
Date: Fri, 15 Jul 2011 18:29:53 +0100

If we don't specify a  reliable transport then all the page authors will end adding a reliable layer in javascript, it will be as ugly as DTMF in RTP !
Or worse it will be spray and pray.

Most of the use-cases I can think of need  sequenced and reliable datagrams. If I'm playing a game I don't want it to
drop or mis-order any one of the actions in the unholster, point, shoot  sequence :-)

I don't think it is very hard to implement, we could take RFC 5456's sequencing and retry mechanism for example.
or indeed Plan9's IL .

Tim.

---

From: Emil Ivov <[email-masked]>
Date: Fri, 15 Jul 2011 20:15:44 +0200

On 15 juil. 2011, at 17:51, Cullen Jennings <[email-masked]> wrote:

> 
> I'd like to push back on the reliable service. I've yet to hear a use case for it that was real time. 

Adding to the DTMF and gaming mentioned by Tim, there's also:

- remote desktop control
- shared whiteboards

I'd also like to mention again the file transfer case. Although it is not exactly real-time, it does require a reliable datagram transport for NAT traversal, and it is part of most real-time applications.

Cheers,
Emil

--
http://jitsi.org

> It's very hard to do a reliable real time protocol and we have seen zero proposal for this. For non real time data, just dump it in dropbox of whatever your equivalent is and don't do it peer to peer. Unless someone has a real need, and wants to put forward a proposal, I don't see a need to focus energy on this right now. I'd rather work on the thing everyone agrees they do need which is the unreliable transfer. 
>

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 16 Jul 2011 10:26:43 -0700

I'm sure I mentioned one case on another WG that oftens gets dropped. 
The simple idea is to deliver content ahead of time by subscription to 
an event. The content is then deemed reliably deployed at by the 
schedule event. Last minute subscriptions are turned over to unreliable. 
The subscription can be as simple as SMTP, so that simplicity alone is 
why people drop and not look at it seriously enough.

If you have over 10,000 people for an event with massive amounts of 
pre-compiled content, then it makes sense to look at it more seriously. 
The complexity is only what people perceive as static content.

I hate to be the nag about such, yet protein topologies and 
crystallization techniques already have vocab that describe such 
ahead-of-time content delivery. The vocab is not accessible to 
everybody, so this is often overlooked as something else.

I don't see why we need to force pre-compiled content over real-time 
services, especially unreliable, and expect something reliable. People 
still do that, and it doesn't seem to be going away.

...as close as we can get to such use-case: start with the solution. =)

On 07/15/2011 08:51 AM, Cullen Jennings wrote:
> Cullen<in my individaul contribut role>
>

--

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 16 Jul 2011 10:41:00 -0700

Another (independent) perspective is http://www.relayforlife.org 
<http://www.relayforlife.org/> on Second Life for current capability 
(and... accessibility). The common tether is the (already noted) Olympics.

On 07/16/2011 10:26 AM, Dzonatas Sol wrote:
> schedule event. Last minute subscriptions are turned over to 
> unreliable. The subscription can be as simple as SMTP, so that 
> simplicity alone is why people drop and not look at it seriously enough.
>
> pre-compiled content, then it makes sense to look at it more 
> seriously. The complexity is only what people perceive as static content.
>
>> I'd like to push back on the reliable service. I've yet to hear a use 
>> case for it that was real time. It's very hard to do a reliable real 
>> time protocol and we have seen zero proposal for this. For non real 
>> time data, just dump it in dropbox of whatever your equivalent is and 
>> don't do it peer to peer. Unless someone has a real need, and wants 
>> to put forward a proposal, I don't see a need to focus energy on this 
>> right now. I'd rather work on the thing everyone agrees they do need 
>> which is the unreliable transfer.
>>

--

---

From: Randell Jesup <[email-masked]>
Date: Sat, 16 Jul 2011 14:37:28 -0400

> drop or mis-order any one of the actions in the unholster, point, shoot  sequence :-)

I must agree that if we don't provide a reliable transport in 
conjunction with the
other streams, you'll get a hodgepodge of incompatible, semi-functional
reliable transports layered on top of unreliable streams.  Not that one 
can't do a good
reliable transport on top of an unreliable layer, but people have 
varying abilities
to get it right.    Also, an integrated solution might have options for 
better
performance than a user-layered solution would (for example, prioritizing
certain packets from a reliable stream like restransmits or acks).

As for the need - one of the first real-time apps on the internet was 
netrek.  This
predates the  web by years (I was in a netrek league in 1991), in the 
days when
a big international company would have a 64Kbps connection.  The 
original TCP-based
protocol broke down badly when exposed to congestion and the real net.  
The solution
was to break the data streams into two: one unreliable one for most 
positional updates,
and a reliable stream for game-state-critical data (like "you're dead").

Saying "if you want reliable data, use a proxy" is also silly IMHO.

Perhaps some here from or formerly from Adobe can speak to the utility 
of reliable streams
in RTFMP.

In VoIP there's a consistent issue with the need to do some things (like 
DTMF) reliably when
your primary streams are unreliable.  Witness DTMF and the mess over RFC 
2833 vs SIP INFO.

-- 
Randell Jesup
[email-masked]

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 16 Jul 2011 13:30:09 -0700

On 07/16/2011 11:37 AM, Randell Jesup wrote:
> Not that one can't do a good
> to get it right.

If we assume nobody has the ability to "get it right" then; unreliable 
is the only solution.

> In VoIP there's a consistent issue with the need to do some things 
> (like DTMF) reliably when
> your primary streams are unreliable.  Witness DTMF and the mess over 
> RFC 2833 vs SIP INFO.

DTMF over JIT is one reason why some rather not allow others to get that 
right. Those who expect perfect flow rather just drop all other reliable 
use-cases. There is a famous case for this I avoid detail here.

For some reason we can't just say order reliable before unreliable 
because it is a waste over the given sequence (where that is already 
known). Here, the difference engine is easier to talk about.

If people really want anything like DTMF over JIT, then they may want to 
get into more formal methods of traffic-shapers, especially the schema 
to describe such for vocab.

Shape is reliable, also known as envelopes.

--

---

From: Dzonatas Sol <[email-masked]>
Date: Sat, 16 Jul 2011 15:49:31 -0700

On 07/16/2011 11:37 AM, Randell Jesup wrote:
> a big international company would have a 64Kbps connection. 

This one is hard to beat in regards to "firsts": http://bfi.org/

I'm not gonna argue on this list when ether- existed in history; 
however, we can grow this now, and we moved on to polymers. If someone 
has a string of lazy monomers that suddenly produce one real-time event 
together, is that "on-the-wire"? Better question is how we can get this 
terminology kept in school where others want to exploit it as a chain 
reaction (it's not). Quantum mechanics is still seems anti-social to 
some. We have patience, and setup simulations.

Some are afraid to approach this technology because they think they'll 
infringe on our business. Our business is more about the continual flow; 
rest assured, so some of these patents do not expire, like "instant" 
clean water.

--

---

From: Ted Hardie <[email-masked]>
Date: Sun, 17 Jul 2011 15:54:53 -0700

On Fri, Jul 15, 2011 at 8:51 AM, Cullen Jennings <[email-masked]> wrote:

>
> I'd like to push back on the reliable service. I've yet to hear a use case
> for it that was real time. It's very hard to do a reliable real time
> protocol and we have seen zero proposal for this. For non real time data,
> just dump it in dropbox of whatever your equivalent is and don't do it peer
> to peer.

Can I see your dropbox incantation for remote camera movement?  I am
particularly interested in how you make it useful without a reliable, near
real-time message that says "go check dropbox for $foo"....

To put this another way, a reliable protocol associated with a real time
stream has some pretty obvious uses (gaming has also already been
mentioned).  Whether it is truly "real time" or not is potentially subject
to debate, but the results of the semantic nit-picking won't tell us much.
The reliable protocol is a useful part of the real time system, even if its
retransmission and congestion control methods make it less "real time" than
rtp.

Just my two cents, also as an individual contributor,

Ted

---

From: Serge Lachapelle <[email-masked]>
Date: Mon, 18 Jul 2011 09:16:10 +0200

Hi Cullen,

I agree with your push back.

Focus is very important. Audio and video already present a huge challenge.
(signalling, network, web developer friendly API, security, browser
integration...)

Also, I think that there is a real risk in introducing "duplicate"
functionality in the browser as it may confuse web developers. There is a
lot going on in HTML5...

In my mind, this is "version 2.0" stuff.

/Serge

On Fri, Jul 15, 2011 at 17:51, Cullen Jennings <[email-masked]> wrote:

> to peer. Unless someone has a real need, and wants to put forward a
> proposal, I don't see a need to focus energy on this right now. I'd rather
> work on the thing everyone agrees they do need which is the unreliable
> transfer.
>

Google Sweden AB | Kungsbron 2, SE-111 22 Stockholm | Org. nr. 556656-6880
Apparently, this footer is required in Europe. Apologies. This email may be
confidential or privileged.  If you received this communication by mistake,
please don't forward it to anyone else,please erase all copies and
attachments, and please let me know that it went to the wrong person.
 Thanks.

---

From: Silvia Pfeiffer <[email-masked]>
Date: Mon, 18 Jul 2011 18:16:52 +1000

FWIW I agree that we should focus on audio and video communication and
not introduce extra complexity by trying to solve real-time data
communication at the same time.

If it falls out as a side effect that what we are developing satisfies
other use cases beyond audio and video, too, then that's fine. But we
should not develop for it. In my experience, real-time data typically
has different requirements than audio and video, such as a much
smaller data size, such as a much higher requirement on reliability of
data delivery (at least video delivery can be slightly lossy without
issues), such as a much smaller requirement on isosynchronous data
delivery, or a lesser requirement on low jitter.

There are already other means of delivering data between browsers such
as Web sockets and XMPP, so let's not confuse the landscape more by
trying to be all things to all people.

Regards,
Silvia.

---

From: Tim Panton <[email-masked]>
Date: Mon, 18 Jul 2011 10:28:45 +0100

I understand the pushback on supporting  reliable datagrams from Cullen, Silvia, Serge and others.

I'm pushing for it simply because I've had it in our browser rt-audio component, and used it extensively.
Without the ability to transport reliable datagrams in 'near realtime' the projects 
we have done would have been far less compelling for the user. The Datagrams are often the 
key to providing a special user experience, beyond conventional telephony. If we don't provide this,
we risk producing the tools for a round of  browser based deskphone emulators. We can do better.

As an example, the demo I show in this blog would have been much harder and less responsive without
realtime data coming back up the RFC 5456 channel :

https://babyis60.wordpress.com/2009/10/24/my-astricon-googlewave-ibook-skype-demo/

So I guess I am asking: Are we aiming for  browser based deskphone emulators or a new sort of
rich media experience for browser users? 

I know what I want.

Tim.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 Jul 2011 15:56:07 +0200

On 2011-07-15 19:29, Tim Panton wrote:
> I don't think it is very hard to implement, we could take RFC 5456's
> sequencing and retry mechanism for example. or indeed Plan9's IL .

I would warn about thinking this is easy. It is easy to get something
that works on sunny days, it is hard to build something that is secure,
efficient, robust and fair.

I would like to point out that a reliable protocol do need a number of
functions. If those are achieve from a lower layer or need to be
implemented in this protocol is a choice. However, functionalities such as:

- Congestion Control
- Flow Control
- Retransmission
- RTT estimation
- Buffer handling
- Parameter and functionality negotiation

Are likely all need for a safe and stable and future safe protocol.

There are good reasons for choosing something there is experience in
that it works.

For example I took a quick look at RFC5456 which appears to not have
congestion control. I think it is partly relying on that the transported
flow will adopt them self if trunking, or if not, that they become
useless and the call terminates because of that.

cheers

Magnus Westerlund

---

From: Tim Panton <[email-masked]>
Date: Mon, 18 Jul 2011 15:19:54 +0100

> efficient, robust and fair.

Agreed, getting all 4 in any protocol is hard, indeed I don't think I've seen it 
done yet.

> - Parameter and functionality negotiation

Agreed, but only Retransmission is specific to reliable datagrams (as opposed to
unreliable ones). 

> useless and the call terminates because of that.

RFC5456 has 2 sorts of packet
 - miniframes, which typically form the bulk of the traffic are handled unreliably. 
 - fullframes which are mostly used for signalling  but some of which are reliable datagrams (e.g. the TEXT frame type).
I was saying we could (in theory) ignore the miniframes and adopt the fullframe sequence,ack,retry mechanisms for
the reliable datagram transport.
The core protocol has been 'repurposed' in this way before : http://www.dundi.com/dundi.txt so it is definitely possible.

I take your point about the lack of congestion control, but the ACK mechanism could be used to detect incipient congestion.

Tim.

---

From: Randell Jesup <[email-masked]>
Date: Mon, 18 Jul 2011 10:34:35 -0400

> efficient, robust and fair.

Agreed, absolutely - which is why I don't want 100 bad designs (let 
alone implementations)
in Javascript.

> There are good reasons for choosing something there is experience in

Agreed also.  There are a few options, one of this is:
1) Encapsulated TCP-over-UDP, where the UDP channel is set up by the same
     mechanisms we use to set up the RTP channels, such as 
http://code.google.com/p/udptunnel/
     This is a big advantage in that normally devices behind NATs can't 
easily set up a direct TCP
     connection, and we can leverage the ability to set up p2p UDP 
channels to get it.

     The UDP channel could participate in the proposed shared bandwidth 
handling/
     congestion control, which is an advantage over a separate TCP 
channel.  The downside is that
     TCP's AIMD may cause interactions with the underlying bandwidth 
handling, so it may need
     to be excluded - some analysis is needed, once we know what we're 
doing on congestion
     control for the UDP channels.

     TCP's time characteristics are very well understood, though not 
optimal.

     The MTU would be slightly reduced - shouldn't be a problem.

It's not a datagram service, which is a minor downside, which offers the 
second option:
2) SCTP-over-UDP.  This is datagram-oriented and provides reliable delivery.
      It supports ECN and congestion control.

      One nice thing is that SCTP allows for unreliable delivery but 
with sequencing, or reliable
      delivery without in-sequence delivery, dependent on the 
application needs.  This can help
      the application optimize the realtime aspects of the reliable channel.

-- 
Randell Jesup
[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Mon, 18 Jul 2011 09:55:36 -0700

Forgive the top-posting, but I want to make a meta-comment.  If we were
planning on building something from scratch, I would strongly agree that it
would be quite tough going, especially given our timelines.  But this
working group is not allowed to re-use existing work, it is strongly
encouraged to do so.  Picking a protocol to implement which has the
characteristics below is a lot less difficult than re-starting the exercise
from scratch.

Providing XMPP, DTLS, or SCTP between the endpoints certainly has
challenges, but it would *not* involve starting from scratch.

regards,

Ted

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 18 Jul 2011 10:00:04 -0700

> Agreed, getting all 4 in any protocol is hard, indeed I don't think I've seen it 

FWIW - TLS over TCP with application level reconnect on failure seem to meet all 4. Where it fails if you can't easily do it in user space. So I'd add two more. Needs to work with high degree of nat/fw traversal success and be easy to deploy.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 18 Jul 2011 10:12:12 -0700

On Jul 17, 2011, at 15:54 , Ted Hardie wrote:

> I'd like to push back on the reliable service. I've yet to hear a use case for it that was real time. It's very hard to do a reliable real time protocol and we have seen zero proposal for this. For non real time data, just dump it in dropbox of whatever your equivalent is and don't do it peer to peer.
> 
> Can I see your dropbox incantation for remote camera movement?  I am particularly interested in how you make it useful without a reliable, near real-time message that says "go check dropbox for $foo"....

Ok, Ok, - I deserver to made fun of.  There are something you can't do with drop box or XMPP but lets take the PTU control problem. I have seen protocols that have semantics like "start panning right" or "pan right 10 degrees relative to current position". These protocol all have an lousy user experience compared to the ones that have semantics of "go to absolutely position Y at time X". IMHO, the best way to do a real time PTU control protocol is just periodical send the absolute position you want the camera to be at and send it more than once, or each time the users presses the button, if you don't want to do an ACK. It's hard to been something like that if latency is important. If latency is not important, XMPP is easier. (thought I would still send absolute not relative). I'll note more than one system is doing PTU control over RTP using an approach much like sending DTMF via RTP.

> 
> To put this another way, a reliable protocol associated with a real time stream has some pretty obvious uses (gaming has also already been mentioned).

I'm pushing back on it is obvious that there are use cases for this. That there is simultaneous need for the semantics of "you must deliver this data no matter how long it takes" and "this data need to get there in less than X time or it is useless" is not obvious to me. 

That said, if someone has a proposal to go do this, as I said before, I have no object to doing this. It be fine to have reliability but I'm not seeing it as critical for use cases like gaming and PTU control. 

>  Whether it is truly "real time" or not is potentially subject to debate, but the results of the semantic nit-picking won't tell us much.  The reliable protocol is a useful part of the real time system, even if its retransmission and congestion control methods make it less "real time" than rtp.

agree

---

From: Tim Panton <[email-masked]>
Date: Mon, 18 Jul 2011 18:35:54 +0100

> I'm pushing back on it is obvious that there are use cases for this. That there is simultaneous need for the semantics of "you must deliver this data no matter how long it takes" and "this data nee…

To my mind,  _sequence_ is vital. 

The protocol should promise to deliver these datagrams to the application layer in the order that they were
sent. If that requires an occasional round-trip delay to cope with packet loss (perhaps with a flag to say it was late),
that's acceptable (but sub-optimal), out-of-order datagrams aren't.  

In the vast majority of cases we can expect it to deliver the datagram in close sync with the associated media.

Tim.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 18 Jul 2011 11:21:23 -0700

> If we don't specify a  reliable transport then all the page authors will end adding a reliable layer in javascript, it will be as ugly as DTMF in RTP !

Tim, I agree with your concern here. My largest concern of not specifying something is that it just means we will see a million different things done in JavaScript. That's pretty much what we have in the IETF today. Lots of protocols implement a different reliability layer on top of UDP. However, it has not been all that bad and it has been very hard to get the transport guys to go and define one that everyone can use (I've presented in transport asking for this in the past). The end result has not really been all that bad. The protocols work even thought each one did there own reliability systems so I have not been all that worried about it. I'm not sure DTMF is a fair example to compare to...

> Or worse it will be spray and pray.

sort of like we do with audio and video in RTP :-) 

> drop or mis-order any one of the actions in the unholster, point, shoot  sequence :-)

A game might have a UI that requires you to do but due to round trip latency times, most games  are going to send over the write something more like an object to type bullet exists at this location in Phase/Time space and let both sides simulate from that and decide if there was a hit or not. The phase/time space is just the location of the bullet, information about it such as it's type, and it's velocity vector as well as the point in time. That might get acked or retransmitted or just ignored on loss depending on the reliability of the game but a FPS is going to have crappy UE if it both side to multiple lock step transaction to keep state like unholster, point, shoot in sync between the sides. 

> I don't think it is very hard to implement, we could take RFC 5456's sequencing and retry mechanism for example.

Again, no object to someone coming up with a good proposal (I suspect that 5456 would get more than a bit of push back) but it's not on my high priority list because the games I can think of could probably work fine with a proposal more like the above than needing a reliable protocol. That said, I do share your concern about we will just see lots of crappy implementations of this a reliable protocol for file transfer on top of whatever we do for this RTCWeb work. 

Cullen Jennings

---

From: Dzonatas Sol <[email-masked]>
Date: Mon, 18 Jul 2011 11:44:51 -0700

On 07/18/2011 10:12 AM, Cullen Jennings wrote:
> There are something you can't do with drop box or XMPP but lets take 
> the PTU control problem. I have seen protocols that have semantics 
> like "start panning right" or "pan right 10 degrees relative to 
> current position". These protocol all have an lousy user experience 
> compared to the ones that have semantics of "go to absolutely position 
> Y at time X".

Gets kind of hard in consideration of gesture recognition as semantics, 
so I think the example above shows why semantic terminology leads to 
bloat without given sequences. The difference is useful where error 
correction is more obvious; for example, avoidance of RTT vs 
retransmission (over wireless). Lossless compression is valuable here, 
yet the semantics of compression let people think lossy is ideal, which 
lossy leads later to extra links (the bloat). Tweaked the example above: 
"track X for duration Y until Z"

--

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 18 Jul 2011 11:52:26 -0700

> I'd like to push back on the reliable service. I've yet to hear a use case for it that was real time. It's very hard to do a reliable real time protocol and we have seen zero proposal for this. For…

I'm personally torn on this one. I think that if we want to get something actually specified and deal with the majority of the use cases, we really need to focus on A/V and make data as simple as possible... that means unreliable datagrams with nothing but browser enforcement of rate via a simple congestion control algorithm.

On the other hand, if we go that route, people building things with the API will be forced to do it in Javascript... and all the arguments for putting ICE in the browser code instead of Javascript apply here, specifically that getting it right for N=# of browser implementations case is much more likely than getting it right for N=# of Javascript coders case.

But to get there probably requires solving many of the same set of problems that MFP and RTMFP solved, and that's a whole lot of specification and code to implement it, and we haven't even started on the agreement of which building blocks to start with (DCCP? SCTP? TCP over UDP?) much less gotten to a complete specification.

Unfortunately the right answer is probably to, once again, go to TSVAREA and state that a protocol that fits set of requirements would be really useful, and then not put it in browsers until it exists. There might be some value to making that ask in the form of a requirements document, but it needs to not be a "requirements of browsers for RTCWEB", instead it needs to be "requirements for a data transport protocol if a sophisticated one were to be added to RTCWEB in the future".

As I do remember most of the reasons we came up with MFP and RTMFP, I would be glad to contribute to such a requirements document.

But until then, I think we need *something* that lets data get from A to B over the direct unreliable channel.

Matthew Kaufman

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 18 Jul 2011 13:03:34 -0700

> But until then, I think we need *something* that lets data get from A to B over the direct unreliable channel.

I find myself on about the same page. I'd be happy to help go write up some requirement slides for the transport area.

---

From: Randell Jesup <[email-masked]>
Date: Mon, 18 Jul 2011 18:11:08 -0400

On 7/18/2011 1:12 PM, Cullen Jennings wrote:
>> On Fri, Jul 15, 2011 at 8:51 AM, Cullen Jennings<[email-masked]>  wrote:
>>

I agree it's easier/more accurate to say "move to X".  However, people 
are used to various
"continuous" motion controls, like zoom and trying to frame a subject, 
or follow motion.  From
a UI point of view, a good low-delay continuous reactive system is often 
more functional, depending
the problem space.  People will find a way to fit their preferred user 
experience onto the protocol,
even if it's not a good fit for the protocol, because they don't care 
about the protocol - they
care about their UI.

> I'm pushing back on it is obvious that there are use cases for this. That there is simultaneous need for the semantics of "you must deliver this data no matter how long it takes" and "this data nee…

It's rare that "no matter how long it takes" is hugely delayed - if it 
is, you have other, bigger
problems.  Delayed - could well be; usually only a little, with some 
jitter.  And SCTP would
be even better as far as that's concerned.

Talk to some RT networked game designers.  I'll bet they all use a mix 
of reliable and unreliable
protocols (perhaps not like TCP, more like SCTP).  But even though 
reliable == not guaranteed,
I'll bet they all want it to get there as fast as possible in the normal 
case.

People are ignoring the huge positive of having this data connection 
bundled with the other
streams and connected with them.  Having to set up a parallel reliable 
stream adds all sorts
of complexity to the application when firewall traversal/IP address 
changes/etc are included, and
then you have the issue of it being a second distinct stream from a 
congestion point of view - it
makes it very hard to control the relative bandwidth of the reliable 
stream versus all the unreliable
streams - you're likely to get ~ 50% for the reliable stream if you're 
overcommitted, with the % varying
quite a bit.  And if the stream has to go through a relay or server 
while media goes P2P
you have an issue for people designing services to use this protocol - 
increased cost and bandwidth
for one.  Even a chat-with-file-transfer - if the file xfer has to go 
through the server, you have to maintain
bandwidth for that case, and transfer speed may be limited by RTT of 
going through a remote server
(think Taiwan user to Taiwan user with a relay in the US).

All that said - yes, there are complexity issues to consider, which was 
why I was suggesting leveraging
an existing tunneled protocol like SCTP or even TCP-over-UDP.

-- 
Randell Jesup
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Jul 2011 16:01:56 +0200

On 2011-07-18 20:21, Cullen Jennings wrote:
> 
> Tim, I agree with your concern here. My largest concern of not
> specifying something is that it just means we will see a million
> different things done in JavaScript. That's pretty much what we have
> in the IETF today. Lots of protocols implement a different
> reliability layer on top of UDP. 

I would note that the the JS library at least is going to run on top of
a congestion controlled and secured datagram service. Thus, any
implementor can primarily hurt themselves rather than the network.

> However, it has not been all that
> bad and it has been very hard to get the transport guys to go and
> define one that everyone can use (I've presented in transport asking
> for this in the past). The end result has not really been all that
> bad. The protocols work even thought each one did there own
> reliability systems so I have not been all that worried about it. I'm
> not sure DTMF is a fair example to compare to...

I can't resist this bate as a transport guy. Well, things don't happen
for free, and no one was willing to stick in there for the long haul to
actually define it.

There also has been a lot of political resistance, and the fact that
transport development in OS etc happens at glacier speed, unless someone
well connected enough truly wants something.

I think a reasonable, re-use as much as possible, sane proposal has some
chance. And we WG chairs should try to get early feedback from TSV-Dir
etc so we avoid late surprises.

Please note that this is not an a comment in any direction around the
support for reliable data service. Just trying to provide some
background and feel for the land.

cheers

Magnus Westerlund

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 19 Jul 2011 09:16:42 -0500

+1
Maybe it would be useful for the proponents of this and many other
³desirable² features to think from the perspective if they would have to pay
themselves for such developments and also make the code freely available.
Cullen at least will make his code available.

Thanks, Henry

On 7/18/11 2:16 AM, "Serge Lachapelle" <[email-masked]> wrote:

> functionality in the browser as it may confuse web developers. There is a lot
> going on in HTML5...
> 
>> for it that was real time. It's very hard to do a reliable real time protocol
>> and we have seen zero proposal for this. For non real time data, just dump it
>> in dropbox of whatever your equivalent is and don't do it peer to peer.
>> Unless someone has a real need, and wants to put forward a proposal, I don't
>> see a need to focus energy on this right now. I'd rather work on the thing
>> everyone agrees they do need which is the unreliable transfer.
>> 
>>>> >> Ericsson AB                | Phone

---

From: Justin Uberti <[email-masked]>
Date: Tue, 19 Jul 2011 08:58:55 -0700

At Google, we created a TCP/ICE-UDP layering to solve this exact problem,
using a user-mode implementation of TCP. It has some rough edges, but has
worked well in practice, and the code is freely available.

We know people will want/need a reliable messaging mechanism for p2p data.
While we can debate the details of this mechanism at length, I suspect
anything we choose will result in a better end-state than if we require
application developers to implement their own.

On Tue, Jul 19, 2011 at 7:16 AM, Henry Sinnreich
<[email-masked]>wrote:

> “desirable” features to think from the perspective if they would have to pay

---

From: Randell Jesup <[email-masked]>
Date: Tue, 19 Jul 2011 12:37:14 -0400

On 7/19/2011 11:58 AM, Justin Uberti wrote:
> At Google, we created a TCP/ICE-UDP layering to solve this exact 
> problem, using a user-mode implementation of TCP. It has some rough 
> edges, but has worked well in practice, and the code is freely available.

Right; pretty much what I'd anticipate, and working open code is good.  
SCTP as mentioned is a good choice too, and there exist (it appears) 
SCTP-over-UDP implementations, which may ease things.  Also the 
TCP-over-UDP library I pointed to.

> We know people will want/need a reliable messaging mechanism for p2p 
> data. While we can debate the details of this mechanism at length, I 
> suspect anything we choose will result in a better end-state than if 
> we require application developers to implement their own.

As is obvious from my other messages, I agree wholeheartedly.

> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     +1
>     “desirable” features to think from the perspective if they would
>     have to pay themselves for such developments and also make the
>     code freely available.

See above.  No one here wants to develop *another* reliable protocol if 
we can avoid it.  I understand your reluctance.

The goal is to produce something that will meet the needs and get used.  
If we don't meet the
needs of the prospective users it's either an total waste of time (if 
they ignore this effort and stick
with Flash/plugins/etc) or we get all sorts of 
hack/bad/problematic/incompatible implementations
by individual developers using the UDP (or RTP!) streams we open as a 
base transport.

To your point, another way this effort could fail is by biting off too 
much or taking too long to
converge, which is a real danger.  That's one reason to leverage 
existing protocols.

-- 
Randell Jesup
[email-masked]

---

From: Emil Ivov <[email-masked]>
Date: Tue, 19 Jul 2011 19:02:11 +0200

На 19.07.11 18:37, Randell Jesup написа:
> Right; pretty much what I'd anticipate

+1 most definitely. Again, I have yet to see a massively used RTC
application that doesn't have file transfer. So if this is not part of
RTCWEB we will basically be asking developers to reimplement Pseudo TCP
in JavaScript.

Emil

>, and working open code is good.  

-- 
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: Serge Lachapelle <[email-masked]>
Date: Tue, 19 Jul 2011 19:09:23 +0200

There are many very established ways to transfer files from a web browser.
Dropbox, Google Docs, yousendit, mobileme, not counting the media specific
ways, such as Flickr, Spotify, Youtube, etc... All offering great APIs for
uploads, ACLs, etc...

Seems like re-inventing the wheel.

/Serge

-- 
Serge Lachapelle | Product Manager | [email-masked] | +46 732 01 22 32
Google Sweden AB | Kungsbron 2, SE-111 22 Stockholm | Org. nr. 556656-6880

---

From: Emil Ivov <[email-masked]>
Date: Tue, 19 Jul 2011 19:21:29 +0200

На 19.07.11 19:09, Serge Lachapelle написа:
> There are many very established ways to transfer files from a web
> browser. Dropbox, Google Docs, yousendit, mobileme, not counting the
> media specific ways, such as Flickr, Spotify, Youtube, etc... All
> offering great APIs for uploads, ACLs, etc...

I am sorry, I should have been more specific when referring to the file
transfer use case. What I meant was the possibility to let users send
files directly to each other.

All of the services you quote above have a public sharing or a backup
aspect that requires files to be stored on a server. Sending files
however, does not have this constraint so forcing the flow to go through
a public relay is only unnecessary overhead.

> Seems like re-inventing the wheel.

Yeah ... but people do that every now and then ;)

http://code.google.com/p/libjingle/source/browse/trunk/talk/p2p/base/pseudotcp.h

Emil

> 
> /Serge
> 
> On Tue, Jul 19, 2011 at 19:02, Emil Ivov <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     >> <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     >>
>     >>     +1
>     [email-masked] <mailto:[email-masked]>                      
>      PHONE: +33.1.77.62.43.30 <tel:%2B33.1.77.62.43.30>
>     <tel:%2B33.1.77.62.47.31>
> 
>     [email-masked] <mailto:[email-masked]>
> Serge Lachapelle | Product Manager | [email-masked]
> <mailto:[email-masked]> | +46 732 01 22 32
> <tel:%2B46%20732%2001%2022%2032>
> Apparently, this footer is required in Europe. Apologies. This email may
> be confidential or privileged.  If you received this communication by
> mistake, please don't forward it to anyone else,please erase all copies
> and attachments, and please let me know that it went to the wrong
> person.  Thanks.

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 19 Jul 2011 10:37:08 -0700

I suspect that TCP becomes the new semantic word for all browsers, as 
otherwise the movement of TCP to user-mode is already evident, and 
redundantly done (as suggested). TCP was the default way for developers 
to find stream-modes. Portability, like this, misrepresents needs beyond 
beginner layers.

Despite change, UDP over HTTP over S/MIME appears proper and quick 
enough (i.e. "can harden"). Path of least resistance... SSRC already 
offers that bit of available change and overlap. The question for 
standard besides mux is only expect RTP first or use OPTIONS to 
downgrade HTTP. We've used 1xx to bypass HTTP/TCP layers before, so in 
fairness I don't think this is correct for rtcweb in regards to states.

Implementation at software level seems futile if that concept is really 
that hard. We need non-encrypted unshrunken headers. Either that or 402 
out of no-where simply bytes for energy alone... a security disaster. I 
usually stay quiet about that, yet please note that harvesters are this 
artificially intelligent now. =)

On 07/19/2011 08:58 AM, Justin Uberti wrote:
>     On 7/18/11 2:16 AM, "Serge Lachapelle" <[email-masked]
>     <http://[email-masked]>> wrote:
>
>         Hi Cullen,
>
>         Focus is very important. Audio and video already present a
>         huge challenge. (signalling, network, web developer friendly
>         API, security, browser integration...)
>
>         Also, I think that there is a real risk in introducing
>         "duplicate" functionality in the browser as it may confuse web
>         developers. There is a lot going on in HTML5...
>
>         On Fri, Jul 15, 2011 at 17:51, Cullen Jennings
>         <[email-masked] <http://[email-masked]>> wrote:
>
>
>             I'd like to push back on the reliable service. I've yet to
>             hear a use case for it that was real time. It's very hard
>             to do a reliable real time protocol and we have seen zero
>             proposal for this. For non real time data, just dump it in
>             dropbox of whatever your equivalent is and don't do it
>             peer to peer. Unless someone has a real need, and wants to
>             put forward a proposal, I don't see a need to focus energy
>             on this right now. I'd rather work on the thing everyone
>             agrees they do need which is the unreliable transfer.
>

--

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 19 Jul 2011 11:51:16 -0700

> http://code.google.com/p/libjingle/source/browse/trunk/talk/p2p/base/pseudotcp.h

Exactly why mainframes and clouds go hand and hand now: TCP is not 
sustainable.

--

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 19 Jul 2011 16:23:16 -0700

> converge, which is a real danger.  That's one reason to leverage 

Baby-safe is what I keep in mind every day. I'm not perfectr, neither is 
danger.

Maybe some systems want optimizational values out of their protocols 
because they see no need for the consumption of computational energy. 
All the riches, what the world want at even given moment. Practical reality.

--

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 19 Jul 2011 18:13:50 -0700

On Jul 18, 2011, at 15:11 , Randell Jesup wrote:

> All that said - yes, there are complexity issues to consider, which was why I was suggesting leveraging

I agree with bunch of what you are saying but the previous several times I've seen the use SCTP over UDP conversation, it usually ends about the point the we ask for a user land implementation. Whatever we do more or less has to be user land or already exist in the OS that people run browsers on. 

If someone has a user land implementation of SCTP or TCP, I imagine that might change the outcome a bit from previous times. I have not looked at the TCP over UPD library Justin mentioned but, at casual glance, I noticed is around 400 lines of code which is very small, which is cool. But given the lines of code in say the BSD TCP stack, it does make me wonder what's missing. That said, I don't think we need something with the perforce of the BSD TCP stack as long as what is there is TCP friendly and robust.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 19 Jul 2011 18:20:59 -0700

> https://babyis60.wordpress.com/2009/10/24/my-astricon-googlewave-ibook-skype-demo/

cool - I had not seen that before 

> rich media experience for browser users? 

Hey, I just want my black phone :-) Ok, I'm sold that a reliable data mechanisms be used and if people build their own, many of them will be bad. 

Cullen Jennings

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 20 Jul 2011 11:43:48 +0200

> Seems like re-inventing the wheel.
I tend to agree. What the data channel of rtcweb could provide is 
shorter latency - but to me that does not seem relevant for a file transfer.
> Serge Lachapelle | Product Manager [email-masked]
> <mailto:[email-masked]> |+46 732 01 22 32

---

From: Emil Ivov <[email-masked]>
Date: Wed, 20 Jul 2011 13:08:59 +0200

> shorter latency - but to me that does not seem relevant for a file transfer.

I am not so sure about that. Transferring a file directly between you
and your peer is often way faster than relaying through the servers of
well known services. The time necessary to transfer several tens of megs
can very greatly ... from a couple of minutes to an hour or more. Users
are definitely very sensitive to this.

Besides, this is not only about the latency. It's mostly about the
reources that such relayed transfers require on the server side. Most
providers want to bring those to a minimum. So much so, that some even
put relatively low caps on the traffic you can send through the
signalling channel.

For example, the desktop sharing implementation we have in Jitsi uses
signalling (SIP or XMPP) to convey key and mouse events. When using
Google's XMPP service users would regularly experience blockages caused
by the Google service dropping XMPP IQs when they go above a certain
frequency. And this is in no way a criticism for the service itself ...
it is however definitely a reason to have a reliable means of
communicating directly between peers (or at least as directly as possible).

Emil

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 20 Jul 2011 15:15:02 +0200

> If someone has a user land implementation of SCTP or TCP, I imagine that might change the outcome a bit from previous times. I have not looked at the TCP over UPD library Justin mentioned but, at c…
I believe this is the current URL:

http://code.google.com/p/libjingle/source/browse/trunk/talk/session/tunnel/pseudotcpchannel.cc 
(500 or so lines).

The real protocol implementation is here:
http://code.google.com/p/libjingle/source/browse/trunk/talk/p2p/base/pseudotcp.cc
which is another 1000 lines (not counting the various .h files).

We're not THAT good at writing compact code :-)

---

From: Randell Jesup <[email-masked]>
Date: Wed, 20 Jul 2011 11:29:36 -0400

> shorter latency - but to me that does not seem relevant for a file 

For some use-cases that's important (shorter on average, not guaranteed) 
- for example games.  Others like the Google Wave demo Tim posted 
(https://babyis60.wordpress.com/2009/10/24/my-astricon-googlewave-ibook-skype-demo/) 
would be painful (and hurt usability) to implement using drop-box like 
transfers.

For other cases (file xfer), yes you can use those - but the problem is 
that when you want to transfer to the person you're chatting with, you 
would need to use another service, agree on it, deal with the 
semantics/accounts/limits/etc for that service, etc.  A horrible user 
experience.  Even if it was "hidden" by the application, it would be 
problematic and subject to breakage continually.

-- 
Randell Jesup
[email-masked]

---

From: Justin Uberti <[email-masked]>
Date: Wed, 20 Jul 2011 11:37:12 -0400

On Wed, Jul 20, 2011 at 9:15 AM, Harald Alvestrand <[email-masked]>wrote:

>> I agree with bunch of what you are saying but the previous several times
>> I've seen the use SCTP over UDP conversation, it usually ends about the
>> point the we ask for a user land implementation. Whatever we do more or less
>> has to be user land or already exist in the OS that people run browsers on.
>>
>> If someone has a user land implementation of SCTP or TCP, I imagine that
>> might change the outcome a bit from previous times. I have not looked at the
>> TCP over UPD library Justin mentioned but, at casual glance, I noticed is
>> around 400 lines of code which is very small, which is cool. But given the
>> lines of code in say the BSD TCP stack, it does make me wonder what's
>> missing. That said, I don't think we need something with the perforce of the
>> BSD TCP stack as long as what is there is TCP friendly and robust.
>>
> http://code.google.com/p/**libjingle/source/browse/trunk/**
> talk/session/tunnel/**pseudotcpchannel.cc<http://code.google.com/p/libjingle/source/browse/trunk/talk/session/tunnel/pseudotcpchannel.cc>(500 or so lines).
>
> http://code.google.com/p/**libjingle/source/browse/trunk/**
> talk/p2p/base/pseudotcp.cc<http://code.google.com/p/libjingle/source/browse/trunk/talk/p2p/base/pseudotcp.cc>

Yes, I was going to send a similar email. There are some
deficiencies/optimizations for the fact it runs over ICE-UDP - doesn't do
path MTU discovery, no checksum, no OOB data - but it is based on TCP and
implements slow start and other congestion avoidance mechanisms, and is
actively used by a number of applications where reliable transfer is
important, such as file transfer and remote desktop applications.

>
>>
>>
>>
>> ______________________________**_________________
>> rtcweb mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>>
>>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Serge Lachapelle <[email-masked]>
Date: Wed, 20 Jul 2011 21:11:17 +0200

> that when you want to transfer to the person you're chatting with, you would
> need to use another service, agree on it, deal with the

If I am building a 1:1 or hangout style application connecting my users, I
would simply integrate it or add the functionality in the web UI I am
building. This is very easy to do with web services these days.

/Serge

---

From: Serge Lachapelle <[email-masked]>
Date: Wed, 20 Jul 2011 22:00:32 +0200

Just to put the file transfer debate to bed from my end, I am not against
reliable channels, in fact, a ton of innovation can come from it when made
available to browsers.

I just want to avoid any re-engineering of what browsers offer today as much
as possible.

/Serge

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 20 Jul 2011 13:37:39 -0700

Agreed. 

To make this a bit more concrete.  From your perspective, what is the preferred mechanism for file transfer in XMPP, and what would it take to support this in a browser? 

From: [email-masked]
Date: Wed, 20 Jul 2011 22:00:32 +0200
To: [email-masked]
CC: [email-masked]
Subject: Re: [rtcweb] realiable data service

Just to put the file transfer debate to bed from my end, I am not against reliable channels, in fact, a ton of innovation can come from it when made available to browsers.
I just want to avoid any re-engineering of what browsers offer today as much as possible.

/Serge

For other cases (file xfer), yes you can use those - but the problem is that when you want to transfer to the person you're chatting with, you would need to use another service, agree on it, deal with the semantics/accounts/limits/etc for that service, etc.  A horrible user experience.  Even if it was "hidden" by the application, it would be problematic and subject to breakage continually.

If I am building a 1:1 or hangout style application connecting my users, I would simply integrate it or add the functionality in the web UI I am building. This is very easy to do with web services these days.

/Serge

-- 

Apparently, this footer is required in Europe. Apologies. This email may be confidential or privileged.  If you received this communication by mistake, please don't forward it to anyone else,please erase all copies and attachments, and please let me know that it went to the wrong person.  Thanks.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 20 Jul 2011 20:35:10 -0600

On 7/20/11 2:37 PM, Bernard Aboba wrote:
> Agreed.
>
> To make this a bit more concrete. From your perspective, what is the
> preferred mechanism for file transfer in XMPP, and what would it take to
> support this in a browser?

The great thing about file transfer mechanisms in XMPP is that there are 
so many to choose from. :)

The most reliable mechanism is "in-band bytestreams", a simple chunking 
method that uses the XMPP channel itself. That's not the fastest method 
but it's the most reliable. Clearly it would be faster to set up a 
direct connection, or if that fails because of NATs to use a relay. We 
have a technology for that, too, but we don't have a lot of relays 
deployed on the network. Then there's the pseudo-tcp stuff that Google 
uses in Google Talk. Or you can upload the file somewhere and just send 
a URL (which makes a lot of sense if you're using BOSH instead of the 
traditional TCP connection method).

I'm not yet convinced that any of those methods is quite right for 
RTCWEB, but I haven't studied the problem intensively.

Peter

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 22 Jul 2011 19:33:00 -0700

On Jul 20, 2011, at 8:37 , Justin Uberti wrote:

> 
> 
> On Wed, Jul 20, 2011 at 9:15 AM, Harald Alvestrand <[email-masked]> wrote:
> http://code.google.com/p/libjingle/source/browse/trunk/talk/session/tunnel/pseudotcpchannel.cc (500 or so lines).
> 
> Yes, I was going to send a similar email. There are some deficiencies/optimizations for the fact it runs over ICE-UDP - doesn't do path MTU discovery, no checksum, no OOB data - but it is based on TCP and implements slow start and other congestion avoidance mechanisms, and is actively used by a number of applications where reliable transfer is important, such as file transfer and remote desktop applications.
>  
> 

It would be really interesting to see someone write a draft that subsets TCP to make it 

1) still be congestion safe and TCP friendly 

2) be valid TCP from point of view nats and firewalls

3) match an implementation like the one you have here. 

Most our use cases do not need OOB data. A subset protocol that was missing something like path MTU discovery might be slower than full blown modern TCP but again, most out use cases would still work just fine. As much as the IETF hates sub setting protocols, having something concrete and in hand like this would be a pretty useful thing. As well as being useful for the wwebrtc work, something like this would be useful for very constrained systems such very cheap sensor networks. I'm seeing lots of really minimal subset of TCP being done for these very low end system.

---

From: Tim Panton <[email-masked]>
Date: Sat, 23 Jul 2011 13:50:29 +0100

> It would be really interesting to see someone write a draft that subsets TCP to make it 

I just want to flag that TCP isn't an especially good fit here, datagrams delivered in events are a very useful
abstraction in JavaScript, which doesn't really do streams of data very well. 

I know we can do datagrams over TCP,  but
it seems wasteful to de-packetize in the TCP layer, just to try and re-packetize it a couple of layers further up.

If there is a reliable datagram protocol as opposed to a reliable stream, I'd go for the datagram every time.

Tim.

---

From: Emil Ivov <[email-masked]>
Date: Sat, 23 Jul 2011 17:26:32 +0200

> 2) be valid TCP from point of view nats and firewalls

Why does it need to be valid TCP? What NATs and firewalls will see is
valid UDP which is the whole point, isn't it?

The fact that the protocol carried in the datagrams is TCP-like only
matters to the application.

Emil

--
http://jitsi.org

---

From: Justin Uberti <[email-masked]>
Date: Sun, 24 Jul 2011 07:40:25 -0700

On Sat, Jul 23, 2011 at 5:50 AM, Tim Panton <[email-masked]> wrote:

> it seems wasteful to de-packetize in the TCP layer, just to try and
> re-packetize it a couple of layers further up.
>

Yes, the API here will be datagram-oriented, just like WebSockets. Ideally,
the API for this would match WebSockets exactly, so that code in higher
layers can be agnostic about exactly how the data is being sent.

Even as a "datagram" service, I think TCP is still the best fit. The fact
that it is well-understood and has countless working implementations is far
more significant than any cost of framing (which will likely be trivial).

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 24 Jul 2011 10:49:02 -0400

agree on the high level API you want something datagram oriented... I was just thinking about the congestion control / reliability approach of TCP and fine if a reliable , in order, datagram is put on top of that. 

inline ...

> valid UDP which is the whole point, isn't it?

I should not have put nats you are right - I'm so used to typing nats and fws :-) On the firewalls that do protocol inspection, they may very well want to be able to parse this layer and even the things inside it. I suspect that code that is there is already valid TCP from the point of view of firewalls so I doubt this requirement really changes anything one way or the other. 

> matters to the application.

Sort of, lots of firewalls are configured not to allow UDP packets to pass unless they understand what is in them.

Cullen Jennings

---

From: Justin Uberti <[email-masked]>
Date: Sun, 24 Jul 2011 08:03:12 -0700

On Fri, Jul 22, 2011 at 7:33 PM, Cullen Jennings <[email-masked]> wrote:

> http://code.google.com/p/libjingle/source/browse/trunk/talk/session/tunnel/pseudotcpchannel.cc(500 or so lines).
> >
> Most our use cases do not need OOB data. A subset protocol that was missing
> something like path MTU discovery might be slower than full blown modern TCP
> but again, most out use cases would still work just fine. As much as the
> IETF hates sub setting protocols, having something concrete and in hand like
> this would be a pretty useful thing. As well as being useful for the wwebrtc
> work, something like this would be useful for very constrained systems such
> very cheap sensor networks. I'm seeing lots of really minimal subset of TCP
> being done for these very low end system.
>

Interesting. From the webrtc context, the requirements are a little
different - e.g. when we're running as TCP/UDP, we don't need the port or
checksum, as those are handled by the UDP layer.

So the goal would become two specs:
(1) minimal subset of TCP
(2) adaptation of #1 to run over UDP instead of IP

Who can speak to what requirements/RFCs should constitute #1? We could
certainly make a proposal based on what we've implemented, but if it's going
to be used more broadly, I'm guessing a LOT of folks will care about these
details.

For #2, in addition to the work we've done with what we call PseudoTcp, I've
noticed these two other drafts on TCP/UDP, which are very similar to
PseudoTcp. The first gives a very good treatment (in Section 8) of why a
PseudoTcp-like approach is the best way for reliable p2p data transfer.

http://tools.ietf.org/html/draft-baset-tsvwg-tcp-over-udp-01
http://tools.ietf.org/html/<http://tools.ietf.org/html/draft-denis-udp-transport-00>
draft-denis-udp-transport-00<http://tools.ietf.org/html/draft-denis-udp-transport-00>

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 24 Jul 2011 11:20:57 -0400

On 07/22/11 22:33, Cullen Jennings wrote:
>> On Wed, Jul 20, 2011 at 9:15 AM, Harald Alvestrand<[email-masked]>  wrote:
ObNitpick: TCP doesn't have OOB data.

What it has is an "urgent data downstream" pointer, which the Unix 
implementors used to pick the byte pointed to out of the data stream and 
deliver it "urgently" as if it was OOB data.
I exchanged mail with Jon Postel about this in 1984, and he confirmed 
that if a TCP protocol stack gets 2 TCP segments with different URG 
pointers, a TCP implementation can merge them and only deliver the 
latest URG pointer - which means that delivery of the OOB data is 
unreliable if you have more than 1 in flight at any one time; you might 
get the byte inband, and you might get it out of band.

This conflict of viewpoints between the protocol design and the API 
design has, I believe, rendered the TCP URG pointer useless for all 
practical purposes.

Returning to more relevant stuff: I think we need to handle PMTU issues 
somehow. This may be hard.

                   Harald

---

From: Justin Uberti <[email-masked]>
Date: Sun, 24 Jul 2011 08:27:09 -0700

On Sun, Jul 24, 2011 at 8:20 AM, Harald Alvestrand <[email-masked]>wrote:

>>> On Wed, Jul 20, 2011 at 9:15 AM, Harald Alvestrand<harald@alvestrand.**
>>> no <[email-masked]>>  wrote:
>> Most our use cases do not need OOB data. A subset protocol that was
>> missing something like path MTU discovery might be slower than full blown
>> modern TCP but again, most out use cases would still work just fine. As much
>> as the IETF hates sub setting protocols, having something concrete and in
>> hand like this would be a pretty useful thing. As well as being useful for
>> the wwebrtc work, something like this would be useful for very constrained
>> systems such very cheap sensor networks. I'm seeing lots of really minimal
>> subset of TCP being done for these very low end system.
>>
> I exchanged mail with Jon Postel about this in 1984, and he confirmed that
> if a TCP protocol stack gets 2 TCP segments with different URG pointers, a
> TCP implementation can merge them and only deliver the latest URG pointer -
> which means that delivery of the OOB data is unreliable if you have more
> than 1 in flight at any one time; you might get the byte inband, and you
> might get it out of band.
>
> This conflict of viewpoints between the protocol design and the API design
> has, I believe, rendered the TCP URG pointer useless for all practical
> purposes.
>

The easy way may be to do what we're likely to do for RTP data: assume a MTU
of 1280 (IPv6 minimum MTU) and packetize as such, leaving PMTU discovery as
a future optimization.