Subject: [dispatch] BFCP over UDP

From: Peter Musgrave <[email-masked]>
Date: Fri, 12 Nov 2010 08:03:28 +0800

Hi all, 

This became a topic over Hot Pot last night. 

Why do middle boxes not relay the TCP? Our conclusion was that it was because it was expensive for them to do this. They need to be stateful and hold data for possible retransmission. (Ok, in some implementation you might be able to do this down in the stack, but many vendors likely need to do this higher up in the application). 

Saying we'll use ICE-TCP does not really change this - it moves the cost of doing this onto a TURN-TCP server in the sky (at least a large fraction of the time). 

Should we in general be preferring UDP options for things which have previously been TCP simply because they scale better in cases where the dest. of a TCP connection is behind a NAT - or is this just "the cost of doing business?". 

Perhaps I should start a company which leases TURN servers on demand :-)

Peter Musgrave

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 11 Nov 2010 19:23:50 -0500

> Why do middle boxes not relay the TCP? Our conclusion was that it was because it was expensive for them to do this. They need to be stateful and hold data for possible retransmission. (Ok, in some…

No they don't.  No middlebox would ever have to hold onto TCP packets in the media plane, unless it wants to inspect their content for matching IDS signatures.  And even then there are tricks to avoid serious buffering.  Been there, done that, got the T-shirt.

It's also not the case that no middleboxes relay TCP - I know of at least one SBC vendor that does relay it... for free (they do not charge extra to do it).

My guess is it's what Roni said: the demand for it is just not high enough to warrant the development resources.  Like anyone, middlebox vendors have to prioritize what to implement, so BFCP must not be a popular enough thing to make it a priority for some of them. (which of course creates a nice chicken and egg problem) 

> Saying we'll use ICE-TCP does not really change this - it moves the cost of doing this onto a TURN-TCP server in the sky (at least a large fraction of the time). 

If a TURN-TCP server has to buffer TCP packets for retransmission, TURN-TCP is designed wrong.  TCP splicing/stitching techniques have been around for a long time.

-hadriel

---

From: Peter Musgrave <[email-masked]>
Date: Fri, 12 Nov 2010 08:58:52 +0800

I concede the middle-box cost issue. However you are still more likely to need a TURN-TCP server if TCP is used for an application protocol in an SDP m-line. 

If we needed a new BFCP today - with our NAT awareness - would we pick TCP?

In fact the more I think about it, the more I think the comment made in the meeting about using INFO or SUB/NOT makes way more sense. I really don't want to re-engineer fragmentation, reliable transmission etc. 

I think if multi-screen, multi-collab telepresence stuff catches on then BFCP might not meet our needs - and a richer semantics might be necessary - but I am far from an expert on BFCP. In any case that will become clear over time.

Peter Musgrave

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 11 Nov 2010 20:46:47 -0500

> If we needed a new BFCP today - with our NAT awareness - would we pick TCP?

That's a really good question.

> In fact the more I think about it, the more I think the comment made in the meeting about using INFO or SUB/NOT makes way more sense. I really don't want to re-engineer fragmentation, reliable tran…

I don't think SUB/NOT makes much sense.  There's no benefit to adding the subscription overhead for this use-case.  An Info-Package would be better.  But even then, if BFCP could reasonably generate large message sizes, Info-Package wouldn't be good. (because SIP itself runs over UDP frequently)  And if BFCP is chatty, using Info-Package wouldn't be good, since INFO is in the signaling plane. 

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 11 Nov 2010 20:53:36 -0500

> Should we in general be preferring UDP options for things which have previously been TCP simply because they scale better in cases where the dest. of a TCP connection is behind a NAT - or is this j…

It is very tempting to say "no", just to keep a competitive advantage. :)

But I'm also a fan of fixing problems people have in the real world, so I think we should consider it.  

In my simple cave-man brain, the reasons we use TCP in the media plane are in cases where we need any one or more of:
1) reliable delivery
2) ordered delivery
3) unbounded message sizes
4) congestion control

Obviously if we use UDP instead, we could re-invent those at the application layer instead of transport... or just tunnel TCP over UDP as has been suggested.  My guess is the latter is easier, from a standards perspective. (from an implementation/use perspective it may be harder for some folks, but I'm not sure if that matters)

The other question is if a media-plane protocol wants any one of those above but specifically does NOT want one or more of the others.  For example if you had an RTP application with potentially large payloads and thus wanted (3), but did not want (1).  Then doing it at the application layer makes perverse sense.  Just my 2 cents.

-hadriel

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 12 Nov 2010 10:18:59 +0800

Hi,

TCP over UDP is the best solution, IMHO, and it can be implemented in
several different ways (Teredo being one of them, as pointed out during
the session yesterday).

BFCP can be extended. So, if you need new semantics, you can add them to
the protocol.

As I explained yesterday, using a SIP event package to deliver
information to the endpoints was proposed a while ago:

http://www.watersprings.org/pub/id/draft-ekim-sipping-conf-floor-package-01.txt

You can fetch the notes from the XCON meeting where I presented the
draft from the link below. It did not get enough traction at that point
but now that we have more implementation experience, we may want to
revisit that decision.

http://www.ietf.org/mail-archive/web/xcon/current/msg01318.html

Cheers,

Gonzalo

On 12/11/2010 8:03 AM, Peter Musgrave wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 12 Nov 2010 10:36:06 +0800

> Saying we'll use ICE-TCP does not really change this - it moves the cost of doing this onto a TURN-TCP server in the sky (at least a large fraction of the time).

You're still living in 2005. Go re-read ICE-TCP. If you work through the 
success rates of everything ranked higher than TURN, I think it becomes 
an extreme minority case, not a "large fraction."

/a

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 12 Nov 2010 04:42:17 +0100

Using SIP to do BFCP functionality makes as much sense as using SIP to do the functions of RTCP!

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Peter Musgrave
> Sent: Friday, November 12, 2010 12:59 AM
> To: Hadriel Kaplan
> Cc: [email-masked] list
> Subject: Re: [dispatch] BFCP over UDP
> 
> I concede the middle-box cost issue. However you are still 
> more likely to need a TURN-TCP server if TCP is used for an 
> application protocol in an SDP m-line. 
> 
> In fact the more I think about it, the more I think the 
> comment made in the meeting about using INFO or SUB/NOT makes 
> way more sense. I really don't want to re-engineer 
> fragmentation, reliable transmission etc. 
> 
> I think if multi-screen, multi-collab telepresence stuff 
> catches on then BFCP might not meet our needs - and a richer 
> semantics might be necessary - but I am far from an expert on 
> BFCP. In any case that will become clear over time.
> 
> Peter Musgrave
> 
> 
> >> Why do middle boxes not relay the TCP? Our conclusion was 
> that it was because it was expensive for them to do this. 
> They need to be stateful and hold data for possible 
> retransmission. (Ok, in some implementation you might be able 
> to do this down in the stack, but many vendors likely need to 
> do this higher up in the application). 
> > 
> > No they don't.  No middlebox would ever have to hold onto 
> TCP packets in the media plane, unless it wants to inspect 
> their content for matching IDS signatures.  And even then 
> there are tricks to avoid serious buffering.  Been there, 
> done that, got the T-shirt.
> > 
> > It's also not the case that no middleboxes relay TCP - I 
> know of at least one SBC vendor that does relay it... for 
> free (they do not charge extra to do it).
> > 
> > My guess is it's what Roni said: the demand for it is just not high 
> > enough to warrant the development resources.  Like anyone, 
> middlebox 
> > vendors have to prioritize what to implement, so BFCP must not be a 
> > popular enough thing to make it a priority for some of 
> them. (which of 
> > course creates a nice chicken and egg problem)
> > 
> > 
> >> Saying we'll use ICE-TCP does not really change this - it 
> moves the cost of doing this onto a TURN-TCP server in the 
> sky (at least a large fraction of the time). 
> > 
> > If a TURN-TCP server has to buffer TCP packets for 
> retransmission, TURN-TCP is designed wrong.  TCP 
> splicing/stitching techniques have been around for a long time.
> > 
> > -hadriel
>

---

From: Peter Musgrave <[email-masked]>
Date: Fri, 12 Nov 2010 11:56:29 +0800

Really?

I think of it's use just in terms of - "Your turn to present now" in the context of H.239 (2nd video for collab) . 

Seems like a low rate, event driven, modest message thing to me...although I guess people could be unreasonable in their use of  FloorRequest or FloorQuery.

Anyway - not like anyone is going to re-invent this in INFOs "for fun".

Peter

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 12 Nov 2010 04:59:26 +0100

The signalling rate may be modest, but the nature is real time. If I want to mute the current speaker, i.e. take the floor away from him, I want that to be instantaenous, not have to wait for SIP routers to get the message to the endpoint.

regards

Keith 

> From: Peter Musgrave [mailto:[email-masked]] 
> Sent: Friday, November 12, 2010 3:56 AM
> To: DRAGE, Keith (Keith)
> Cc: Hadriel Kaplan; [email-masked] list
> I think of it's use just in terms of - "Your turn to present 
> now" in the context of H.239 (2nd video for collab) . 
> 
> Seems like a low rate, event driven, modest message thing to 
> me...although I guess people could be unreasonable in their 
> use of  FloorRequest or FloorQuery.
> 
> >> I concede the middle-box cost issue. However you are still more 
> >> likely to need a TURN-TCP server if TCP is used for an application 
> >> protocol in an SDP m-line.
> >> 
> comment made 
> >> in the meeting about using INFO or SUB/NOT makes way more sense. I 
> >> really don't want to re-engineer fragmentation, reliable 
> transmission 
> >> etc.
> >> 
> catches on 
> >> then BFCP might not meet our needs - and a richer 
> semantics might be 
> >> necessary - but I am far from an expert on BFCP. In any case that 
> >> will become clear over time.
> >> 
> >> Peter Musgrave
> >> 
> >> 
> retransmission. 
> >> (Ok, in some implementation you might be able to do this 
> down in the 
> >> stack, but many vendors likely need to do this higher up in the 
> >> application).
> >>> 
> >> TCP packets in the media plane, unless it wants to inspect their 
> >> content for matching IDS signatures.  And even then there 
> are tricks 
> >> to avoid serious buffering.  Been there, done that, got 
> the T-shirt.
> >>> 
> >> moves the cost of doing this onto a TURN-TCP server in the sky (at 
> >> least a large fraction of the time).
> >>> 
> splicing/stitching 
> >> techniques have been around for a long time.
> >>> 
> >>> -hadriel
> >>

---

From: "Roni Even" <[email-masked]>
Date: Mon, 15 Nov 2010 10:53:49 +0200

Hi,
My view on the topic is that we made a wrong decision in the past to use TCP
based on an architecture that may have been relevant. The fact is that the
only use for BFCP today (please provide others if you are aware) is when the
BFCP server is behind a NAT being used between two video conferencing end
points or between an MCU and video endpoints.
The implementation experience is that the product have problems with TCP
support in this architecture. 
Instead of trying to correct the problem I feel that what is happening is
that this work becomes and hostage to deployment of some protocol which may
be the worst thing that may happen for a standard body. 
What may happen is that using BFCP over UDP is happening anyhow but is not
be documented at the IETF which is worse for interoperability and will lack
better review.

The people who objected agreed that there is currently a problem but said
that solution is coming which may be true in terms of the specification but
not in terms of deployment. This is why I feel that the work is hostage
until deployment of NAT traversal for TCP will exist

Roni Even

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Peter Musgrave
> Sent: Friday, November 12, 2010 2:03 AM
> To: [email-masked] list
> Subject: [dispatch] BFCP over UDP
> 
> Hi all,
> 
> Why do middle boxes not relay the TCP? Our conclusion was that it was
> because it was expensive for them to do this. They need to be stateful
> and hold data for possible retransmission. (Ok, in some implementation
> you might be able to do this down in the stack, but many vendors likely
> need to do this higher up in the application).
> 
> Saying we'll use ICE-TCP does not really change this - it moves the
> cost of doing this onto a TURN-TCP server in the sky (at least a large
> fraction of the time).
> 
> Should we in general be preferring UDP options for things which have
> previously been TCP simply because they scale better in cases where the
> dest. of a TCP connection is behind a NAT - or is this just "the cost
> of doing business?".
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 15 Nov 2010 12:09:49 -0500

I think that for the BFCP case the issue isn't as much NAT traversal, but rather legacy middlebox "traversal" as well as NAT traversal.  

In other words, you need to be able to work through something like this:

         +---------+   +---------+
         |   SIP   |   |   SIP   |
         |Middlebox|---|Middlebox|
         +---------+   +---------+
     +-----+/                \+-----+
     | NAT |                  | NAT |
     +-----+                  +-----+
+----+ /                         \ +----+
|BFCP|/                           \|BFCP|
| UA |                             | UA |
+----+                             +----+

ICE-TCP won't help you do that.  It'll help you get through NATs, not legacy middleboxes.

-hadriel

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 16 Nov 2010 06:52:20 +0800

I agree with Roni. 

This is a real problem and there are implementations of what Tom presented. A description of how this has been done makes sense and since BFCP is an IETF protocol doing this RAI makes the most sense. ("Rough consensus and running code" ring a bell for anyone?)

IF we had a blank sheet of paper and time to wait for TURN-TCP to be specified fully, implemented and deployed then TCP would be possible. That is not where we are. 

I agree the doc needs to address some issues like MTU/fragmentation - but these are straight-forward issues. 

Peter

---

From: Adam Roach <[email-masked]>
Date: Mon, 15 Nov 2010 17:16:16 -0600

> This is a real problem and there are implementations of what Tom presented. A description of how this has been done makes sense and since BFCP is an IETF protocol doing this RAI makes the most sens…

We actually have a process that covers publication of protocols that 
people have gone off and implemented without IETF community input. It's 
how things like IRC (RFC 2812), Cisco's Lawful Intercept protocol (RFC 
3924) and MSCML (RFC 5022) were published.

I strongly support publication of BFCP/UDP using the same mechanism -- 
that is, an informational draft (outside of a working group) that 
describes a deployed mechanism that isn't necessarily endorsed as part 
of the overall internet architecture. I still believe it is a 
fantastically bad idea to have a protocol that can ride on two different 
transports, and don't think it is sensible to publish a standards-track 
document that endorses this kind of bifurcation.

> IF we had a blank sheet of paper and time to wait for TURN-TCP to be specified fully, implemented and deployed then TCP would be possible. That is not where we are.

For what it's worth: if I were the type of person to make wagers, I 
would put my money on ICE-TCP finishing before BFCP/UDP. I've seen this 
kind of race before (XCON's CCP versus simple-chat), and the general 
solution is going to finish before the "simpler" point solution.

Or we could forgo learning from our past experiences.

/a

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 16 Nov 2010 07:20:27 +0800

I am cool with an informational draft. I agree that is the best way forward. 

I will not take the bet on ICE-TCP - you may well be right.

Peter

On 2010-11-16, at 7:16 AM, Adam Roach wrote:

> We actually have a process that covers publication of protocols that people have gone off and implemented without IETF community input. It's how things like IRC (RFC 2812), Cisco's Lawful Intercept protocol (RFC 3924) and MSCML (RFC 5022) were published.
> 
> I strongly support publication of BFCP/UDP using the same mechanism -- that is, an informational draft (outside of a working group) that describes a deployed mechanism that isn't necessarily endorsed as part of the overall internet architecture. I still believe it is a fantastically bad idea to have a protocol that can ride on two different transports, and don't think it is sensible to publish a standards-track document that endorses this kind of bifurcation.
> 
> For what it's worth: if I were the type of person to make wagers, I would put my money on ICE-TCP finishing before BFCP/UDP. I've seen this kind of race before (XCON's CCP versus simple-chat), and the general solution is going to finish before the "simpler" point solution.
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 15 Nov 2010 20:20:28 -0600

> In other words, you need to be able to work through something like this:

What are you seeing in the BFCP/UDP draft that makes you think it will 
make it through the middleboxes? It's pretty clear that legacy 
middleboxes will have no clue what "m=application 53280 UDP/DTLS/BFCP *" 
means. Why would this have any more success getting through the 
middleboxes than the SDP specified in ICE-TCP?

What you have described is a problem either way. We can solve it twice 
(BFCP/UDP and ICE-TCP), or we can solve it once (ICE-TCP). Regardless of 
whether you do it twice or once, you address the same set of problems. 
One approach just happens to be twice as much work.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 15 Nov 2010 21:46:30 -0500

> middleboxes than the SDP specified in ICE-TCP?

Because I asked that question at the mic, and the answer was they were seeing BFCP/UDP successfully go through legacy middleboxes.  (I was surprised by this - I was expecting we'd have to format the m-line like audio for it to work)

> One approach just happens to be twice as much work.

Not if handling TCP to begin with is a problem for these middleboxes, which is what people are saying in this forum.  In that case, only a UDP-based approach will work. (I don't personally understand why these middleboxes would have any more trouble with TCP than UDP, mind you - and you don't even need ICE-TCP to begin with for a middlebox to handle it)

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Mon, 15 Nov 2010 20:49:27 -0600

> Because I asked that question at the mic, and the answer was they were seeing BFCP/UDP successfully go through legacy middleboxes.  (I was surprised by this - I was expecting we'd have to format th…

I strongly suspect they did not understand the question you asked. They 
almost certainly were answering it as regarding the NAT boxes in your 
diagram, not the SIP ALGs. It is very difficult to imagine a product 
that would fail to proxy TCP connections but which could magically 
deduce the meaning of the token "UDP/DTLS/BFCP."

/a

---

From: Roni Even <[email-masked]>
Date: Tue, 16 Nov 2010 06:50:29 +0200

Adam,
On the middle box case the experience in the past was when talking to the
manufacturer they are willing to add support to UDP new m-lines tpes but are
not that happy to add TCP m-lines. 
Roni

> Behalf Of Adam Roach
> Sent: Tuesday, November 16, 2010 4:20 AM
> To: [email-masked]
> > I think that for the BFCP case the issue isn't as much NAT traversal,
> but rather legacy middlebox "traversal" as well as NAT traversal.
> >

---

From: Tom Kristensen <[email-masked]>
Date: Tue, 16 Nov 2010 14:15:40 +0100

Yes, as I said during the presentation on how it all started; we had
to add support for UDP/BFCP on the middlebox in question back then.
And this lead to the observation and conclusion Roni responded with
below.

I might not have answered Hadriel's question clear enough, due to
"information overload" in the Dispatch timeslot. :-) UDP/BFCP is of
course not in any way a general legacy middlebox traversal approach,
forwarding support is needed.

-- Tom

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

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Nov 2010 08:35:36 -0600

Let me make sure I understand what you're saying.

If what you say is true, then the SIP middleboxes are happy to add new 
SDP tokens to accomodate this use case. "TCP" isn't any harder to parse 
than "UDP," so it can't be that that.

And the middleboxes are happy to forward IP packets according to this 
SDP, potentially rewriting IP addresses and/or ports. Basically, 
changing bytes 12-15, 16-19, and/or 24-27 of an IP packet:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version|  IHL  |Type of Service|          Total Length         | 0-3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Identification        |Flags|      Fragment Offset    | 4-7
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Time to Live |    Protocol   |         Header Checksum       | 8-11
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Source Address                          | 12-15
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Destination Address                        | 16-19
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Options                    |    Padding    | 20-23
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Source Port          |       Destination Port        | 24-27
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 From an ALG's perspective, the only difference between what they need 
to do to IP packets for UDP and TCP is that byte 9 will be "6" for TCP 
and "17" for UDP. They also have to dig a few more bytes down to get to 
the packet checksum, but the math do so this isn't tricky (8 bytes after 
the ports rather than 2).

That's it. So; are you saying that the number "6" is somehow harder to 
forward than the number "17"? Or is it skipping 8 bytes instead of 2 to 
find the checksum? Or is it that the letters "TCP" in the SDP cause 
problems while the letters "UDP" somehow do not?

Because there's really no other explanation for what you're saying.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 Nov 2010 15:46:20 +0100

Hi,

In my experience, the problem with ICE (no matter whether it's UDP or TCP) and middleboxes is that the middleboxes, depending on where they are located in the network, do not always allow bi-directional media plane data (which is required by ICE) until the session has been established.

Regards,

Christer

> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: 16. marraskuuta 2010 16:36
> To: Roni Even
> Cc: [email-masked]
> If what you say is true, then the SIP middleboxes are happy 
> to add new SDP tokens to accomodate this use case. "TCP" 
> isn't any harder to parse than "UDP," so it can't be that that.
> 
> And the middleboxes are happy to forward IP packets according 
> to this SDP, potentially rewriting IP addresses and/or ports. 
> Basically, changing bytes 12-15, 16-19, and/or 24-27 of an IP packet:
> 
>      0                   1                   2                   3
>     |                       Source Address                    
>       | 12-15
>  From an ALG's perspective, the only difference between what 
> they need to do to IP packets for UDP and TCP is that byte 9 
> will be "6" for TCP and "17" for UDP. They also have to dig a 
> few more bytes down to get to the packet checksum, but the 
> math do so this isn't tricky (8 bytes after the ports rather than 2).
> 
> That's it. So; are you saying that the number "6" is somehow 
> harder to forward than the number "17"? Or is it skipping 8 
> bytes instead of 2 to find the checksum? Or is it that the 
> letters "TCP" in the SDP cause problems while the letters 
> "UDP" somehow do not?
> 
> > On the middle box case the experience in the past was when 
> talking to 
> > the manufacturer they are willing to add support to UDP new m-lines 
> > tpes but are not that happy to add TCP m-lines.
> > Roni
> >
> [mailto:[email-masked]] On 
> >> Behalf Of Adam Roach
> >>> ICE-TCP won't help you do that.  It'll help you get through NATs, 
> >>> not
> >> legacy middleboxes.
> >>
> >>
> >>
> >> What are you seeing in the BFCP/UDP draft that makes you think it 
> >> will make it through the middleboxes? It's pretty clear 
> that legacy 
> >> middleboxes will have no clue what "m=application 53280 
> UDP/DTLS/BFCP 
> >> *"
> >> What you have described is a problem either way. We can solve it 
> >> twice (BFCP/UDP and ICE-TCP), or we can solve it once (ICE-TCP). 
> >> Regardless of whether you do it twice or once, you address 
> the same 
> >> set of problems.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 16 Nov 2010 12:38:11 -0500

> forwarding support is needed.

So you got the middlebox vendors to make changes?  Then I'm really confused - why not just make them support BFCP/TCP to begin with if they're gonna make changes?
It isn't rocket science.  (as one data point: I think it took us about 2 days to implement support for it back in 2005)

Even to have the middlebox handle NAT traversal when both UA's are behind NATs and use BFCP/TCP, which is trickier, isn't that hard if they think about it for a while. 

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Tue, 16 Nov 2010 13:20:21 -0600

> In my experience, the problem with ICE (no matter whether it's UDP or TCP) and middleboxes is that the middleboxes, depending on where they are located in the network, do not always allow bi-direct…

Then they can just use TCP. As Hadriel points out: if you're changing 
the middleboxes to support BFCP, then change the middleboxes to support 
BFCP, not some BFCP-inspired protocol with a different transaction model 
and an alternate transport. It's not like ferrying IP packets from one 
interface to another is any harder because of what the protocol number is.

/a

---

From: Bob Penfield <[email-masked]>
Date: Tue, 16 Nov 2010 14:32:55 -0500

It's not quite that simple. A TCP implementation is a bit more involved since it needs to allocate a listening port on each side (which is included in the SDP), but then it has to create port bindings for each new TCP connection. For UDP, it just a pair of ports (one on each side of the SBC).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Tuesday, November 16, 2010 9:36 AM
To: Roni Even
Cc: [email-masked]
Subject: Re: [dispatch] BFCP over UDP

     0                   1                   2                   3

/a

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 Nov 2010 20:47:09 +0100

Hi, 

>>In my experience, the problem with ICE (no matter whether 
>>it's UDP or TCP) and middleboxes is that the middleboxes, 
>>depending on where they are located in the network, do not 
>>always allow bi-directional media plane data (which is 
>>required by ICE) until the session has been established.
> 
>Then they can just use TCP. As Hadriel points out: if you're 
>changing the middleboxes to support BFCP, then change the 
>middleboxes to support BFCP, not some BFCP-inspired protocol 
>with a different transaction model and an alternate 
>transport. It's not like ferrying IP packets from one 

I guess we all have different experience of middleboxes, but in my opinion "BFCP" is not the problem: if the middlebox supports UDP, it should not be difficult to make it support BFCP. It can probably be done with a configuration parameter.

But, as Bob also indicated, implementation wise supporting TCP requires more than just checking what is carried on top of UDP.

At this point I don't have an opinion whether BFCP/UDP is a good thing or not - I am only giving my input to the why-TCP-is-difficult-with-middleboxes discussion :)

Regards,

Christer

---

From: "Tucker, Mike" <[email-masked]>
Date: Tue, 16 Nov 2010 11:47:31 -0800

I believe that enabling existing middleboxes to support BFCP-over-UDP will be very similar to the experience of enabling middleboxes to support the far-end camera control channel (FECC) which is used in video conferencing.

Like BFCP-over-UDP, the FECC channel is also an application channel which uses UDP.  

When FECC was first implemented in SIP several years ago, our experience was:

1) Many middleboxes supported it without changes because it was "just another" UDP-based channel
2) Other middleboxes quickly added support, just by adding support for the m=application "media" line

We have also found existing UDP ICE solutions that will support FECC channels without changes.  We think these ICE solutions will also support UDP-based BFCP channels.

We have yet to discover a middlebox which supports BFCP-over-TCP.  To us, this indicates that supporting a TCP-based channel will require great effort by the middlebox vendors.

Tandberg's experience seems to support the premise that BFCP-over-UDP will be supported in middleboxes without requiring large changes in the mddileboxes.

Mike Tucker

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Tuesday, November 16, 2010 1:20 PM
To: Christer Holmberg
Cc: [email-masked]; Roni Even
Subject: Re: [dispatch] BFCP over UDP

> In my experience, the problem with ICE (no matter whether it's UDP or TCP) and middleboxes is that the middleboxes, depending on where they are located in the network, do not always allow bi-direct…

Then they can just use TCP. As Hadriel points out: if you're changing the middleboxes to support BFCP, then change the middleboxes to support BFCP, not some BFCP-inspired protocol with a different transaction model and an alternate transport. It's not like ferrying IP packets from one interface to another is any harder because of what the protocol number is.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 16 Nov 2010 14:54:39 -0500

Sure, that's one of the reasons it takes more than 5 minutes to implement. :)
But once they're willing to make *any* changes, one wouldn't expect TCP to be that much more work.  By that I mean once a vendor is willing to go through QA, docs, and creating a new release and such, the diff for development should be noise... unless it's really hard.

Of course different architectures may make it really hard.  Like an IMS decomposed BGF solution may make it a lot harder to do this (but that's what you get for going with a decomposed model).

-hadriel

---

From: "Roni Even" <[email-masked]>
Date: Wed, 17 Nov 2010 06:53:40 +0200

To clarify, FECC payload which is H224 is specified in RFC 4573
Roni Even

> From: Tucker, Mike [mailto:[email-masked]]
> Sent: Tuesday, November 16, 2010 9:48 PM
> To: Adam Roach; Christer Holmberg
> Subject: RE: [dispatch] BFCP over UDP
> 
> I believe that enabling existing middleboxes to support BFCP-over-UDP
> will be very similar to the experience of enabling middleboxes to
> support the far-end camera control channel (FECC) which is used in
> video conferencing.
> 
> We have also found existing UDP ICE solutions that will support FECC
> channels without changes.  We think these ICE solutions will also
> support UDP-based BFCP channels.
> 
> We have yet to discover a middlebox which supports BFCP-over-TCP.  To
> us, this indicates that supporting a TCP-based channel will require
> great effort by the middlebox vendors.
> 
> Tandberg's experience seems to support the premise that BFCP-over-UDP
> will be supported in middleboxes without requiring large changes in the
> mddileboxes.
> 
> Mike Tucker
> 
> 
> > In my experience, the problem with ICE (no matter whether it's UDP or
> TCP) and middleboxes is that the middleboxes, depending on where they
> are located in the network, do not always allow bi-directional media
> plane data (which is required by ICE) until the session has been
> established.
> 
> 
> BFCP, not some BFCP-inspired protocol with a different transaction
> model and an alternate transport. It's not like ferrying IP packets
> from one interface to another is any harder because of what the
> protocol number is.
> 
> /a