Re: [XCON] BFCP over UDP

[<Markus.Isomaki at nokia.com>]

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: xcon-bounces at ietf.org [mailto:xcon-bounces at ietf.org] On 
>Behalf Of ext Gonzalo Camarillo
>Sent: 09 April, 2009 08:56
>To: XCON
>Cc: xcon-chairs at tools.ietf.org
>Subject: [XCON] BFCP over UDP
>
>Hi,
>
>the following (expired) draft was presented in the XCON session in San
>Francisco:
>
>http://www.watersprings.org/pub/id/draft-sandbakken-xcon-bfcp-u
>dp-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
>_______________________________________________
>XCON mailing list
>XCON at ietf.org
>https://www.ietf.org/mailman/listinfo/xcon
>