Re: [rtcweb] Last Call: <draft-ietf-rtcweb-data-channel-12.txt> (WebRTC Data Channels) to Proposed Standard

["Wyss, Felix" <[e-mail]>]

> > I now see a tradeoff between allowing such non-mapping boxes
> > (operating below the SCTP layer but above the DTLS layer in our model)
> > and avoiding additional complexity (either extending DCEP with glare
> > resolution - something it was designed to avoid needing - or requiring
> > such boxes to not use actpass).
> 
> I'll note that not only does it have to sit between the SCTP and DTLS layers,
> but also it has to be the offerer to both sides as well. 

This is a problem even if the middlebox is the answerer on one side and the offerer on the other (relay).  As offerer it cannot control what role it will play without violating RFC#5763.  As Indicated in my response to Harald from the 15th, I do not believe allowing the offerer to offer anything but actpass to be a desirable approach.  


> While certainly there are some use-cases for that, it's by no means the common case.  
> WebRTC applications designed to work with such a midpoint may need to fall back on
> "external" negotiation, perhaps running a short sequence at opening time to
> decide who will get even and odd (assuming that both sides actually open
> channels dynamically).
> It means you may not be able to drop such a middlebox (and have it initiate
> offers to both sides) without a cooperative application (or one known to
> have a compatible usage patter) - but likely you need some level of known
> compatibility anyways, or more likely the entity deploying the middlebox also
> deploys or chooses the application - especially as we've explicitly said that
> signaling protocols and transmission (i.e. sending the offer, etc) is explicitly
> not defined by the WG, so the middlebox, in order to generate the offers to
> both sides
> *must* be in bed somehow with the applications - at least to where they all
> agree on signaling.

Well, then why not leave the ID generation and conflict resolution completely up to the application?   That takes the DTLS role hack out of the picture too.  Of course, leaving it to the application how it determines the ID risks that poorly written applications just pick it at random or some other criteria and don't worry about collisions ("well, it worked in my tests").  


> > I agree that the DTLS hack is ugly. But glare resolution is ugly too.
> 
> Quite so.  We had glare resolution in earlier versions. It sucked and caused
> lots of problems, especially with 0-rtt opens.
> 
> While DTLS role isn't wonderful, neither was anything else proposed.
> Offerer/answerer status has the same problem.  

Even the offerer/answerer role would be better than the DTLS role.  At least that would work in the case where the middlebox relays the offer and answer.  I think that's still too limiting as I'd rather allow the middlebox to be offerer on both sides, but I'll take it over the DTLS hack any day :-)


> An SDP parameter would
> allow a middlebox to specify to the endpoints compatible (complementary)
> values; however from a DataChannels perspective, this is almost the same as
> external negotiation if the middlebox and applications are 'matched'.

If in-band negotiation and collision resolution is not an option, adding an SDP attribute would be my second choice.  If it's not present, use offerer/answerer role. 


Thanks,
--Felix