- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Mon, 30 Jan 2012 08:28:03 +0100
- To: Justin Uberti <juberti@google.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 01/30/2012 02:32 AM, Justin Uberti wrote:
>
>
> On Fri, Jan 27, 2012 at 3:58 AM, Stefan Hakansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
> On 01/27/2012 05:21 AM, Justin Uberti wrote:
>
>
>
> On Thu, Jan 26, 2012 at 5:25 PM, Randell Jesup
> <randell-ietf@jesup.org <mailto:randell-ietf@jesup.org>
> <mailto:randell-ietf@jesup.org
> <mailto:randell-ietf@jesup.org>__>> wrote:
>
> On 1/26/2012 6:41 AM, Stefan Hakansson LK wrote:
>
> On 01/26/2012 02:59 PM, Harald Alvestrand wrote:
>
> I believe this fails on one of the listed
> requirements in
> draft-jesup (I
> note that you listed the use cases, but did not
> include the
> requirements
> that Randell inferred from these use cases):
>
>
> Yes, I did list the use-cases but not the requirements,
> mainly
> because I
> could not really go from the use cases and derive (many
> of) the
> requirements. The ones below, possibly with the exception of
> Req. 2, are
> among those that I could not really derive from the use
> cases.
>
>
> Req. 1 Multiple simultaneous datagram streams must
> be supported.
>
>
> I should note that for games, having multiple streams with
> different
> characteristics is a huge plus. Going *all* the way back to
> netrek
> (you can look it up on wikipedia), networked games have used
> multiple streams. Netrek used a reliable stream for
> critical state
> info ("you're dead"), and unreliable datagrams for general
> world-state updates ("opponent 3's position is x,y"). One
> of the
> reasons for providing the multiple channels is that if we don't,
> application makers who need them will create their own
> protocol on
> top of whatever we provide. If we provide reliable only,
> that fails
> a lot of real-time needs, and if we provide unreliable only
> they'll
> build reliable on top of it - badly, and incompatibly.
>
>
> Multi-user scenarios will almost certainly need multiple
> simultaneous
> streams, i.e. at least one for each participant. Of course, you
> could
> get away with having a single stream and just muxing everything over
> that stream using an application-defined protocol, but it's probably
> best for interoperability if we officially support this scenario.
>
>
> I assume that you're talking about multi-user with a central server,
> otherwise there would be a separate PeerConnection to each user.
>
> With the "Alternative Data API" muxing of DOMString data is
> straightforward (to do in the application); blobs and ArrayBuffers
> is another story. There ChannelMessaging should be possible to use
> to create channels, but I've not looked into the details (and am
> unsure about the maturity of ChannelMessaging).
>
>
> It's multi-user that is not full mesh, but it might not involve a
> central server (e.g. a directed p2p graph).
>
> If all the elements in the graph are aware of the application protocol,
> this would certainly work, even with ArrayBuffers. The app could create
> its own packet format, and use that to create its own multiplexing
> mechanism, and even its own reliability and priority mechanism (it would
> of course have to depend on the PeerConnection's congestion control
> mechanism).
>
> This might allow us to make the in-browser code substantially simpler,
> as it would just be a secure pipe for generic datagrams at this point.
> All the advanced stuff would be done through JS libraries.
>
> I think this is a important point for the WG to consider. Would folks
> rather have a simpler, less capable API that we can ship sooner?
>
> I admit that doing SCTP or PseudoTCP in Javascript sounds interesting.
I must admit I never thought that far. My idea was more to have a simple
API (much aligned to WebSockets) for a start, and then add functionality
if needed (with e.g. the options argument); but having SCTP as the
underlying transport.
I think that also with the simple start API you can get a lot of
functionality by combining it with other tools in the web platform (and
the app can perhaps prioritize between its own data).
But I think your question (i.e. doing protocol in JS) is valid indeed.
>
>
>
>
>
> There is also no support for:
>
> Req. 2 Both reliable and unreliable datagram streams
> must be
> supported.
>
> Req. 4 The application should be able to provide
> guidance as
> to the
> relative priority of each datagram stream relative
> to each
> other,
> and relative to the media streams.
>
>
> This ties back to the congestion control issues. The data
> channel
> must be congestion controlled, and depending on the use case
> one or
> the other may want priority for bits on the wire.
>
>
> While these COULD be done with the suggestion of "add
> options" under
> "future extensions", I think this seems like a clear and present
> requirement.
>
> A number of the other requirements aren't really
> relevant to
> the API,
> being more protocol related, but these 3 seem to be
> impossible to
> satisfy without corresponding API functionality.
>
>
> I agree. I think 2 and 4 are very straightforward to
> fulfill, and 1
> needing some more work - but then again there has been
> little
> evidence
> of the need, and my input was more on offering a "do
> less now, add
> things if there is need" approach.
>
>
> Well, from the JS API end that might be the case, but from
> the IETF
> bits-on-the-wire side, we need to define the protocol, and
> it's hard
> to upgrade those later without major backwards-compatibility
> pain.
> So, even if we used a single-channel api to start, we'd want a
> multi-channel-compatible wire protocol underneath it - and
> it would
> be hard to test that.
>
>
>
>
> I believe embedding a single-channel data function into
> PeerConnection
> (and therefore encouraging the deployment of
> single-channel-assuming
> applications) would make it harder to satisfy this
> requirement set later.
>
>
> Why? I can't see that that the fact that there are
> single-channel-assuming applications deployed would stop
> adding e.g.
> multiple-channel support later (as long as the
> single-channel API
> continues to work) if there are use cases demanding that.
>
>
> If you add multi-channel later while keeping single-channel, the
> final interface might be kindof odd/confusing for someone
> coming to
> it cold.
>
>
>
> Again, I'm fine with doing the more advanced approach,
> my input was
> mostly to show that there is an alternative approach
> available
> that is
> simpler (it may for example allow us to define fewer new
> events -
> something that is not introduced everyday), is better
> aligned to
> existing messaging APIs _but_ less capable.
>
> It is up to the group, and as contributor I will do my
> best to
> make the
> selected approach as good as possible (there may on the
> other
> hand be
> very little value in that...)!
>
>
>
>
> --
> Randell Jesup
> randell-ietf@jesup.org <mailto:randell-ietf@jesup.org>
> <mailto:randell-ietf@jesup.org <mailto:randell-ietf@jesup.org>__>
>
>
>
>
>
Received on Monday, 30 January 2012 07:28:37 UTC