Subject: [XCON] BFCP over UDP

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 09 Apr 2009 08:55:57 +0300

Hi,

the following (expired) draft was presented in the XCON session in San 
Francisco:

http://www.watersprings.org/pub/id/draft-sandbakken-xcon-bfcp-udp-00.txt

The agreement was that given the problems TCP has with NATs (the P2PSIP 
WG is currently discussing the same issue) it would be a good idea to 
define a more NAT-friendly transport for BFCP. The proposal was to 
simply use UDP (this is what existing deployments do).

Since BFCP messages can be rather long, we would need an applicability 
statement saying which types of messages cannot be used over UDP.

In order to specify the new UDP-based transport we can either put 
together a new draft or revise the BFCP specification. I got the action 
point to list the things that could be fixed in a potential revised BFCP 
spec. These are the contents of my notes. Of course, if someone knows of 
more issues, please let us know:

o When a user performs a third-party floor request the beneficiary of 
the floor is not informed when the floor is granted. This may not be a 
problem because endpoints using third-party floor requests probably have 
different means to get in synch but we may want to add some text about this.

o We do not have errors for an unsupported version of the protocol or 
for wrong message length. We do not have a general error either.

o When we get more experience on queue management from real deployments, 
it would be nice to explaining it further in the spec.

o UserStatus

UserStatus =   (COMMON-HEADER)
                   [BENEFICIARY-INFORMATION]
                 1*(FLOOR-REQUEST-INFORMATION) -> remove the 1
                  *[EXTENSION-ATTRIBUTE]

o A message may need to be longer than the maximum message length 
supported by the protocol

o A rather small number of typos

As you can see, at this point there are not so many things to fix... so, 
the simplest way forward may be to simply specify a new UDP-based 
transport for BFCP. In any case, I would like to get feedback from folks 
operating BFCP deployments.

A different alternative (the one the P2PSIP WG is looking at) would be 
to either use a UDP encapsulation for TCP or to specify a new transport 
protocol... but these alternatives may be more complex than just using UDP.

Comments?

Thanks,

Gonzalo

---

From: <[email-masked]>
Date: Thu, 9 Apr 2009 10:03:05 +0200

Hi Gonzalo,

The problem with TCP and NATs usually stems from the scenario where both parties who want to communicate are behind a NAT. This is presumably often the case with P2PSIP. However, I've thought that BFCP would be typically deployed in a fashion where the conference focus (or the element managing the floor) would be hosted in a public address. In such a case TCP definitely works much better even if the conference participant would be behind a NAT.

So, does the motivation for BFCP over UDP come from the requirement that the conference focus (the floor "manager") would itself need to be behind a NAT? This might be a valid requirement as such, when we think about endpoint hosted conferences. But even in those cases TCP could still work, if we assume that some infra like TURN-TCP or comedia/TCP aware SBCs (which we have discussed in SIMPLE lately) would be available. Again in P2PSIP the situation is different as they can't assume that kind of infra (the peers themselves need to provide it). So, I'm not sure if BFCP and P2PSIP requirements are identical. Unless you think about BFCP within a P2PSIP deployment.

Sorry, I didn't attend the XCON session in San Francisco, this was probably well covered there.

(I agree that there are many situations where defining how to tunnel/emulate TCP-like transport service over UDP. So, I think the best would be if TSV area could define one single solution and then protocols like P2PSIP, MSRP, BFCP etc. could use it.)

Markus

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Gonzalo Camarillo
>Sent: 09 April, 2009 08:56
>To: XCON
>Cc: [email-masked]
>Subject: [XCON] BFCP over UDP
>
>Hi,
>
>The agreement was that given the problems TCP has with NATs 
>(the P2PSIP WG is currently discussing the same issue) it 
>would be a good idea to define a more NAT-friendly transport 
>for BFCP. The proposal was to simply use UDP (this is what 
>existing deployments do).
>
>Since BFCP messages can be rather long, we would need an 
>applicability statement saying which types of messages cannot 
>be used over UDP.
>
>In order to specify the new UDP-based transport we can either 
>put together a new draft or revise the BFCP specification. I 
>got the action point to list the things that could be fixed in 
>a potential revised BFCP spec. These are the contents of my 
>notes. Of course, if someone knows of more issues, please let us know:
>
>o When a user performs a third-party floor request the 
>beneficiary of the floor is not informed when the floor is 
>granted. This may not be a problem because endpoints using 
>third-party floor requests probably have different means to 
>get in synch but we may want to add some text about this.
>
>o We do not have errors for an unsupported version of the 
>protocol or for wrong message length. We do not have a general 
>error either.
>
>o When we get more experience on queue management from real 
>deployments, it would be nice to explaining it further in the spec.
>
>o UserStatus
>
>o A message may need to be longer than the maximum message 
>length supported by the protocol
>
>As you can see, at this point there are not so many things to 
>fix... so, the simplest way forward may be to simply specify a 
>new UDP-based transport for BFCP. In any case, I would like to 
>get feedback from folks operating BFCP deployments.
>
>A different alternative (the one the P2PSIP WG is looking at) 
>would be to either use a UDP encapsulation for TCP or to 
>specify a new transport protocol... but these alternatives may 
>be more complex than just using UDP.
>
>Comments?
>
>Thanks,
>
>Gonzalo
>_______________________________________________
>XCON mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/xcon
>

---

From: Geir Arne Sandbakken <[email-masked]>
Date: Thu, 16 Apr 2009 12:05:00 +0200

Markus,

The are two main uses cases that lead to the deployment of BFCP over 
UDP. Firstly - as you mention - is when the focus resides behind a NAT. 
Many video conference endpoints can take the role as a focus mixing 
multiple calls. Also, enterprise deployments tend to place the bridges 
behind the corporate NATs. Secondly BFCP is utilized in vanilla p-t-p 
calls for presentation tokens control.

Other motivations are that we want BFCP to work with ICE, and when you 
have taken the cost of setting up a BFCP server, client and possibly a 
turn resource - it is a very tempting to extend it for other uses as well.

Geir Arne

---

From: Geir Arne Sandbakken <[email-masked]>
Date: Thu, 16 Apr 2009 17:33:14 +0200

Gonzalo,

The UDP usage draft does utilize transaction ids more and has a few 
extra messages to get reliable delivery.  The changes are still very 
minor to the protocol itself and our implementation of it. 

IMHO having a single way of operating the protocol is better than having 
two different modes of operation.  Also as mentioned in San Francisco it 
makes any intermediaries easier to implement only having to forward 
messages independent of transport.   Can we do a bis?

Geir Arne

Gonzalo Camarillo wrote:
> The agreement was that given the problems TCP has with NATs (the 
> P2PSIP WG is currently discussing the same issue) it would be a good 
> idea to define a more NAT-friendly transport for BFCP. The proposal 
> was to simply use UDP (this is what existing deployments do).
>
> together a new draft or revise the BFCP specification. I got the 
> action point to list the things that could be fixed in a potential 
> revised BFCP spec. These are the contents of my notes. Of course, if 
> someone knows of more issues, please let us know:
>
> problem because endpoints using third-party floor requests probably 
> have different means to get in synch but we may want to add some text 
> about this.
>
> As you can see, at this point there are not so many things to fix... 
> so, the simplest way forward may be to simply specify a new UDP-based 
> transport for BFCP. In any case, I would like to get feedback from 
> folks operating BFCP deployments.
>
> to either use a UDP encapsulation for TCP or to specify a new 
> transport protocol... but these alternatives may be more complex than 
> just using UDP.
>
> Comments?
>
> Thanks,
>
> Gonzalo