Subject: [dispatch] Rough notes

From: "Elwell, John" <[email-masked]>
Date: Thu, 11 Nov 2010 10:19:15 +0100

Report on RTC-Web Workshop. 
Harald: Hoping to bring some work to the IETF and I am available this week to anyone wishing to discuss.

Preliminary deadlines for IETF#80.

Telepresence - Allyn
James Polk: Wonder if whole solution is expected to be in any one document.
Chair: Framework.
Peter St. Andre. Wanted clarification we would be extending, not changing, IETF protocols such as SDP.

Chair: Who is interested - 25.

Chair: Who would be prepared to work on - about 15+.

Hum: Who is in favour of moving ahead with charter? Unanimous in favour.

INFO event package for DTMF - Hadriel
Chair: Not much difference between 1 and 3 - could do AD-sponsored with INFO-package, but probably wouldn't succeed because too much community interest.

Keith: IETF is not going to solve this problem for you (the fact that people won't change their existing implementations based on INFO). So IETF doesn't need to do that work, and therefore only way to go is individual submission, which is allowed for INFO packages. And if want to document and not as an INFO package, I don't want to know!

Chair: ????

Keith: I thought we had made the INFO package framework sufficiently flexible.

Hadriel: I don't want an INFO package - would rather have an RFC that says what people do now.

Chair: Further clarification that options 1 and 2 refer to documenting what is done today, not an INFO package.

Hadriel: Correct.

Paul K: If we could go back in time I would go for INFO package, but that is not the world today. Adding the INFO package would just increase number of specs. Options 1 and 2 I wouldn't mind.

Andy Hutton: I agree with last two speakers, but not sure we even want the IETF to rubber stamp anything that is out there. Also question whether this is DTMF - it is just user input, and we would not call it DTMF if we were doing it properly, e.g., it would not have duration of tones.

Hadriel: DTMF relay out there does have duration of tones.

Christer: We had a strong agreement in the past that we MUST NOT generate any usages using legacy INFO. Yes, there is indeed a package in 3GPP, and will be decided next week whether to register it. It is very simple and does not have duration. Perhaps there should be a dialog with 3GPP, because defining a new one, particularly if not backward compatible with the 3GPP one, would not be good.

Keith: Agree with Christer that we should not do any work on any INFO usage that is not an event package. Would like people to use the 3GPP event package and don't mind other people generating others (and use individual submission if desired), but IETF should not do that.

Marshall: Given that there is a legacy solution documented on a vendor's website, are there IPR issues?

Hadriel: Submitters would have to declare it.

Mary: Suspect there may be IPR from a company that no longer exists - should be investigated.

Cullen: Not aware of Cisco IPR.

Chair: Anyone thinks anyone should go ahead and bring this event package for working on in the IETF? Nobody.

Chair: Who believes we should document the legacy INFO usage for DTMF? Only Hadriel.

Chair: Would anybody object to AD-sponsored?

Keith: I have already objected to that.

Robert: Disconnect I was hearing is between documenting existing practice versus building something that is the basis of a standard. No problem writing an informational document on what is in field - many paths. We can worry about which path when that I-D exists.

Jon Peterson: An individual can write a draft - this WG doesn't need to care.

Mary: If Hadriel wants to do this he can go off and do it. We are not, in the RAI area, documenting the legacy usage of INFO.

BFCP over UDP - Tom Kristensen

HEALTH WARNING: THIS IS LONGGGGGGGGGG

Adam Roach: This is characterised as minor enhancement, but it is not backwards compatible and will not interoperate with existing implementations. ICE-TCP has dramatically different from earlier. Toredo does ????
So if we do this, instead of having a generic solution, we have a one-off that is not compatible.

Tom: If we had a choice we wouldn't extend BFCP. But this is not a completely new protocol. You can negotiate the transport to choose which to use.

Spencer: Would you expect one to displace the other, or would people have to implement both? So how would anyone write a profile on this.

Tom: I think they would support both, especially if they have an existing BFCP implementation. Depends on use case.

Spencer: In IETF you can't mandate picking one, but would somebody else do that?

Tom: Our implementation starts with one, if it doesn't work tries the other.

Spencer: What is definition of large packet size?

Tom: When it would get fragmented.

Spencer: Do you anticipate package bodies that IP fragmentation would accommodate?

Tom: May end up setting a maximum size, but our implementation doesn't get large enough to fragment.

Keith: Adam said you are creating new protocol. Yes, you are, because it updates the existing RFCs and have eliminated the possibility of building a TCP-only implementation.
2nd point: You haven't specified what happens when you exceed the MTU size. SIP says you have to use TCP at the point - should specify something for BFCP too.
3rd point - are conferencing servers not going to need other things over TCP such as MSRP?
Chair: Can you clarify how this eliminates a TCP-only implementation.
Keith: Because it updates the RFC.
Tom: As written in current draft, correct, but can be changed to allow TCP only. Or make it an extension rather than update.
Tom: On MTU size, we give a maximum packet size, and if you can detect MTU size, can use that.
Tom: On MSRP, may want to do it, but my company doesn't have plans to do it - why does that need to stop a solution for BFCP?

Roni: Original decision on TCP for BFCP was because we didn't have DTLS at time. Also I am not aware of any current uses of BFCP except for the applications already mentioned, which encounter the problems with TCP. So those applications were forced to use UDP. But try TCP to start with and then fallback to UDP if it fails. I support this activity.
Gonzalo: For clarification: Roni, why does HTTP work and not TCP? - ???? Did I capture this correctly?
Roni: Because SBC used.

Hadriel: We have to decide where to dispatch this - is there not already an appropriate group?
Gonzalo: We are in process of closing down XCON, and TSV area not interested, so result was to bring it to DISPATCH. Could AD sponsor - not necessarily a need to charter a WG.

Hadriel: Problem as Tom stated it was that some middleboxes don't support TCP. So why would an m-line containing BFCP and UDP would work through those middleboxes? Why would it solve it? Has it been tested?
Tom: Easier to solve, and does seem to work fine today.
Hadriel: Good. So I support this activity.

Hadriel: With UDP, we need the guy behind the NAT to send UDP first - is this a real problem? Is server ever behind NAT.

Tom: Yes.

Hadriel: So have to solve that - not solved in draft at present.

Tom: ????

Hadriel: Trying to help, but we really need to make sure we can get through middleboxes.

Keith: In 3GPP we made a decision for TCP for ????

Peter Musgrave: It's a hack.

Tom: Yes, but it works.

Gonzalo: Comments have been made again and again, and problems haven't been addressed in the draft. But there does seem to be a problem to be solved. Should look at Toredo.

Tom: On fragmentation, it is dealt with in draft, and if anyone needs very large messages BFCP probably isn't the right protocol.

Hadriel: What if I want something bigger than maximum size.

Tom: BFCP is meant for token control.

Hadriel: How big can the messages get? 100 byte range?

Gonzalo: Brought this issue up when BFCP work was started. Also proposed some time ago SIP event package to transmit the bigger parts, e.g., transporting the whole floor queue.

Hadriel: The concern is when messages get up around the 1300 byte region - there are possible ways to handle this, but I am trying to understand why the draft ignores the problem at present. Is it because nobody in practice would want to do this?

Tom: True, we have ignored it because you won't see these messages.

Chair: Tom will take an action to address this issue.

Hadriel: Would define an INFO package to carry in SIP.

Tom: Was considered, but rejected.

Alan Johnston. I support having a solution to this problem. As co-chair of XCON, I confirm what Gonzalo and Keith have said, but I don't think we considered this sort of use case for BFCP. Hope you take the advice from Hadriel and look carefully at what you need to solve, e.g., separate ALG issues from NAT issues, and also consider Toredo.

Spencer: ??? Once you start losing fragments, success rate starts going down.

Gonzalo: Main problems has been getting the authors to do their homework. Need to come back and say whether Toredo works or not. We don't want the same discussion yet again in Prague.

Adam: If concerned about speed that ICE-TCP is moving forward, please go to MMUSIC and help it move forward.

Gonzalo: ICE-TCP is moving forward quite fast now.

Chair: Several issues have been highlighted. How many people want to work on BFCP over UDP. 9 in favour, 6 against.

Chair: Who doesn't want BFCP work through middleboxes? None.

Adam: If there are techniques that can be done to make BFCP over TCP work through middleboxes with ICE-TCP, it is not too late - ICE-TCP not yet finished.

Hadriel: It is not just NATs - the problem is middleboxes.

Chair: So is consensus there is a problem, but no consensus on how to solve the problem. A certain amount of support for a solution based on Tom's proposal and he should continue to work on it and we can ask again.

Christer: We are talking about peer-to-peer, correct?

Tom: Yes.

Andrew Allen: Need an analysis of what the problems are that we are trying to solve.

Roni: Have to distinguish between short term and long term solution.

Chair: We had a hum, and this draft needs to be reworked. Perhaps what Andrew was stating is more background and motivation in the draft.

Andrew: If it solves only a specific problem and not the general problem, no good.

Hadriel: Wants clarification on how it works at present, in terms of how we initiate the communication. How does it get through SBCs?

Hadriel: Do we want to solve general problem of working through SBCs, not just for BFCP? This is the first protocol for which I have heard this problem.

Adam: If this falls down in cases where ICE-TCP falls down, we need to do more work.

Chair: Tom has sufficient feedback to have another go.

Joerg: Who is guarantee that the near-term solution is going to be done before ICE-TCP?

Chair: As Tom explores some of the issues raised ....

Hadriel: Assuming ICE-TCP still doesn't magically work through SBCs, it won't solve the problem.

Tom: Conclusion is more work is needed, both with this and with ICE-TCP.

John