Subject: Re: [rtcweb] SCTP mapping to data channels

From: "Timothy B. Terriberry" <[email-masked]>
Date: Fri, 03 Feb 2012 15:10:24 -0800

Randell Jesup wrote:
> I'm quite open to alternative ideas, and someone could make a case for
> providing a transparent interface to the full set of SCTP functionality.

I'm not going to make such a case, but the comment was made during the 
interim meeting that we don't have use cases and derived requirements 
for all the features we want from the data channel. I've had at least 
one that I've been kicking around in my head as various options for 
handling signaling and channels are discussed, so I would like to 
propose adding it to the use-cases document (cc'ing the IETF list since 
it maintains it):

Simple video communication with peer-to-peer file transfer

This use-case is almost identical to the Simple Video Communication 
Service use-case (Section 4.2.1). The difference is that during the 
session, one user drags a directory containing (potentially thousands 
of) files onto the page, and these are transferred to the other user. 
The user can select a "high priority transfer" option to lower the 
quality of the media in order to speed up the file transfer.

This motivates the desire for a reliable data channel (the user would 
like to receive the entire file), that is peer-to-peer (the web server 
probably doesn't want to pay for all that traffic), doesn't starve the 
media, and whose relative share of the available bandwidth can be 
configured (maybe I'm willing to put up with low framerate video as long 
as the files gets there quickly, maybe I just want the transfer to go in 
the background so you can look at it when we're done talking). I'm open 
to suggestions about how exactly to phrase those as requirements.

It also has implications, which are not requirements, for how the SCTP 
channels are used and APIs around them are constructed. The natural 
(though by no means the only nor the best) way to implement something 
like this would be to open a unidirectional channel for each file, send 
all the data for that file, and then close it and proceed to the next 
file. But this requires that a) the receiving side gets informed of a 
channel opening, b) before it receives any data on it, and c) the 
receiving side gets informed of a channel closing, but d) only after it 
has received all the in-flight data on that channel, and e) channels can 
later be re-used.

a) and c) are needed to delineate the bounds of each file. Because there 
may be many thousands of tiny files, the latency introduced by a) and c) 
should be minimized (most file transfer programs have terrible 
throughput in this case).

b) is required to avoid the need for the app to buffer unknown amounts 
of incoming data before it has any idea what it is or what it's for. d) 
is needed to make sure the app knows when it has all the data for a file 
and can close it. b) and d) may be complicated if the channel open/close 
notifications are done via signaling in the SDP, rather than over the 
SCTP association somehow (though that doesn't mean they're impossible).

e) is necessary because I can (almost certainly) add more files to my 
directory than any pre-set maximum number of channels you pick, though I 
only ever need to use one or two channels simultaneously. It may also 
argue the need for a label that is not the same as the SCTP channel 
number. In this case, something containing the file path from the sender 
might be a particularly useful label.

You could argue that all five of these things could be achieved with a 
single ordered, reliable data channel and a one-off custom protocol. But 
if the webapp needs to resort to that even in this simple case, then I'd 
argue that providing an API for multiple independent channels isn't 
adding much value.

---

From: Stefan Hakansson LK <[email-masked]>
Date: Sat, 4 Feb 2012 15:14:10 +0100

> argue that providing an API for multiple independent channels isn't

If I understand things correctly, each file would be represented by a 
blob object. So with the API Justin has proposed, with the addition of 
the send(blob) (or with the API I proposed as well for that matter), the 
app would just have to send each of those blobs. If the developer sends 
them over one single channel, or opens several parallel is up to 
her/him, but either way there would be no need to open/close, or to in 
any way handle file start/stop - each file would be represented by a 
discrete object, and the app just sends them.

I assume that in this use case the html input element with type file 
(and multiple attribute set) would be used so that the user can select 
the files,

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

---

From: Randell Jesup <[email-masked]>
Date: Sat, 04 Feb 2012 13:47:02 -0500

> discrete object, and the app just sends them.

Are we assuming that the data channel will automatically split up and 
transfer the blob?  And at the reception side, does it plop out as a 
blob at the other end?  (Which implies buffering up the entire file 
before notifying the application it's coming, and removes the chance to 
stream it to disk or to an image element (or video element in some cases)).

I was assuming a blob in this case was an opaque datagram to send to the 
other side, not (necessarily) a complete file object.

> (and multiple attribute set) would be used so that the user can select

Sure, though the interface between that selection and the calls to the 
dataChannel is an open question (and perhaps most reasonable to leave up 
to the application - provide good tools, not pre-packaged solutions).

-- 
Randell Jesup
[email-masked]

---

From: Stefan Hakansson LK <[email-masked]>
Date: Sun, 5 Feb 2012 11:27:42 +0100

On 02/04/2012 07:47 PM, Randell Jesup wrote:
> blob at the other end?

Yes, that is the (from me) expected behavior, in line with e.g. the 
WebSocket API.

> (Which implies buffering up the entire file

It is not necessarily that; but in Tim's use case it was (thousands) of 
files. Blobs can be sliced and so on; refer to the File API spec.

> to the application - provide good tools, not pre-packaged solutions).

I agree, I just wanted to ensure we're talking about the same thing.