Re: SCTP mapping to data channels

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.

Received on Friday, 3 February 2012 23:10:50 UTC