Subject: [XCON] WG Adoption? draft-sandbakken-xcon-bfcp-udp-02

From: Tom Kristensen <[email-masked]>
Date: Mon, 07 Jun 2010 15:22:38 +0200

The draft draft-sandbakken-xcon-bfcp-udp-02 was submitted early in
March. No comments received since.

We'd like guidance on the next steps. First we ask for adoption as WG
item. Next step would include the merging process with bis versions of
RFC 4582 and RFC 4583. 

We'd like to point out that interested parties for this work indeed
exist.

(For the record: Questions was sent to XCON chairs in April and May. See
below. No response given. Therefore, this request on the list.)

-- Tom

On Wed, 2010-05-12 at 10:43 +0200, Tom Kristensen wrote:
> Chairs,
> 
> Any thoughts or decision on this matter?
> 
> Cheers,
> -- Tom
> 
> On Tue, 2010-04-20 at 11:58 +0200, Tom Kristensen wrote:
> > XCON chairs,
> > 
> > We submitted draft-sandbakken-xcon-bfcp-udp-02 early in March - well in
> > advance of IETF-77. 
> >    http://tools.ietf.org/html/draft-sandbakken-xcon-bfcp-udp
> > 
> > No comments received. Neither on XCON WG list, nor directly to the
> > authors. Therefore, we ask for adoption of this draft as an XCON WG
> > item.
> > 
> > -- Tom
>

---

From: Alan Johnston <[email-masked]>
Date: Tue, 08 Jun 2010 11:43:30 -0500

Tom,

Apologies for the delay in replying.  As you know, the working group is
in the process of completing its final milestones.  Publication requests
will be issued in the next few days for the data model, CCMP, and the
Examples drafts.

Taking on any new milestones for the working group would require:
1. Strong support and interest from working group participants
2. Approval of our ADs.

I haven't seen evidence of either of these at this stage.

A possible option is to take this work to DISPATCH, get an indication of
interests, and get feedback on the best way to move this work forward.

- Alan -
co-chair XCON

---

From: "Roni Even" <[email-masked]>
Date: Tue, 8 Jun 2010 21:35:05 +0300

Hi Alan,
I support this work and think it is urgent to finish it.
I think that updating BFCP with UDP support is very important. I would like
to mention that BFCP is being used in video conferencing application and
since the implementers encountered problems with TCP they use a fall back to
UDP.
We discussed this work in previous IETF meeting and Gonzalo as far as I
remember suggested to add it to a BFCP bis draft.

Thanks
Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alan Johnston
> Sent: Tuesday, June 08, 2010 7:44 PM
> To: Tom Kristensen
> Cc: Mark Thompson; [email-masked]
> Subject: Re: [XCON] WG Adoption? draft-sandbakken-xcon-bfcp-udp-02
> 
> Tom,
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xcon

---

From: Patrick Luthi <[email-masked]>
Date: Wed, 09 Jun 2010 09:06:50 +0200

Hi Alan,

I support this work too. Videotelephony and videoconferencing 
manufacturers quickly need the solution that this draft is addressing!

I was in the room the last time we discussed this in XCON and my 
understanding was that there was support for the work to move 
forward. I also remember Gonzalo suggesting the addition to a BFCP-bis draft.

Regards,

Patrick

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 9 Jun 2010 13:20:39 +0200

We made an explicit decision in the original draft that UDP was not required, not that we would do it later. That as far as I am concerned represents the current status of consensus.

This was done on the basis that we had all seen how UDP support had complicated SIP, and we did not want to repeat that issue.

So this is not continuing the work. The status is an author draft which goes against a WG consensus position.

I believe Georg Ott also expressed some concerns which I did not see answered on list at all.

regards

Keith 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Roni Even
> Sent: Tuesday, June 08, 2010 7:35 PM
> To: 'Alan Johnston'; 'Tom Kristensen'
> Cc: 'Mark Thompson'; [email-masked]
> I think that updating BFCP with UDP support is very 
> important. I would like to mention that BFCP is being used in 
> video conferencing application and since the implementers 
> encountered problems with TCP they use a fall back to UDP.
> We discussed this work in previous IETF meeting and Gonzalo 
> as far as I remember suggested to add it to a BFCP bis draft.
> 
> Thanks
> Roni Even
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Alan Johnston
> > Apologies for the delay in replying.  As you know, the 
> working group 
> > is in the process of completing its final milestones.  Publication 
> > requests will be issued in the next few days for the data 
> model, CCMP, 
> > and the Examples drafts.
> > 
> > 1. Strong support and interest from working group participants 2. 
> > Approval of our ADs.
> > 
> > A possible option is to take this work to DISPATCH, get an 
> indication 
> > of interests, and get feedback on the best way to move this work 
> > forward.
> > 
> > - Alan -
> > co-chair XCON
> > 
> > 
> > > We'd like guidance on the next steps. First we ask for 
> adoption as 
> > > WG item. Next step would include the merging process with bis 
> > > versions
> > of
> > > RFC 4582 and RFC 4583.
> > >
> > > (For the record: Questions was sent to XCON chairs in 
> April and May.
> > See
> > >>> authors. Therefore, we ask for adoption of this draft 
> as an XCON 
> > >>> WG item.
> > >>>
> > >>> -- Tom
> > >>
> > >
> > >

---

From: Tom Kristensen <[email-masked]>
Date: Wed, 9 Jun 2010 13:37:56 +0200

The UDP/BFCP draft has been presented and discussed in two or three
IETF XCON sessions. No objection to the work being carried on, just
that adoption as WG item was postponed until the draft was more
complete. (This has been delayed of various reasons, but the authors
believe the -02 version in question here should be ready for
adoption).

The "current status of consensus" might be valid for some, but
participants in the XCON sessions and the minutes of meeting show
progress away from that initial consensus.

I believe Ott's concerns are either dealt with or at least mentioned
in the draft. Arrest me if I'm wrong.

-- Tom

-- 
# TANDBERG R&D
## http://www.tandberg.com
### http://folk.uio.no/tomkri/

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Wed, 09 Jun 2010 13:38:29 +0200

Hi

I support this draft, and would like to see support for BFCP over UDP

Best regards,

Alfred E. Heggestad
Telio Telecom AS

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 9 Jun 2010 08:34:16 -0400

Tom and others who are interested in this draft:

For those who are relatively new here: Could you summarize why you  
think this draft is needed?  What requirement does it meet that BFCP  
doesn't right now?

Thanks,
--Richard

On Jun 9, 2010, at 7:37 AM, Tom Kristensen wrote:

>> We made an explicit decision in the original draft that UDP was not  
>> required, not that we would do it later. That as far as I am  
>> concerned represents the current status of consensus.
>>
>> This was done on the basis that we had all seen how UDP support had  
>> complicated SIP, and we did not want to repeat that issue.
>>
>> So this is not continuing the work. The status is an author draft  
>> which goes against a WG consensus position.
>>

---

From: "Roni Even" <[email-masked]>
Date: Wed, 9 Jun 2010 15:39:40 +0300

Richard,
The BFCP I used as a presentation token for video conferencing. What the
implementers found out that TCP does not work in real networks due to
Session border controllers not supporting TCP as used in BFCP. 
This is why in products they try to establish TCP connection and if fails
tries UDP.
The video conferencing vendors participating in the IMTC sip parity activity
group defined an interoperability profile that references this option
Roni Even 

> Richard L. Barnes
> Sent: Wednesday, June 09, 2010 3:34 PM
> To: Tom Kristensen
> Cc: Mark Thompson; DRAGE, Keith (Keith); Alan Johnston; Tom Kristensen;
> [email-masked]

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 9 Jun 2010 08:51:30 -0400

Thanks for the quick reply, Roni.

What do you mean by "TCP as used in BFCP"?  Is the issue:
-- SBCs don't let any TCP through at all?
-- SBCs don't support the SDP options for BFCP? (thus don't open ports?)
-- SBCs are doing DPI and don't let through TCP traffic containing BFCP?
-- Something else?

On Jun 9, 2010, at 8:39 AM, Roni Even wrote:

>> Behalf Of
>>>>>>>>> We submitted draft-sandbakken-xcon-bfcp-udp-02 early in  
>>>>>>>>> March -
>>>>>> well in
>>>>>>>>> advance of IETF-77.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 10 Jun 2010 00:54:02 +0200

What you are essentially saying is that all protocols in the future that need reliable transport, as BFCP does, have to design in their own reliable transport element so they can use UDP. This is not a BFCP specific issue.

I find that an unacceptable direction for IETF to be heading in. 

I would also note that you are also asking for adoption of a document that cannot in its current form meet the security requirements of the original RFC.

regards

Keith

> From: Roni Even [mailto:[email-masked]] 
> Sent: Wednesday, June 09, 2010 1:40 PM
> To: 'Richard L. Barnes'; 'Tom Kristensen'
> Cc: 'Mark Thompson'; DRAGE, Keith (Keith); 'Alan Johnston'; 
> 'Tom Kristensen'; [email-masked]
> Subject: RE: [XCON] WG Adoption? draft-sandbakken-xcon-bfcp-udp-02
> 
> Richard,
> The BFCP I used as a presentation token for video 
> conferencing. What the implementers found out that TCP does 
> not work in real networks due to Session border controllers 
> not supporting TCP as used in BFCP. 
> This is why in products they try to establish TCP connection 
> and if fails tries UDP.
> The video conferencing vendors participating in the IMTC sip 
> parity activity group defined an interoperability profile 
> that references this option Roni Even 
> 
> > Of Richard L. Barnes
> > Cc: Mark Thompson; DRAGE, Keith (Keith); Alan Johnston; Tom 
> > Kristensen; [email-masked]
> important. I 
> > >>> would like to mention that BFCP is being used in video 
> > >>> conferencing application and since the implementers encountered 
> > >>> problems with TCP they use a fall back to UDP.
> > >>> We discussed this work in previous IETF meeting and 
> Gonzalo as far 
> > >>> as I remember suggested to add it to a BFCP bis draft.
> > >>>
> > >>> Thanks
> > >>> Roni Even
> > >>>
> > >>>> is in the process of completing its final milestones.  
> > >>>> Publication requests will be issued in the next few 
> days for the 
> > >>>> data
> > >>> model, CCMP,
> > >>>> and the Examples drafts.
> > >>>>
> > >>>>>>> We submitted draft-sandbakken-xcon-bfcp-udp-02 
> early in March 
> > >>>>>>> -
> > >>>> well in
> > >>>>>>> advance of IETF-77.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 10 Jun 2010 01:03:00 +0200

You say:

> The UDP/BFCP draft has been presented and discussed in two or 
> three IETF XCON sessions. No objection to the work being 
> carried on, just that adoption as WG item was postponed until 
> the draft was more complete. (This has been delayed of 
> various reasons, but the authors believe the -02 version in 
> question here should be ready for adoption).
> 

Aside from this being at total variance to my understanding of WG adoption this is the previous history according to the minutes.

IETF #77

XCON did not meet.

IETF #76

3. BFCP over UDP
  draft-sandbakken-xcon-bfcp-udp
Alan Johnston presented an update on this document on behalf of Tom Kristensen.  Several commenters pointed out that the current draft still has many problems that had been called out at previous meetings, The draft will not be taken up by the WG at this time.

IETF#75

No discussion in meeting

IETF#74

4. Geir Arne Sandbakken: BFCP over UDP
-- Trouble getting BFCP/TCP through RTP relays for NAT traversal
   => Translated BFCP to UDP
-- Now works with ICE, IMTC considering adopting BFCP
-- Open issues: Dynamic message sizes, security considerations
-- Adam: Not going to ask for adoption now, but wanted to present it
   -- People please read through this
-- Roni: Work is going on in IMTC because companies are meeting and working.  This work is important.
-- Elwell: This is important, especially since TURN-TCP isn't done
-- Cullen: If we limited message sizes, would it still be useful?
   -- If so, then that would be much easier than fragmenting
   -- Geir Arne: Biggest packets seem to be 40bytes
   -- Gonzalo: BFCP messages can get big, I will help with this doc
-- Lorenzo: There are packet size limitations in TCP too
-- Lorenzo: Have you considered UDP/TCP gateways?
-- Gonzalo: You would have problems with that.
-- Gonzalo: There's a scope question; do we want to do BFCP bugfixes too?

IETF#73

No discussion in meeting

IETF#72

No discussion in meeting

IETF#71

No discussion in meeting

regards

Keith

> From: Tom Kristensen [mailto:[email-masked]] 
> Sent: Wednesday, June 09, 2010 12:38 PM
> To: DRAGE, Keith (Keith)
> Cc: Roni Even; Alan Johnston; Tom Kristensen; Mark Thompson; 
> [email-masked]
> The UDP/BFCP draft has been presented and discussed in two or 
> three IETF XCON sessions. No objection to the work being 
> carried on, just that adoption as WG item was postponed until 
> the draft was more complete. (This has been delayed of 
> various reasons, but the authors believe the -02 version in 
> question here should be ready for adoption).
> 
> The "current status of consensus" might be valid for some, 
> but participants in the XCON sessions and the minutes of 
> meeting show progress away from that initial consensus.
> 
> I believe Ott's concerns are either dealt with or at least 
> mentioned in the draft. Arrest me if I'm wrong.
> 
> -- Tom
> 
> > We made an explicit decision in the original draft that UDP 
> was not required, not that we would do it later. That as far 
> as I am concerned represents the current status of consensus.
> >
> > This was done on the basis that we had all seen how UDP 
> support had complicated SIP, and we did not want to repeat that issue.
> >
> > So this is not continuing the work. The status is an author 
> draft which goes against a WG consensus position.
> >
> >> Of Roni Even
> >> I think that updating BFCP with UDP support is very important. I 
> conferencing 
> >> application and since the implementers encountered 
> problems with TCP 
> Gonzalo as far as 
> >> I remember suggested to add it to a BFCP bis draft.
> >>
> >> Thanks
> >> Roni Even
> >>
> Publication 
> >> > >>> We submitted draft-sandbakken-xcon-bfcp-udp-02 early 
> in March -
> >> > well in
> >> > >>> advance of IETF-77.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Jun 2010 19:12:18 -0400

> I find that an unacceptable direction for IETF to be heading in. 

I just came across this discussion, and am not entirely briefed on all 
its history.

Nevertheless I'm inclined to agree with Keith on this.
In fact I think the argument being raised in support of this direction 
is an even broader one: that no new feature can be added to sip if it 
doesn't work through currently deployed SBCs. I really hope we have not 
reached that state of affairs.

	Thanks,
	Paul

>> support had

---

From: "Roni Even" <[email-masked]>
Date: Thu, 10 Jun 2010 08:22:55 +0300

Hi  Keith,

I think that the IETF is trying to design protocols that will work over the
Internet and also to enable interoperability between independent
implementations. 
 
In the BFCP case the shipping implementations support TCP as the transport
protocol but they encountered issues when running over the Internet due to
devices like SBCs and due to lack of support for TCP media relay or ICE-TCP
[I-D.ietf-mmusic-ice-tcp].  
When implementations looked at how to address the issue, the
interoperability went away since there is no fall back solution for this
real life case. Some did a fall back to HTTP and some did to UDP but not in
an interoperable way.

In order to achieve interoperability, this draft is trying to extend the
current BFCP. It is not suggesting to replace TCP but to keep TCP as the
mandatory transport and use UDP as fallback if unable to establish TCP
connection. 

As for security, if the topic will be adopted the solution will be updated
to use DTLS as the transport for BFCP.

I hope that people will read the draft and look at the objectives and the
proposed solution.

BTW: This is a problem for client to client media connections over TCP and
my understanding is that RTSP offers to use both TCP and UDP since both are
specified. Since BFCP is not a payload but is running in parallel to the RTP
payload (for the point to point calls or MCU based multipoint) it needs
similar transport options.

Thanks
Roni Even

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Thursday, June 10, 2010 1:54 AM
> To: Roni Even; 'Richard L. Barnes'; 'Tom Kristensen'
> Cc: 'Mark Thompson'; 'Alan Johnston'; 'Tom Kristensen'; [email-masked]
> What you are essentially saying is that all protocols in the future
> that need reliable transport, as BFCP does, have to design in their own
> reliable transport element so they can use UDP. This is not a BFCP
> specific issue.
> 
> I would also note that you are also asking for adoption of a document
> that cannot in its current form meet the security requirements of the
> original RFC.
> 
> regards
> 
> Keith
> 
> 
> 
> 
> 
> > =

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 10 Jun 2010 11:23:18 +0200

Gonzalo, thanks for the input. 

Yes, I believe this discussion is exactly the discussion we should be having, rather than the blind adoption of a draft.

I believe in the past we also informally asked for IAB input on this issue. Did we ever get any viewpoint from that body.

regards

Keith

> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Thursday, June 10, 2010 10:19 AM
> To: Richard L. Barnes
> Cc: Roni Even; 'Tom Kristensen'; DRAGE, Keith (Keith); 
> [email-masked]; 'Mark Thompson'; 'Alan Johnston'
> Hi,
> a bit of background on this draft. When writing the BFCP 
> spec, I included a DNS-based mechanism to choose which 
> transport protocol to use. However, the WG decided to specify 
> a single transport protocol
> (TCP) instead. At that point, using UDP instead of TCP was 
> seen as an unnecessary optimization because the may reason 
> for using UDP was to save a RTT (i.e., by avoiding the TCP 
> three-way handshake) in certain circumstances. Nobody seems 
> to be keep on using SCTP either.
> 
> The typical use case for BFCP consisted of a client talking 
> to a floor control server with a public IP address. In that 
> type of scenario, TCP works well even when the client is behind a NAT.
> 
> However, there are deployments where BFCP is used between two 
> endpoints (one of them acts as the floor control server), 
> none of which have a public IP address. Given the problems 
> ICE TCP currently has, implementers have (understandably) 
> started using UDP. Using UDP allows endpoints to use ICE or 
> any other NAT traversal technique for UDP flows.
> 
> With this background in mind, there are different things the 
> WG may choose to do. We could follow the approach in this 
> draft and specify a UDP transport for BFCP, we could specify 
> how to encapsulate BFCP over TCP over UDP, we could progress 
> ICE TCP to completion, ...
> 
> Cheers,
> 
> Gonzalo
> 
> 
> 
> On 09/06/2010 3:51 PM, Richard L. Barnes wrote:
> conferencing. What 
> >> the implementers found out that TCP does not work in real networks 
> >> due to Session border controllers not supporting TCP as 
> used in BFCP.
> >> This is why in products they try to establish TCP 
> connection and if 
> >> fails tries UDP.
> >> The video conferencing vendors participating in the IMTC 
> sip parity 
> >> activity group defined an interoperability profile that references 
> >> this option Roni Even
> >>
> >>> From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> >>> Of Richard L. Barnes
> >>>> complete. (This has been delayed of various reasons, but the 
> >>>> authors believe the -02 version in question here should be ready 
> >>>> for adoption).
> >>>>
> >>>>> We made an explicit decision in the original draft that UDP was 
> >>>>> not required, not that we would do it later. That as 
> far as I am 
> >>>>> This was done on the basis that we had all seen how UDP support 
> >>>>> had complicated SIP, and we did not want to repeat that issue.
> >>>>>
> >>>>> I believe Georg Ott also expressed some concerns which 
> I did not 
> >>>>> see answered on list at all.
> >>>>>
> >>>>> regards
> >>>>>
> >>>>> Keith
> >>>>>
> >>>>>> We discussed this work in previous IETF meeting and Gonzalo as 
> >>>>>> far as I remember suggested to add it to a BFCP bis draft.
> >>>>>>
> >>>>>> Thanks
> >>>>>> Roni Even
> >>>>>>

---

From: Tom Kristensen <[email-masked]>
Date: Thu, 10 Jun 2010 11:52:29 +0200

> reached that state of affairs.

I like this kind of argumentation when looking at the problem at hand
from an ideal point of view. However, we also have to be pragmatic to
some degree and make useful protocols that works in the actual networks
existing out there.

Camarillo pointed out a path for discussion in a recent message in this
thread - and we have had parts of it already in the WG and elsewhere.
Some of the alternatives are mentioned in the draft (versions -01 and
-02).

-- Tom

---

From: "Roni Even" <[email-masked]>
Date: Thu, 10 Jun 2010 13:04:39 +0300

Hi Gonzalo,
I think that the important input is
" However, there are deployments where BFCP is used between two endpoints
(one of them acts as the floor control server), none of which have a public
IP address. Given the problems ICE TCP currently has, implementers have
(understandably) started using UDP. Using UDP allows endpoints to use ICE or
any other NAT traversal technique for UDP flows."

I think that even though the suggestions " we could specify how to
encapsulate BFCP over TCP over UDP, we could progress ICE TCP to completion,
..." are interesting they do not solve the issue raised in the previous
paragraph since this discussion about TCP has been going forever and is not
progressing. Nobody shows interest which means that people are either using
HTTP or UDP when they encounter the problem. 
If there are cases where TCP does not work I do not see any reason not to
use UDP / DTLS as a fallback mechanism as this draft suggests.

Roni Even

> Sent: Thursday, June 10, 2010 12:19 PM
> To: Richard L. Barnes
> Cc: Roni Even; 'Tom Kristensen'; 'DRAGE, Keith (Keith)'; [email-masked];
> 'Mark Thompson'; 'Alan Johnston'
> a bit of background on this draft. When writing the BFCP spec, I
> included a DNS-based mechanism to choose which transport protocol to
> use. However, the WG decided to specify a single transport protocol
> (TCP) instead. At that point, using UDP instead of TCP was seen as an
> unnecessary optimization because the may reason for using UDP was to
> save a RTT (i.e., by avoiding the TCP three-way handshake) in certain
> circumstances. Nobody seems to be keep on using SCTP either.
> 
> The typical use case for BFCP consisted of a client talking to a floor
> control server with a public IP address. In that type of scenario, TCP
> works well even when the client is behind a NAT.
> 
> However, there are deployments where BFCP is used between two endpoints
> (one of them acts as the floor control server), none of which have a
> public IP address. Given the problems ICE TCP currently has,
> implementers have (understandably) started using UDP. Using UDP allows
> endpoints to use ICE or any other NAT traversal technique for UDP
> flows.
> 
> With this background in mind, there are different things the WG may
> choose to do. We could follow the approach in this draft and specify a
> UDP transport for BFCP, we could specify how to encapsulate BFCP over
> TCP over UDP, we could progress ICE TCP to completion, ...
> 
> Cheers,
> 
> Gonzalo
> 
> 
> 
> >>> Kristensen;
> three
> authors
> not
> had
> 2.

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 10 Jun 2010 13:00:09 +0200

Hi all,

with respect to this topic, I think there are many issues implementers
have to face when bringing IETF solutions to the real world. We found
ourselves many times in a situation in which some kind of work-around
had to be devised in order to let things work properly. Just to cite a
couple of examples, with BFCP we had to find a way to let it work in a
distributed conferencing scenario (which is far from easy, given the
intrinsic centralized model behind such protocol). In such case, we
decided to encapsulate BFCP messages in the body of XMPP
server-to-server packets (see the XCON-DCON Synchronization Protocol in
draft-romano-dcon-xdsp-reqs-06 for the details) and then even devised
a BFCP-XMPP gateway for such a purpose. With respect to the NAT
traversal issue, we also implemented an HTTP encapsulation. Moving
further we even conceived a DTMF-based frontend to BFCP ;) and also
almost thought about a BFCP-over-RTP approach.

That said, I nevertheless agree with Keith on the discussion. Those
problems may be common to other TCP-based protocols as well, and as such
a generic solution (generic TCP over UDP, for instance, or anything
else) may be a much better approach than doing a protocol specific
patch. Besides, whatever the solution, it should also take care of how
the negotiation of such channels would be affected (as is the
case of RFC4583 for BFCP, which the proposed draft actually does).

As Keith already suggested, DISPATCH may be a much better place to
discuss this issue: DISPATCH is where we'll also propose the above
mentioned DCON work.

Lorenzo

On Thu, 10 Jun 2010 08:22:55 +0300

-- 
Lorenzo Miniero
Meetecho s.r.l.
http://www.meetecho.com/

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 10 Jun 2010 09:18:12 -0400

<hat type="individual"/>

I tend to agree with Lorenzo that DISPATCH would be a better place to  
have these discussions, especially given that, as far as I can tell  
from this thread, the problem seems to be a general one of NAT  
traversal for TCP.

---

From: "Roni Even" <[email-masked]>
Date: Thu, 10 Jun 2010 16:27:31 +0300

Lorenzo,
Your email emphasis the urgency of a solution, you mention that you
encapsulate BFCP in HTTP for NAT traversal. In your own solution it works.
The problem is with interoperability between different implementations and
the current state is that for the same application people choose different
approaches for fall back if TCP fail.

Again this may look like a general problem but the so far there are no
solutions if though it is being discussed. We can go on discussing ICE TCP
and TCP relays other directions but this should not stop us from solving
current problems.

Part of the UDP fall back is also to address the reliability of the protocol
this requires specific solution per protocol. I think that this work is
within the scope of XCON since the BFCP protocol design in the WG is not
finished (Gonzalo agrees that the use case where the BFCP server is not in
the public Internet was not considered when designing the protocol) so we
should finish BFCP in XCON
Roni Even 

> From: Lorenzo Miniero [mailto:[email-masked]]
> Sent: Thursday, June 10, 2010 2:00 PM
> To: Roni Even
> Cc: 'DRAGE, Keith (Keith)'; 'Richard L. Barnes'; 'Tom Kristensen';
> 'Mark Thompson'; 'Alan Johnston'; 'Tom Kristensen'; [email-masked]
> but
> > > > > >> I believe Georg Ott also expressed some concerns which I did
> not
> On
> > > > > >>>>>>>    http://tools.ietf.org/html/draft-sandbakken-xcon-
> bfcp-
> > > udp
> > > > > >>>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Jun 2010 10:52:47 -0400

> some degree and make useful protocols that works in the actual networks

Yes, I understand. At some point we must work with what exists.

In the case of SBCs this is a constant problem because they are not an 
entity with well defined behavior. Most of them are configurable to a 
large degree. I don't know if the problems you had were because of lack 
of configurability in the SBCs, or because of some more major lack, such 
as ICE-TCP.

At the least, I don't want "we did *this* because *that* didn't work" to 
be sufficient justification.

For instance, I believe there is very close analogy here to MSRP. Should 
the same concerns cause us to define MSRP-over-UDP?

> thread - and we have had parts of it already in the WG and elsewhere.

I hunted for a message by Gonzalo on this topic without success.

> Some of the alternatives are mentioned in the draft (versions -01 and

What section? I couldn't find those either, in -02.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Jun 2010 10:57:39 -0400

> I hunted for a message by Gonzalo on this topic without success.

Hmm. I now found a message in reply to Gonzalo's, so I know what he 
said, though I still don't have his original message. Odd.

In any case, his comments do provide some insight.
I agree it is worth having a discussion of the use cases where 
bfcp-over-tcp fails, and what the options are for solving those.

	Thanks,
	Paul

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Thu, 10 Jun 2010 14:02:31 -0700

Extremely interested in moving this forward.

Thanks,
Allyn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tom Kristensen
Sent: Monday, June 07, 2010 6:23 AM
To: [email-masked]
Cc: Alan Johnston; Mark Thompson; [email-masked]
Subject: [XCON] WG Adoption? draft-sandbakken-xcon-bfcp-udp-02

-- Tom

---

From: "Roni Even" <[email-masked]>
Date: Wed, 23 Jun 2010 08:05:55 +0300

Hi,
The XCON charter includes:

  - A mechanism for notification of conference related events/changes
    (for example a floor change)
  - A basic floor control protocol

This document is an update to the floor control protocol. You need a working
floor control protocol for centralized conferences and the current solution
has implementation problem. This is why I think that this work is within the
charter of XCON who is still an open WG. 
This proposal is in XCON for a while and there were requests to address some
issues in the proposal but there was never a question if this is within the
scope of XCON.
Roni Even

> From: Richard L. Barnes [mailto:[email-masked]]
> Sent: Thursday, June 10, 2010 4:18 PM
> To: Lorenzo Miniero
> Cc: Roni Even; 'DRAGE, Keith (Keith)'; 'Tom Kristensen'; 'Mark
> Thompson'; 'Alan Johnston'; 'Tom Kristensen'; [email-masked]

---

From: Patrick Luthi <[email-masked]>
Date: Wed, 23 Jun 2010 17:12:16 +0200

I am with Roni on this one! BFCP is in the scope of XCON and there 
shouldn't be a problem extending it to include UDP as a fallback.

Videoconferencing manufacturers have a problem with TCP as discussed 
earlier and they need a solution now!

XCON Chairs, could you please consider this work to move forward?

Regards,

Patrick

---

From: Mary Barnes <[email-masked]>
Date: Wed, 23 Jun 2010 11:25:34 -0500

I have reviewed the draft in question and while I agree that this
could be viewed as a workaround for some more general problems that
need to be solved, there is a current industry need for the solution
in this draft.   If the general problems described go to DISPATCH
(which is the appropriate thing to do rather than bringing this
specific document), the timeframe for getting agreement on the problem
to be solved and for the solutions to be agreed would be far longer
IMHO than if this document were progressed. If XCON would prefer to
close the WG without progressing this document (in this form or as a
-bis to RFC  4582), my suggestion would be to do as was done for the
remaining SIP and SIPPING documents and progress this item as an
individual AD sponsored.

Mary.

On Thu, Jun 10, 2010 at 8:18 AM, Richard L. Barnes <[email-masked]> wrote:
> <hat type="individual"/>
>
> I tend to agree with Lorenzo that DISPATCH would be a better place to have
> these discussions, especially given that, as far as I can tell from this
> thread, the problem seems to be a general one of NAT traversal for TCP.
>
>
>
>>>>>> think this draft is needed?  What requirement does it meet
>>>>>
>>>>> that BFCP
>>>>>>
>>>>>> doesn't right now?
>>>>>>
>>>>>> Thanks,
>>>>>> --Richard
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> The UDP/BFCP draft has been presented and discussed in
>>>>>
>>>>> two or three
>>>>>>>
>>>>>>> IETF XCON sessions. No objection to the work being
>>>>>
>>>>> carried on, just
>>>>>>>
>>>>>>> complete. (This has been delayed of various reasons, but
>>>>>
>>>>> the authors
>>>>>>>
>>>>>>> I believe Ott's concerns are either dealt with or at
>>>>>
>>>>> least mentioned
>>>>>>>
>>>>>>>> We made an explicit decision in the original draft that
>>>>>
>>>>> UDP was not
>>>>>>>>
>>>>>>>> So this is not continuing the work. The status is an
>>>>>
>>>>> author draft
>>>>>>>>
>>>>>>>>> Subject: Re: [XCON] WG Adoption?
>>>>>
>>>>> draft-sandbakken-xcon-bfcp-udp-02
>>>>>>>>>
>>>>>>>>> Hi Alan,
>>>>>>>>>> Taking on any new milestones for the working group
>>>>>
>>>>> would require:
>>>>>>>>>>
>>>>>>>>>> 1. Strong support and interest from working group
>>>>>
>>>>> participants 2.
>>>>>>>>>>
>>>>>>>>>> Approval of our ADs.
>>>>>>>>>>
>>>>>>>>>> of interests, and get feedback on the best way to move
>>>>>
>>>>> this work
>>>>>>>>>>
>>>>>>>>>> forward.
>>>>>>>>>>
>>>>>>>>>> - Alan -
>>>>>>>>>> co-chair XCON
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> The draft draft-sandbakken-xcon-bfcp-udp-02 was submitted
>>>>>>>>>
>>>>>>>>> early in
>>>>>>>>>>>
>>>>>>>>>>> We'd like to point out that interested parties for this
>>>>>>>>>
>>>>>>>>> work indeed
>>>>>>>>>>>
>>>>>>>>>>> exist.
>>>>>>>>>>>
>>>>>>>>>>> below. No response given. Therefore, this request on
>>>>>
>>>>> the list.)
>>>>>>>>>>>
>>>>>>>>>>> -- Tom
>>>>>>>>>>>
>>>>>>>>>>>>>  http://tools.ietf.org/html/draft-sandbakken-xcon-bfcp-
>>>>
>>>> udp
>>>>>>>>>>>>>
>>>>>>>>>>>>> No comments received. Neither on XCON WG list, nor
>>>>>>>>>
>>>>>>>>> directly to the
>>>>>>>>>>>>>

---

From: "Roni Even" <[email-masked]>
Date: Thu, 24 Jun 2010 17:40:25 +0300

Mary,
I think that in the discussion in the past, Gonzalo suggested to do a bis
draft to RFC 4582. I think he mentioned other issues he wanted to update.
Roni Even

> Mary Barnes
> Sent: Wednesday, June 23, 2010 7:26 PM
> To: Richard L. Barnes
> Cc: Tom Kristensen; DRAGE, Keith (Keith); [email-masked]; Mark Thompson;
> Alan Johnston
> have
> >>> I think that the IETF is trying to design protocols that will work
> over
> >>> the
> >>> protocol but they encountered issues when running over the Internet
> due
> >>> to
> >>> real life case. Some did a fall back to HTTP and some did to UDP
> but not
> >>> in
> >>> an interoperable way.
> >>>
> >>> BTW: This is a problem for client to client media connections over
> TCP
> >>> and
> >>> my understanding is that RTSP offers to use both TCP and UDP since
> both
> >>> are
> >>> specified. Since BFCP is not a payload but is running in parallel
> to the
> >>> RTP

---

From: Tom Kristensen <[email-masked]>
Date: Thu, 24 Jun 2010 16:50:05 +0200

That's correct, Roni.

The thread starting with a list of issues in addition to the UDP/BFCP
extension is available in the list archives here:
http://www.ietf.org/mail-archive/web/xcon/current/msg02231.html

-- Tom

---

From: stephen botzko <[email-masked]>
Date: Thu, 24 Jun 2010 11:29:27 -0400

BFCP is an important component in our application (videoconferencing).  The
inability to use BFCP when TCP cannot be used is a huge problem for us
today.

So I would like to see this document progressed.

If for some reason XCON doesn't finish it before the WG is closed, I think
Mary's suggestion of progressing it under individual AD sponsorship is good.

Stephen Botzko

2010/6/24 Roni Even <[email-masked]>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 24 Jun 2010 08:53:10 -0700

I am very interested in seeing draft-sandbakken-xcon-bfcp-udp move forward as I see it as a very useful and straightforward extension of RFC 4582 that solves a real world problem in an way that makes use of many existing mechanisms already standardized within the IETF. With the IMTC, we are already recommending support for draft-sandbakken-xcon-bfcp-udp in addition to RFC 4582 as there are cases in which BFCP via TCP is not possible and BFCP via UDP offers a very workable solution. The draft already has wide support with the IMTC member companies, most of which are quite active within the IETF as well, so I feel there is sufficient support to move this draft forward.
As for the best path to achieve this, XCON seems the most logical choice to me, but I only recently started following the group's work and defer to others on the best way forward in terms or timing and procedure. My main concern is that the path taken is one that leads to standardize the addition of BFCP via UDP sooner rather than later.

Thanks,
Charles 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Kristensen
> Sent: Thursday, June 24, 2010 7:50 AM
> To: Roni Even
> Cc: Mark Thompson; Alan Johnston; DRAGE,Keith (Keith); [email-masked]; Tom Kristensen

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Thu, 24 Jun 2010 11:29:21 -0700

Although a general solution for TCP based media would be a very good thing to be worked on, we also are in the position of needing an immediate solution, and BFCP over UDP fills that bill. So, I'm also in favor of working further on the draft and moving forward with it, in whichever venue people find convenient.

Allyn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: Wednesday, June 23, 2010 9:26 AM
To: Richard L. Barnes
Cc: Tom Kristensen; DRAGE,Keith (Keith); [email-masked]; Mark Thompson; Alan Johnston
Subject: Re: [XCON] WG Adoption? draft-sandbakken-xcon-bfcp-udp-02

Mary.

---

From: Patrick Luthi <[email-masked]>
Date: Thu, 24 Jun 2010 21:19:20 +0200

Great to hear that since I was making that point about the problem 
with TCP for videoconferencing in a previous post!

XCON seems to be the right place for this work, but if the WG closes, 
then Mary's suggestion is perfectly good. The key is to have a solution soon!

Regards,

Patrick

At 17:29 24/06/2010, stephen botzko wrote:
>BFCP is an important component in our application 
>(videoconferencing).  The inability to use BFCP when TCP cannot be 
>used is a huge problem for us today.
>
>If for some reason XCON doesn't finish it before the WG is closed, I 
>think Mary's suggestion of progressing it under individual AD 
>sponsorship is good.
>
>Stephen Botzko
>
>
>
>2010/6/24 Roni Even <<mailto:[email-masked]>[email-masked]>
>Mary,
> > From: <mailto:[email-masked]>[email-masked] 
> [mailto:[email-masked]] On Behalf Of
> > Mary Barnes
> > Cc: Tom Kristensen; DRAGE, Keith (Keith); 
> <mailto:[email-masked]>[email-masked]; Mark Thompson;
> > Alan Johnston
> > On Thu, Jun 10, 2010 at 8:18 AM, Richard L. Barnes 
> <<mailto:[email-masked]>[email-masked]>
> > wrote:
> > > <hat type="individual"/>
> > >
> > >> "Roni Even" 
> <<mailto:[email-masked]>[email-masked]> wrote:
> > >>
> > >>> Hi  Keith,
> > >>>
> > >>>> Cc: 'Mark Thompson'; 'Alan Johnston'; 'Tom Kristensen';
> > <mailto:[email-masked]>[email-masked]
> > >>>>> 'Tom Kristensen'; <mailto:[email-masked]>[email-masked]
> > >>>>>> From: <mailto:[email-masked]>[email-masked] 
> [mailto:[email-masked]]
> > >>>>>
> > >>>>> On Behalf
> > >>>>>>
> > >>>>>> Of Richard L. Barnes
> > >>>>>> Kristensen; <mailto:[email-masked]>[email-masked]
> <<mailto:[email-masked]>[email-masked]> wrote:
> > >>>>>>>>
> > >>>>>>>>> From: 
> <mailto:[email-masked]>[email-masked] 
> [mailto:[email-masked]] On
> > >>>>>>>>> Behalf Of Roni Even
> > >>>>>>>>> Cc: 'Mark Thompson'; <mailto:[email-masked]>[email-masked]
> > >>>>>>>>>> From: 
> <mailto:[email-masked]>[email-masked] 
> [mailto:[email-masked]]
> > >>>>>>>>>
> > >>>>>>>>> On Behalf
> > >>>>>>>>>>
> > >>>>>>>>>> Of Alan Johnston
> > >>>>>>>>>> Cc: Mark Thompson; <mailto:[email-masked]>[email-masked]
> <http://tools.ietf.org/html/draft-sandbakken-xcon-bfcp->http://tools.ietf.org/html/draft-sandbakken-xcon-bfcp-
> > >>>>
> > >>>> udp
> > >>>>>>>>>>>>>
> > >>>>>>>>>> <mailto:[email-masked]>[email-masked]
> > >>>>>>>>> <mailto:[email-masked]>[email-masked]
> > >>>>>>>> <mailto:[email-masked]>[email-masked]
> > >>>>>>> ## <http://www.tandberg.com>http://www.tandberg.com
> > >>>>>>> <mailto:[email-masked]>[email-masked]
> > >>>>>> <mailto:[email-masked]>[email-masked]
> > >>> <mailto:[email-masked]>[email-masked]
> > >> <http://www.meetecho.com/>http://www.meetecho.com/
> > >
> > > <mailto:[email-masked]>[email-masked]
> > <mailto:[email-masked]>[email-masked]
><mailto:[email-masked]>[email-masked]

---

From: Alex Eleftheriadis <[email-masked]>
Date: Mon, 28 Jun 2010 11:30:06 -0400

+1.

--
Alex Eleftheriadis
[email-masked]