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
_______________________________________________
XCON mailing list
XCON at ietf.org
https://www.ietf.org/mailman/listinfo/xcon
