Comments from Adam Roach (adam@nostrum.com)

[Bernard_Aboba@…]

The recommendations in the document seem appropriate, and tailored
towards improving the deployability and interoperability of IETF
protocols. I do note, however, that there is very little guidance on a
general topic that is actually causing some amount of dispute in the RAI
area today.

Within the DISPATCH working group, there has been a proposal to extend
the BFCP protocol (defined in RFC 4582) in a way that is fundamentally
incompatible with the base protocol. In particular, the draft
(draft-sandbakken-dispatch-bfcp-udp) proposes to change the transport
from TCP to UDP. To support doing so, it proposes changes to the
transaction model (adding BFCP-level confirmations to make up for the
unreliability of UDP), and potentially adding restrictions on message
size to reduce the chance of IP fragmentation.

While section 2.3 of draft-iab-extension-recs-02 can be read as very
vaguely pointing away from this kind of extension ("[S]pecifications
that look very similar to the original but don't interoperate with each
other or with the original - are even more harmful to interoperability
than extensions"), it appears to be aimed more squarely at the creation
of protocol profiles by SDOs other than the IETF.

At the very least, the current extensions recommendation document (by
casting this issue mostly in the light of inter-SDO coordination) leaves
room for people to argue about whether the IAB intends such guidance to
apply to defining new variations of a protocol aimed predominantly at
changing the underlying transport protocol (which inherently prevents
interoperation with the original protocol).

I would appreciate seeing more explicit guidance from the IAB regarding
the definition of alternate transports for existing protocols, and I
think this document is an ideal vehicle for the IAB to provide this kind
of guidance.

[bernard_aboba@…]

[From Spencer Dawkins]

I would like to support Adam's request for guidance in this area.

I was at the DISPATCH meeting that Adam is referring to (we spent a considerable amount of time switching off at the mike during the meeting).
He describes the situation well, which I would summarize as the proponents of BFCP-over-UDP as saying:

• we did the right thing and used TCP for BFCP ("Basic Floor Control Protocol", RFC 4582 and friends)

• we can't get TCP through NATs without something like TCP-ICE

• we can't wait for TCP-ICE to deploy, because it's stalled in MMUSIC

• we want to use UDP, which we know how to get through NATs

• we can't SWITCH to UDP, because some people are using TCP

• we can't JUST say "be transport-independent", because of concerns about requests/responses that may not fit in a single UDP message without IP-level fragmentation - this, in addition to the usual "need to handle application-level timers, loss detection and retransmission, congestion avoidance, etc." concerns that arise when we use UDP as a transport - the application protocol itself needs to change

• so can we please have two protocols that aren't compatible at the application-protocol level, with the same name (BFCP), that do the same thing?

(As an aside: I haven't spent a lot of time thinking specifically about a BFCP-TCP/BFCP-UDP application-level gateway, but my experience with doing this for other protocols hasn't been positive - I don't believe the BFCP-UDP proponents mentioned this possibility, but if the work had been chartered, that would have been the next topic of discussion, I'd bet. And the discussion mentioned setting a limit on request/response sizes for BFCP-UDP that isn't present in BFCP-TCP, because TCP handles such things transparently - that wouldn't help with application-level gatewaying,
either)

Most of the pushback in the meeting followed two paths: "go to MMUSIC and work on ICE-TCP, so you don't have to do this", and "don't solve the TCP NAT traversal problem for one application protocol - MSRP will have the same problem, and others would, too - use something like Teredo that would handle any application protocol". But this discussion was happening at the "matters of taste" level, without specific guidance from the IAB that either side could reference.

Is there support on the IAB for text that would describe this type of "protocol extension" as "considered harmful"?

[Bernard_Aboba@…]

Here is some proposed text for addition to Section 2.2:

2. Changes to the transport model. While there are circumstances where specification of additional transport protocols may make sense, removal of a widely implemented transport protocol is highly likely to result in interoperability problems and thus should be avoided wherever possible.

Where additional transports are specified, one way to avoid issues
is to mandate support for a single transport protocol, while
designating other transport protocols as optional. However, if
optional transport protocols are introduced due to the unique
advantages they afford in certain scenarios, in those situations
implementations not supporting optional transport protocols may
exhibit degraded performance or may even fail.

While requiring support for multiple transport protocols may
appear attractive, authors need to realistically evaluate the
likelihood that implementers will conform to the requirements.
For example, where resources are limited (such as in embedded
systems), implementers may choose to only support a subset of the
mandated transport protocols, resulting in non-interoperable
protocol variants.