Draft Minutes of the DISPATCH WG Session at IETF 79
=========================================
Meeting chaired by:
Minutes produced by Mary Barnes based on detailed notes
(included below) by John Elwell and Paul Kyzivat.
Jabber transcript at
http://jabber.ietf.org/logs/dispatch/
Slides presented included in the proceedings.
Thursday, Nov 11, 2010
================
Topic: Agenda
Bash
Discussion led by: Chairs
The chairs summarized the agenda/topics for discussion.
In
terms of
status all the information is kept up-to-date in the DISPATCH WG wiki.
The
wiki contains a summary of the process, deadlines for the upcoming
meeting, as well as a detailed summary as to the status of each of the
previously discussed topics.
A potential new area of work was briefly highlighted: RTC-Web.
Background: RTC-Web workshop
Related documents:
Topic: Telepresence
Discussion led by: Allyn Romanow
Charter proposal: Telepresence
Related Documents:
Allyn
provided an overview of the key charter changes since IETF-79 that had
been discussed and agreed on the mailing list.
There was
a question as to whether there would be a single document as a
deliverable. The chair responded that likely there would be a separate
framework document. Peter St. Andre had raised an issue on the
mailing list with regards to the proposed WG in terms of whether
existing protocols (e.g., SDP) would be changed or extended. The
intent of the WG would be to extend existing protocols as required -
the charter will be updated to reflect such.
A vote was taken
as to who in the WG is interested in this work - 25+ raised hands.
Another question was asked as to who would be willing to
contribute to the work - 15+. A final hum vote was taken on
whether folks believed the work should be chartered.
Conclusion: There was unanimous support to move forward with the charter and request AD/IESG approval.
Topic: Info Event Package
Discussion led by: Hadriel Kaplan
Mailing List Discussion
Relevant document: draft-kaplan-dispatch-info-dtmf-package
The
discussion centered around whether one of the legacy implementations
for using INFO to carry dtmf digits (tones & durations) should
be standardized (either individual AD sponsored or within a RAI area
WG) or whether an INFO package should be defined per draft-ietf-sipcore-info-events.
It
was noted that there are multiple legacy mechanisms in place - e.g.,
3GPP and several very old individual drafts, some of which may have
IPR.
Two questions were posed:
1. Should the WG endorse an INFO package for DTMF? The response indicated that there was zero interest in doing so.
2.
Who believes the legacy usage of DTMF should be documented? The
response indicated that only Hadriel has an interest in doing so.
Conclusion: There
is not interest in standardizing DTMF behavior (either an INFO package or legacy usage of INFO).
However, if an individual wants to pursue publication of the
legacy behavior, there are mechanisms in place to do so - e.g.,
historic via RFC editor.
Topic: BFCP over UDP
Discussion led by: Tom Kristensen
Past discussion threads:
Relevant documents:
draft-sandbakken-dispatch-bfcp-udp
There
was a general concern raised that this proposal is basically defining a
new protocol. Background was discussed in terms of this work
being previously proposed in the XCON WG, but diverted to DISPATCH
since XCON WG is close to completing chartered deliverables. It
was also noted that a decision was made in XCON at the time BFCP was
being developed to support TCP only. Although, it was highlighted that
this particular problem was not considered at that time.
ICE-TCP
was frequently suggested as a preferred solution
option. However, that doesn't resolve one of the primary issues
that
provided the impetus for this solution proposal in that not all
middleboxes support TCP. It was suggested that this proposal
needs to clearly separate ALG issues from NAT issues. The
current proposal is also not adequate in terms of evaluating other
solution
options. It was suggested that Toredo might solve the problem.
In addition, the current proposal does not adequately address the handling
of large messages. It was noted that other
alternatives had been considered during the developement of BFCP, such
as a SIP event package to handle large BFCP messages.
A
poll was taken to determine level of interest in working on this
problem (i.e., BFCP over UDP): 9 raised hands in support of solving
this problem, 6 against. Another question was posed to determine
the level of interest in solving the more basic problem of getting BFCP
through middleboxes - there was unanimous support for working on the
middlebox problem (i.e., there was no one that did not want to solve
the middlebox traversal problem)
Conclusion: The proposal needs to be updated to address the concerns raised in order to determine the best way forward.
=======================================================================================
DISPATCH WG meeting notes by John Elwell:
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.DISPATCH WG rough notes by Paul Kyzivat:
15:30-16:15 Hadriel Kaplan Info Event Package for DTMF
Problem discussion
draft-kaplan-dispatch-info-dtmf-package
Keith
D not in favor of the options. He thinks individuals can create info
packages, without the ietf, and that the ietf shouldn’t be doing that.
I stated not in favor of new info pkg – would accept publishing something that documents the existing usage, or doing nothing.
John E agree with Keith/me.
Christer
thinks rules in new info prevent publishing the existing one. He also
says that 3gpp has an info package that is not yet registered but is
about to be.
Mary suggested that a large company no longer in
existence (Nortel) might have had IPR in this the DTMF-Relay that is
currently documented only on the Cisco web site. Cullen said he wasn’t
aware of any Cisco IPR.
Show of hands – nobody wants to do an info package for this.
Show of hands about whether we should do anything about this – only Hadriel said yes.
Asked if anyone would object to Hadriel bringing this in as a Historic document. Keith objected to that.
Robert
said that if somebody has the energy to do this, there are many ways to
do it. And if its historic there won’t be a lot of objections to it.
Mary says we are never talking about this subject again in a WG.
16:15-16:45 Allyn Romanow Telepresence
Charter proposal: Telepresence
draft-romanow-dispatch-telepresence-use-cases
draft-romanow-dispatch-telepresence-prob-statement
Agreed to request ADs to form the group.
16:45-17:15 Tom Kristensen BFCP for UDP
Discussion threads:
http://www.ietf.org/mail-archive/web/dispatch/current/msg02583.html
http://www.ietf.org/mail-archive/web/tsv-area/current/msg00639.html
draft-sandbakken-dispatch-bfcp-udp
Adam
comments that this is defining a new protocol, and that it will cause
interop problems – everyone will need to implement both. Concerned that
this establishes a bad precedent.
Tom of course disagrees.
Spencer
generally agrees with Adam. He asks if one of these would displace the
other, or if people would have to implement both. Tom says his impl
uses UDP as default. If can’t connect with that, will try TCP. (They
implement both.)
Spencer asked about packet fragment. Tom says in
his use there will never be fragmentation, but he has no answer for how
they would handle fragmentation in general.
Keith agrees with Adam
that this creates a new protocol. He says the way this updates the
specs it has made it impossible to create a TCP-only implementation. He
also brought up fragmentation issues. Tom is willing to rewrite things
so this is just an extension. Keith also said that we need a general
solution for tcp because we will need MSRP for chat in this context.
Roni
Even asked about reason why TCP was chosen originally. Said reason was
security – TLS – that there was nothing for UDP at the time. (Now there
is DTLS.) He supports Tom – says this is what conferencing vendors do.
Hadriel
is sympathetic to Tom. But he asks – aren’t we just supposed to
dispatch this. The appropriate group would have been XCON, but that is
being closed down. Gonzalo doesn’t foresee starting a group for this –
could be AD sponsored. He asks what is preventing the TCP from working
– it is actually SBCs that don’t support TCP relay. Hadriel supports
this. But he is concerned with how the pinhole gets opened – need
packets to be sent right away. And this doesn’t solve that currently.
Peter Musgrave said this was tried at sipit. He says it’s a hack, but one they intend to implement.
Gonzalo
surprised that fragmentation hasn’t been addressed – that it has been
brought up as an issue three years ago. But he agrees with Hadriel that
this is a problem that needs to be solved. He wants them to investigate
the solutions like Teredo for getting tcp to work.
Alan Johnston
supports having a solution to this problem. But he also supports what
Adam and Gonzalo said. He wants Tom to take Hadriel’s advice to
look again closer at the other alternatives.
Poll on who wants to work on a UDP solution to this. Nine hands. Six are opposed to working on the UDP solution.