Subject: Re: [dispatch] I-D Action:draft-sandbakken-dispatch-bfcp-udp-01.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 04 Nov 2010 09:51:00 +0200

Hi,

given that this draft will be presented in Beijing, it would be great to
have some list discussions before the presentation. The main requirement
relates to deployments where the floor control server is behind a NAT. I
would like to see discussions on the main alternative approaches to
address those deployments. The talks on specifying a general TCP over
UDP tunneling solution in the transport area did not go anywhere. It has
also been proposed to use ICE TCP or even Teredo. The draft below
proposes to define a BFCP-specific UDP-based transport.

Comments?

Thanks,

Gonzalo

On 27/10/2010 12:30 AM, Tom Kristensen wrote:
> On 25 October 2010 23:45,  <[email-masked]> 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)       : T. Kristensen, et al.
>>        Filename        : draft-sandbakken-dispatch-bfcp-udp-01.txt
>>        Pages           : 26
>>        Date            : 2010-10-25
>>
>> 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://tools.ietf.org/html/draft-sandbakken-dispatch-bfcp-udp-01
> 
> We managed to submit this version before the IETF-79 great
> wall surrounded the draft submission tool yesterday. This is
> the basis for the planned UDP/BFCP presentation/discussion
> at the Dispatch meeting in Beijing:
>   http://tools.ietf.org/wg/dispatch/agenda
> 
> Changes from -00:
>   http://tools.ietf.org/html/draft-sandbakken-dispatch-bfcp-udp-01#appendix-A
> 
> Most notable changes:
> - Removed the - too verbose and not directly related - rationale/
>   motivation text describing background and why other approaches
>   where not chosen. Focus on the actual extensions.
> - Not mandate ICE as a SHALL, but leave it as a non-mandatory
>   way of solving the potential need for NAT/FW traversal.
> - Emphasized that the reference to DTLS-SRTP are merely
>   informational.
> - Decision made to not increase the protocol version number as
>   a result of this extension.
> 
> -- Tom
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 4 Nov 2010 16:17:06 -0400

OK, you asked for comments...

I know very little about BFCP, but I scanned this draft and I have a couple simple questions:

1) Since the problem you're trying to solve is NAT traversal (I think?), then the reason it wouldn't work for TCP is when the BFCP server is behind a NAT, right?  Is that a normal thing?

2) If NAT traversal is the problem, the UDP packets have to start from inside the NAT to the public side, regardless of who called whom.  I don't know BFCP, but I thought the SDP for it used the setup attribute for the TCP initiation indication.  Middleboxes would fiddle with that to force the device behind the NAT to initiate the TCP connection.  Without that, what's gonna make the BFCP device behind the NAT send a BFCP UDP message first? (for example, for RTP middleboxes fiddle with the direction attribute, and for SIP they rely on a REGISTER or OPTIONS coming out of the client to open that pinhole)

3) As I recall, BFCP has a URI attribute which encodes a contact address.  I don't think I've ever seen it used (nor do I understand what it does), but if you're gonna run BFCP through NATs, then you should probably put some text indicating how to use that field (or not to use it), since it's address will invariably be wrong. (and I strongly suggest you get rid of it if you can - protocols putting addresses inside themselves is a major pain, and will only get worse with NAT46/NAT64/NAT44/etc.)

-hadriel

---

From: Peter Musgrave <[email-masked]>
Date: Fri, 5 Nov 2010 05:40:33 +0800

Hi all, 

I probably know less about BFCP than Hadriel - but here goes:

1) This is a problem which needs to be solved. At a recent SIPIT I observed a number SBC of vendors did not proxy TCP at all - so BFCP just plain breaks. (Companies starting with "A" as usual did an excellent job)

2) The text in this draft has examples! Thank you! (We tried to implement BFCP using RFC4582 and the lack of examples made it very hard to get going. We ended up relying on packet sniffs to see how the protocol was actually used). 

3) If adopted will this become a straight BIS on 4582? I find the "interspersing this text in 4582" very tough to read - especially since I am not an expert on BFCP. 

4) I do think an explicit section on NAT traversal would be of benefit. This would make clear the answers to the points Hadriel raised.

Regards, 

Peter Musgrave

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 4 Nov 2010 15:30:25 -0700

As a NAT traversal consideration, I am thinking it may be worth
recommending use of symmetric ports for sending and receiving BFCP
packets, as recommended for RTP/RTCP in RFC 4961.

Cheers,
Charles 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Peter Musgrave
> Sent: Thursday, November 04, 2010 2:41 PM
> To: Hadriel Kaplan
> Cc: DISPATCH list; Tom Kristensen
> Subject: Re: [dispatch] I-D
Action:draft-sandbakken-dispatch-bfcp-udp-01.txt
> 1) This is a problem which needs to be solved. At a recent SIPIT I
observed a number SBC of vendors
> did not proxy TCP at all - so BFCP just plain breaks. (Companies
starting with "A" as usual did an
> excellent job)
> 
> 2) The text in this draft has examples! Thank you! (We tried to
implement BFCP using RFC4582 and the
> lack of examples made it very hard to get going. We ended up relying
on packet sniffs to see how the
> protocol was actually used).
> 
> 3) If adopted will this become a straight BIS on 4582? I find the
"interspersing this text in 4582"
> very tough to read - especially since I am not an expert on BFCP.
> 
> 4) I do think an explicit section on NAT traversal would be of
benefit. This would make clear the
> answers to the points Hadriel raised.
> 
> Regards,
> 
> Peter Musgrave
> 
> 
> > 1) Since the problem you're trying to solve is NAT traversal (I
think?), then the reason it wouldn't
> work for TCP is when the BFCP server is behind a NAT, right?  Is that
a normal thing?
> >
> > 2) If NAT traversal is the problem, the UDP packets have to start
from inside the NAT to the public
> side, regardless of who called whom.  I don't know BFCP, but I thought
the SDP for it used the setup
> attribute for the TCP initiation indication.  Middleboxes would fiddle
with that to force the device
> behind the NAT to initiate the TCP connection.  Without that, what's
gonna make the BFCP device behind
> the NAT send a BFCP UDP message first? (for example, for RTP
middleboxes fiddle with the direction
> attribute, and for SIP they rely on a REGISTER or OPTIONS coming out
of the client to open that
> pinhole)
> >
> > 3) As I recall, BFCP has a URI attribute which encodes a contact
address.  I don't think I've ever
> seen it used (nor do I understand what it does), but if you're gonna
run BFCP through NATs, then you
> should probably put some text indicating how to use that field (or not
to use it), since it's address
> will invariably be wrong. (and I strongly suggest you get rid of it if
you can - protocols putting
> addresses inside themselves is a major pain, and will only get worse
with NAT46/NAT64/NAT44/etc.)

---

From: Peter Musgrave <[email-masked]>
Date: Fri, 5 Nov 2010 06:34:22 +0800

I concur. 

Peter

---

From: Tom Kristensen <[email-masked]>
Date: Fri, 05 Nov 2010 14:43:10 +0100

Great, comments are good!

- Regarding 1)
What a "normal thing" is depends, of course, but in commonly used 
videoconferencing scenarios the BFCP server role is indeed assigned to a 
system behind a NAT.

A clarification on the term "BFCP server" first. In some scenarios a 
BFCP server is a separate entity, doing kind of 3rd party floor control 
for a conference. In this case the BFCP FCS (Floor Control Server) role 
is statically assigned to this entity.

In other scenarios the FCS role is dynamically negotiated in an SDP 
offer/answer exchange. This is the case in normal (!) videoconferencing 
calls where an endpoint (or MCU) participating in the conference will 
perform the FCS role to control the presentation/duo video channel. Note 
that BFCP is used this way in both point-to-point and 
point-to-multipoint calls. The FCS may very well be placed behind a NAT, 
communicating with another system that may or may not be placed between 
a NAT as well.

- Regarding 2)
For TCP (and the proposed usage of DTLS) the setup attribute is used for 
negotiating and indicating who will initiate the connection setup.

The clients will announce their presence by issuing a Hello message to 
the FCS.

I can imagine middleboxes will perform their black magic, but this draft 
makes no assumptions or requirements on what these boxes may, should or 
will do - to put it that way. :-)

- Regarding 3)
Right. The USER-URI BFCP attribute contains the user's contact URI, e.g. 
the SIP URI of the system. A recommendation on it's usage with NATs 
involved and if an IP address is part of this URI seems appropriate.

However, we're not currently using the USER-URI in our BFCP stack so 
others might have an opinion on the destiny of this BFCP attribute.

Thanks for comments and questions,
-- Tom

---

From: Tom Kristensen <[email-masked]>
Date: Fri, 05 Nov 2010 14:53:26 +0100

Agreeing that this is a problem which need to be solved ASAP, as current 
deployments meets the problem to be solved today. The UDP/BFCP approach 
means the BFCP traffic is able to follow the same path, utilizing the 
same infrastructure as successfully used by RTP in these deployments.

Examples are good, even though they are not normative and only selected 
use cases will be part of the specificatoin.

The text of this draft is for sure hard to read, as the intention was to 
make the merge into RFC4582bis and RFC4583bis drafts easy. My hope is 
for this approach to be accepted by Dispatch, making the -bis drafts 
easier to read and understand.

I'm not sure that adding details on all kinds of NAT traversal scenarios 
(and approaches) are needed in this draft. The ICE/STUN associated work 
should be sufficient, given that the specific mechanisms for BFCP are 
put into this draft.

-- Tom

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 5 Nov 2010 10:31:23 -0400

> will do - to put it that way. :-)

There is no "magic" one can do if the BFCP server behind the NAT doesn't send out a BFCP message over UDP _before_ it receives one.  The whole "trick" is to get the device behind the NAT to send a packet out _first_, both to open the pinhole and to learn what ip/port the NAT assigned for the binding.  So to make this work we need some way to make the BFCP server send out a BFCP message before receiving a Hello. (some type of no-op or STUN message, for example)

Ironically, with TCP there are "tricks" one can do to make BFCP/TCP work through NATs. (namely by making the setup attribute tell the server to initiate the TCP connection)

-hadriel

---

From: Tom Kristensen <[email-masked]>
Date: Fri, 05 Nov 2010 15:46:19 +0100

> There is no "magic" one can do if the BFCP server behind the NAT doesn't send out a BFCP message over UDP _before_ it receives one.  The whole "trick" is to get the device behind the NAT to send a…

Ah, I misunderstood your initial comment. You are right. In the first 
version of the draft and our implementation we advocated both FP (Floor 
Participant/client) and FCS sending Hello messages regularly (every 1 
second, if I remember correctly) initially and until an HelloAck message 
was received. Then the FCS would stop sending Hello messages, but the FP 
used Hello as keep-alive.

However, this is now deprecated and STUN is recommended for keep-alive 
if needed.

> Ironically, with TCP there are "tricks" one can do to make BFCP/TCP work through NATs. (namely by making the setup attribute tell the server to initiate the TCP connection)

OK, but in cases where TCP is not proxied by some sort of middleboxes 
this will not apply.

-- Tom

---

From: Adam Roach <[email-masked]>
Date: Sat, 06 Nov 2010 17:44:02 +0800

On 11/5/10 10:46 PM, Tom Kristensen wrote:
>> Ironically, with TCP there are "tricks" one can do to make BFCP/TCP 
>> work through NATs. (namely by making the setup attribute tell the 
>> server to initiate the TCP connection)
>

Actually, it can. See section 4.2 of RFC 5382.

/a

---

From: "Roni Even" <[email-masked]>
Date: Sat, 6 Nov 2010 16:38:56 +0200

Hi,
I know this is a real problem in video conferencing when there is no BFCP
server and one of the terminals or an MCU is the BFCP server. There is
application usage for giving the right to send a presentation to one of the
parties in the call. The bfcp channel in this case has the same end to end
connection as the media itself and this works fine for UDP but have problems
for TCP.  
This is an important draft and I fully support this work
Roni Even 

> Behalf Of Gonzalo Camarillo
> Sent: Thursday, November 04, 2010 9:51 AM
> To: Tom Kristensen; DISPATCH list
> Cc: Tom Kristensen
> Subject: Re: [dispatch] I-D Action:draft-sandbakken-dispatch-bfcp-udp-
> 01.txt
> 
> Hi,
> 
> >>        Title           : Revision of the Binary Floor Control
> Protocol (BFCP) for use over an unreliable transport

---

From: Tom Kristensen <[email-masked]>
Date: Sun, 07 Nov 2010 15:38:19 +0100

> Actually, it can. See section 4.2 of RFC 5382.

Indeed, thus the 'OK' above for Hadriel's NAT traversal case.

However, I used the term 'middlebox' - not NAT - deliberately in my 
sentence. Consider for instance an RTP proxy/media relay, where the TCP 
"trick" most likely is not interesting as chances are huge TCP proxying 
simply is not supported.

For another instance of the term 'middlebox', Peter Musgrave wrote in 
this thread that he observed at a recent SIPit the fact that a number of 
SBC vendors did not proxy TCP at all.

-- Tom

---

From: Tom Kristensen <[email-masked]>
Date: Sun, 7 Nov 2010 15:53:29 +0100

Agree. Not sure to what extent we need to detail the NAT traversal
issues and scenarios in this draft, referring existing work is
hopefully sufficient. Recommending use of symmetric ports should be
fine.

>From what I understand using symmetric ports this way is beneficial
when using DTLS as well, to limit the number of DTLS
connections/associatons. We'll make a note of RFC4961 when the DTLS
details needed in the draft are done (as soon as possible after
IETF-79).

-- Tom

-- 
# Cisco                         |  http://www.cisco.com/telepresence/
## [email-masked]  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/

---

From: <[email-masked]>
Date: Sun, 7 Nov 2010 16:09:17 +0100

Hi,

I can't comment on how relevant the use case of the BFCP server behind a NAT is, but if you want to make it work, I believe UDP as the transport and this draft is the way to go. The other option would be to rely on either comedia rewriting at the SBCs or ICE-TCP with TURN-TCP, but that would require some infrastructure support, and I believe solutions that don't rely on that have generally a better chance at succeeding. Especially as there is no clarity on if either of those TCP-based options would become generally supported in any timeframe.

The main worry I usually have with UDP and NATs is the short timeouts and thus the need for frequent keepalives. That tends to be bad for long-lasting sessions with long (application/user) idle periods, but I suppose in this case the usage is associated with an ongoing video call, that will anyway generate a lot of traffic.

Markus 

>Behalf Of ext Gonzalo Camarillo
>Sent: 04 November, 2010 09:51

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 7 Nov 2010 19:50:18 -0500

> SBC vendors did not proxy TCP at all.

I am dumbfounded that you're finding support for TCP media relay to be so lacking.
I'm surprised because the SBC space is competitive and everyone tries to out-do the next guy, so I would have figured this would be table stakes by now.  :( 

The problem with this slippery slope is: what makes you think that such SBCs, firewall ALGs, or various B2BUA's inside the providers/enterprises can handle the SDP having even a new draft's BFCP over UDP syntax?  I mean you're basically arguing that you can't depend on middleboxes to be upgraded to support BFCP.  So why would they be upgraded to understand BFCP/UDP?

In other words, shouldn't you literally make the SDP something like:
m=audio 12345 RTP/AVP 100
a=rtpmap:100 BFCP/8000

-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 8 Nov 2010 05:55:15 +0100

I agree we need a solution that works when the BFCP server is behind a NAT, and in particular where it is collocated with one of the sources/sinks of audio/video. That solution needs to be compatible with as many existing middleboxes as possible. I don't have a strong opinion on what that solution should be.

John 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 08 November 2010 00:50
> To: Tom Kristensen
> I'm surprised because the SBC space is competitive and 
> everyone tries to out-do the next guy, so I would have 
> figured this would be table stakes by now.  :( 
> 
> The problem with this slippery slope is: what makes you think 
> that such SBCs, firewall ALGs, or various B2BUA's inside the 
> providers/enterprises can handle the SDP having even a new 
> draft's BFCP over UDP syntax?  I mean you're basically 
> arguing that you can't depend on middleboxes to be upgraded 
> to support BFCP.  So why would they be upgraded to understand 
> BFCP/UDP?
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 08 Nov 2010 13:32:01 +0800

I agree with John that this is a problem that needs solving. I've also 
seen that having two ways of doing a protocol is effectively the same as 
having two non-interoperable protocols. And that's just not a sound 
technical decision.

Rather than coming up with a protocol-specific solution, I think it 
would make a lot more sense to put our effort into completing the newly 
reinvigorated ICE-TCP work, which solves this problem every bit as well 
as coming up with an incompatible profile of BFCP.

The brilliant part of that approach is that it solves it not just for 
BFCP, but for every peer-to-peer TCP protocol. Well, that and the fact 
that it remains compatible with BFCP as specified.

/a

---

From: Tom Kristensen <[email-masked]>
Date: Tue, 09 Nov 2010 09:59:45 +0100

Markus, I totally agree!

And as you say, the keepalive traffic for the BFCP stream is next to 
nothing compared to an associated 1080p60 video stream (in addition to 
128 kbit/s for audio and a potentially active high-resolution 
presentation video stream).

-- Tom

On 11/07/2010 04:09 PM, [email-masked] wrote:
>>> On 25 October 2010 23:45,<[email-masked]>  wrote: