On 28 July 2010 17:45, <[email protected]> wrote: > On Wednesday, July 28 2010, "Joerg Ott" wrote to "Jukka Manner, > [email protected]" saying: > >> this should be the preferred approach rather than doing a special >> version of every application protocol to also run over UDP -- which >> would just be calling for trouble, IMHO. > > Do you mean specifically GUT, or generally something that allows tunneling > of TCP over UDP? Other options in that space would be some sort of > peer-to-peer Teredo, or draft-baset-tsvwg-tcp-over-udp. Each of these makes > different choices about the tradeoff between generality and overhead, and > it's not clear to me which would be the best option for this functionality. > > The concern for BFCP specifically is that these ideas are all currently, at > best, individual author drafts, which would need not only to be standardized > but also to have documents written defining their use in SDP <proto> fields > and ICE candidate addresses. > > Given how long this discussion has been going on already, I don't think > anyone imagines this would be a quick process. The community that uses BFCP > is running into problems with peer-to-peer TCP communication in their > currently deployed networks, and the feeling among much of this community is > that progressing draft-sandbakken-xcon-bfcp-udp would be a much more > expedious process than getting consensus on a generic TCP-over-UDP > mechanism.
I completely agree with the argumentation and view here. More vendors now see the need for a solution to allow BFCP work in important, indeed real scenarios. I had nothing to add when Lennox wrote this late in July. We have just submitted a new version of the draft in question, with amongst other things an expanded argumentation for the approach chosen - this is in-line with what Lennox has written here. > That said, I agree that having a general mechanism would be greatly > preferable, and going forward we'd be much better off if we starting having > serious discussions of this mechanism rather than having to revisit this > problem for all the protocols that come along in the future. (And if it > does manage to progress quickly, but BFCP-over-UDP bogs down or runs into > trouble, the question of how to transmit BFCP could be revisited.) I agree. A general solution to the problem at hand is the preferred solution, this way the IETF policy and recommendations in for instance RFC5404 will be easier to follow for the different (future) protocols also facing problems with nasty NATs and other middleboxes out there. The announcement of the new draft as sent to Dispatch: --- On 2 September 2010 16:45, <[email protected]> wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : Revision of the Binary Floor Control Protocol > > (BFCP) for use over an unreliable transport > > Author(s) : M. Thompson, et al. > > Filename : draft-sandbakken-dispatch-bfcp-udp-00.txt > > Pages : 27 > > Date : 2010-09-02 > > > > This memo extends the Binary Floor Control Protocol (BFCP) for use > > over an unreliable transport. It details a set of revisions to the > > protocol definition document and the specification of Session > > Description Protocol (SDP) format for BFCP streams. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-sandbakken-dispatch-bfcp-udp-00.txt This is an updated version of draft-sandbakken-xcon-bfcp-udp-02 and due to XCON closing soon, we have changed name and reset the version count when submitting and associating the draft with Dispatch. An overview of the changes is listed in the draft: http://tools.ietf.org/html/draft-sandbakken-dispatch-bfcp-udp-00#appendix-A.1 Notable changes: - Most of the discussion so far - in XCON and on the TSV area list - has dealt with the extension to use UDP as transport, therefore the motivation for this approach is expanded. - How congestion control is done is explained explicitly in the text. - DTLS usage is mandated. Still remaining work on details and adaption to BFCP. - The Transaction ID syntax and semantics are not changed, used one of the reserved bits for the Transaction Identifier. Comments and feedback are most welcome. --- Cheers, -- Tom -- # TANDBERG, now part of Cisco ## http://www.tandberg.com ### http://folk.uio.no/tomkri/
