[AVT] Draft proceedings text from IETF #79 (Beijing)

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Wed, 01 December 2010 23:36 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 8959A3A682A for <avt@core3.amsl.com>; Wed, 1 Dec 2010 15:36:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.517
X-Spam-Status: No, score=-105.517 tagged_above=-999 required=5 tests=[AWL=0.732, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id m9fybYuKYsAS for <avt@core3.amsl.com>; Wed, 1 Dec 2010 15:36:12 -0800 (PST)
Received: from smail3.alcatel.fr (smail3.alcatel.fr []) by core3.amsl.com (Postfix) with ESMTP id BAC273A681A for <avt@ietf.org>; Wed, 1 Dec 2010 15:35:51 -0800 (PST)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com []) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oB1NaqtC007547 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <avt@ietf.org>; Thu, 2 Dec 2010 00:36:52 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([]) with mapi; Thu, 2 Dec 2010 00:36:52 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: "'IETF AVT WG'" <avt@ietf.org>
Date: Thu, 2 Dec 2010 00:36:51 +0100
Thread-Topic: Draft proceedings text from IETF #79 (Beijing)
Thread-Index: AcuRsKDKXN1ehoNSQIelT/6nf1dvTw==
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE21E363718@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on
Subject: [AVT] Draft proceedings text from IETF #79 (Beijing)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Dec 2010 23:36:15 -0000

I've compiled the notes from the notetakers (your efforts gratefully appreciated) into these draft proceedings.

Please review and comment if corrections, additions, or whatever are required.




Audio/Video Transport (AVT) Working Group


Chairs: Keith Drage , Roni Even

Monday, 8 November 2010 at 13:00-15:00 (Valley Ballroom B)

Introduction and Status Update Chairs

Slides avt-0.

No agenda changes identified.

1 draft in RFC editor queue, 9 in IESG processing, 3 waiting for proto write-up. There are plenty of drafts needing review,  update, discussion. Next steps are: progress various RTP payloads, address several new topics.

On draft-ietf-avt-app-rtp-keepalive-09, one IESG discuss was still open. Robert said it would be addressed this week.

For draft-ietf-avt-srtp-not-mandatory-07, it was noted that there may be some new work to do in future regarding security  requirements; this does not impact this draft proceeding.

Glen Zorn undertook to take on the editorship of draft-ietf-avt-rtp-g718-03.

Colin Perkins: individual draft about draft-perkins-avt-srtp-vbr-audio-04 should also be considered.

Roni: it was not a WG item, I may have missed it.

Port Mapping Between Unicast and Multicast RTP Sessions

Ali Begen presenting.

Related draft: draft-begen-avt-token-for-portmapping-01

[Note -02 version of the above document was available by the time the meeting started.]

Slides: avt-6.

Jonathan Lennox: When are two streams "on the same server" for the purposes of the token?

Ali Begen:  The server can define a single PT port for all sessions.

Jonathan Lennox:  How does a client know when to get another token?

Ali Begin: Every PT defines a separate port.

Ali agreed to make some clarification text.

Magnus Westerlund:  Replay attacks are possible as long as a token can be stolen and the source address of a request forged.

Ali Begin: If the token is stolen and the IP address used, then there is a chance of a replay attack. Only fix for that is  shortening the token validity time.

Magnus Westerlund:  The server can verify that client wants the stream [that the client appears to have requested], e.g., by  returning RTCP [which reduces the impact for forged requests for streams].

EKR (via Jabber): It sounds like the threat model magnus is considering is one where address forgery is practical but on-path  attack is not. Correct?
 That seems plausible.

Magnus: with cookie, once you use it, it's expired. With token you're open to reply attacks.

Collin Perkins:  I have similar concerns.  It seems strange that the token appears in only some messages back to the server,  and we need to consider replay and spoofing attacks.

Magnus: Cookie is different, cannot replay the cookie because it expires as soon as you use it.

[Much discussion of various tradeoffs in how tokens are used and the breadth of applicability of various approaches.]

In terms of resolution, parked for future deliberation on list.

Chair (Keith Drage):  Are we going to replace the existing WG draft with this one?  Does anyone object?

Colin: I don't care whether you replace the existing draft, or just paste text from this draft. Let's move forward with this.

Cullen (via Jabber): I think this is a better basis for going forward than the the current WG draft."

Glen Zorn:  I haven't read this draft in a month. There is a lot of stuff in the WG draft that is not in this draft, but is  left to be completed.  Shouldn't these parts be fleshed out before we adopt this

Ali: Believes the -02 version of the draft (issued recently) does address this.

Magnus: discussion about which draft to adopt is irrelevant compared to the security issues. Need to nail down the  engineering.

Dan Wing:  There are networks being deployed that contain source filtering.  The Begin draft is the simple solution; the  existing draft is a complex solution that no one is interested in implementing.  Can we rely on source address filtering?  If  so, we can use the Begin draft.

Ali Begen:  In the "cookie" approach, the cookie was specific to each client port, the "token" [in this draft] is specific  only to the client IP address.

Jonathan Lennox:  Would it be possible for the server to tag the token in regard to whether it was specific to the client  source port, so we could use it in both modes?

Colin: to be clear, this is a good place to start, support moving it forward.

Ali Begen:  Use of one token for each client simplifies things, as one token can be used for multiple streams.

Chair (Roni Evin):  We want to finish this before end of year because other drafts depend on this work.

EKR: Trusting source addresses is not part of any Internet threat model I'm aware of. I'd be interested in hearing from the  security area about what they think of that claim.

Chairs: Will make the final call on list to adopt or not adopt the text of the draft in place of the exist WG draft. Will  decide later the naming of the document if that is successful.

Explicit Congestion Notification for RTP over UDP

Colin Perkins presenting.

Related draft: draft-ietf-avt-ecn-for-rtp-03

Slides: avt-4.

* Issue -- ECN Nonce

Support for ECN nonce was removed in -03 following email discussion around anti-cheating mechanisms raised by Bob Briscoe.  Asked for confirmation from the meeting.

No objection from the meeting.

Chairs asked Colin to post to the list seeking confirmation.

* Issue -- Initiation mechanisms

Draft currently specifies 3 mechanisms for initiation:
- Probing using occasional ECN-marked RTP packets, with RTCP feedback
- Leap of Faith
- STUN-based probing for use with ICE

- MUST implement RTCP-based probing; leap-of-faith is OPTIONAL
- If ICE is implemented then MUST implement STUN-based probing, but MAY fall-back to RTCP-based probing if that fails

Jonathan Lennox: Asks for clarification of the "Suggestion".

Colin: Clarifies. Using STUN needs a STUN extension, This means it will not work with an ordinary STUN implementation.  However reasonable to expect that an ECN implementation has also implemented the STUN extension - there is no guarantee of  that so the text will have to cover it. Describes various complex failure situations, including endpoints that implement some  but not all of the extensions envisioned in this draft.

Colin Perkins:  The feeling I'm getting is that people are generally happy with this proposal.

Colin to take proposal to list as a specific proposal.

* Issue -- Combining ECN packets

In Translators ECN packets can be split or joined - what happens to ECN-CE markings on such packets? Current solution based  on TCP rules. Bob Briscoe proposed an alternative solution.

[Discussion of alternative proposals for how to handle the ECN
markings when combining packets.]

Lars: Bob Briscoe's proposal may work slightly better, but the complenxity it adds makes it not worth it. Should follow TCP  as there is some evidence that it worked.

Jonathan: do not spend cycles on the enhancement of an enhancent of an enhancement. Are there any implementations of this?  Colin: don't know if it's integrated in any product -- I work for an univeristy -- but seem to remember that it's been  impemented.

Chairs conclude no need to change the working group draft.

* Issue -- ICE Options IANA Registry

RFC 5245 states that an ICE options registry exists, but doesn't define it
> This draft needs to register an option into this registry!
> Solutions:
        - Define the registry in this draft? (preferred)
        - Submit a separate draft to MMUSIC?

Lars: the issue about ICE (the doc updates it) should go in a separate draft. Nobody will find it here. It would be a 1  pager, AD sponsored. Not a big deal.

Colin: alright, will put it in a separate draft.

[Note: See MMUSIC mailing for further discussions and progressions on this.]

RTCP Report Extension for Feedback Suppression

Qin Wu presenting.

Related draft: draft-wu-avt-retransmission-supression-rtp-06

Slides: avt-1.

* Issues addressed

bullet: Issue 1

Jonathan: NACK could be sent by some other element than the server.

Ali: we should be provide some informative text, but the semantics should be simple.

Jonathan: there is a distinction between NACK (packet not received) and "there is someone in between".

Conclusion that a new message should be defined - semantics would be simpler.

Discussion regarding the more complex RTP topologies, some of which are described as "broken", and whether or not they should  be discussed in the draft.

Magnus: I would prefer if we skipped these switching MCU use cases. Colin: agree with that.

[Discussion ran out of time - summary and then continue on list.]

See Thursday for discussion on whether should be progressed as a working group draft.

RTCP XR for inter-destination media synchronization

Ray van Brandenburg presenting

Related draft: draft-brandenburg-avt-rtcp-for-idms-02

Slides: avt-2

[Ray van Brandenburg asks whether AVT should take this over from

Ali: if we do this in AVT, since this is already specified by ETSI, can we make any changes?

Chair (Roni Even): When a document becomes a WG document, then the IETF can change it.

Ali Begin:  Will TISPAN go along with any changes the IETF makes?

Magnus Westerlund: I think we should do this. I have done some work in this area and had grad
students who have done so and I suspect that there will be substantial
improvements to the current TISPAN proposal.

Colin Perkins: This would have to change quite radically. We will probably want a different RTCP XR code for the
forward direction [than is used in the reverse direction]. Will need it for things other than reporting. Will TISPAN be happy  with that?

Ali: I'll go through the draft carefully.

Magnus Westerlund: Does the ETSI document also cover how you identify the different time sources? Warns that NTP time is not  perfectly consistent [between elements], possibly inconsistent enough to interfere with this mechanism.

Chair conclusion: Progress as working group draft for a further iteration.

Additional Parameters in for H.264 Video

Tom Kristensen presenting.

Related draft: draft-kristensen-avt-rtp-h241param-01

Slides: avt-3.

Jonathan Lennox:  Why is max-fps different from a= framerate attributes? That is, the SDP attributes defined for various  codecs that describe/limit their framerates.

Tom Kristensen:  Because it applies to all codecs present and future.

Hadriel Kaplan:  My video people say we need this [parameter].

Using approximate authentication SRTP

Gabor Feher presenting.

Related draft: draft-feher-avt-approx-auth-srtp-00

Slides: avt-5.

Magnus Westerlund:  What about the lower layers? UDP doesn't accept any bit errors. [Packets with bit errors will be  discarded by the lower layers, making it irrelevant if the SRTP lay tolerates bit errors.]

Gabor Feher: We have UDP Lite.

Magnus Westerlund:  Even if we have UDP Lite, how many link layers let bit errors through rather than being detected [and  deleted] by the link layer?

Gabor Feher: It is possible with implementation of different link layer drivers to receive packets with bit errors.

Magnus Westerlund: I was wondering what you are considering doing with the other layers?  There are huge problems with  deployment for this type of technology. I see very little possibility to deploy this in a useful way.

Gabor Feher: We would like to first show the benefits of this approach.

Chair (Roni Even): There are two issues:  We try to understand if this is a real problem, before [attempting to solve the]  problem.

Gabor Feher: You can have better video quality. I've posted the benefit on the list.

Colin Perkins: This can clearly offers a benefit in certain cases. And it can't cause problems to assign a code point.  This  seems to be a good candidate for an "Experimental" RFC.

Chair (Keith): Move the discussion on to the list.

Session ended at 15:00.

Thursday, 11 November 2010 at 13:00-15:00 (Garden Ballroom 3)

Introduction and Status Update Chairs

Slides: avt-11

No agenda changes identified.

Chair (Roni): RFC 6051 was published on monday.

Jonathan Lennox referred to an issue on IANA registration that he had raised on the list.

Roni: I checked with previous chairs and we will respond on the list and decide what to do with these registries.

Audio Levels status

Roni Even summarising status.

Slides: avt-11.

New milestone setting

Slides: avt-11.

Roni: We think following items are ready for milestones setting:

1. RTP HEader extension for mixer to client audio level indication

2. idem for client to mixer. RTP XR for audio level indication between client and mixer
 was presented in stockholm.

3. TCP report for retransmission suppression. Should be indication for retransmission suppression.

4. Guidenlines for the use of variable bit rate audio with secure RTP. Colin said it can be informational or BCP. Cullen said  informational.

Peter Musgrove - The audio level stuff is interesting and i will review.

Keith: is everyone OK with these bullets as descriptions of the work? Note revision of 3).

Cullen (via Jabber): I would prefer the VBR to informational not BCP.

Roni: first 3 should be standards, VBR for informational.

Keith: Who is willing to work on these items.

For 1: 4 people indicate (plus Cullen via Jabber)

For 2: Same.

For 3: 7 people indicate.

For 4: 4 people (plus Cullen via Jabber).

For all four work areas, there was no objection to working on these items.

Keith: There seem to be people willing to work on all four items. No one is opposed. We will ask the same questions on the  list to confirm this.

Content Splicing for RTP Sessions

Jinwei Xia presenting.

Related draft: draft-xia-avt-splicing-for-rtp-00

Slides: avt-7.

J. discusses main changes to draft

Next steps:
1)      Whether peiple think a translation can completely perform RTP splicing?
2)      Will adopt this work as informational one to direct actual implementationi of RTP splicing.

Chair (Keith): There has been some discussion on list, some people are of the opinion that the necessary protocols already  exist. Do we need to standardise anything or is something more like a guide necessary?

Chair (Roni): The current documents are not clear enough how to do such a thing, so something information might be needed.

Colin: Agree with Roni, standard is not needed, but there is confusion on the list so an information draft might be useful  and no objection to people working on this.

Jorg Ott: No standards work the receiver is not supposed to know about this so nothing to communication. Information draft  might be useful.

Magnus: There are a number of issues relevant for the AVT group to discuss on how to use fields.

Chair (Keith): The next step is to proceed with some redrafting as author draft (informational), with a view to getting it  into a shape as an informational draft where the working group can made a decision to work on it.

Colin: This group should be sympathetic to anybody bringing information

Cullen (via jabber): On the topic of an information document, I think we have more things to do and the book "RTP: Audio and  Video for the Internet" seems to be a better approach for helping educate people.

Colin: Buy my book but it won't help with this problem.

Monitoring Architectures for RTP

Roni Even presenting.

Related draft: draft-hunt-avt-monarch-01

Slides: avt-8.

AVT has chartered milestone due feb 2011
. Conference call was arranged to 14 september to discuss the scope in more detail.  This presents the outcomes of the conference call.
 So far, only Qin Wu has volunteerd to work on document, without more  comitted people, it's not feasible to start this large piece of work (two people willing to review).

Chair (Keith): Do we have people prepared to work on this?

Chair (Roni): We have 10 documents relating to metrics waiting for an architecture.

Colin: Cannot commit to text but will try to review.

Dan: Would very much like to help.

Robert Sparks: How many people on the recent call - About 10.

Chair (Keith): Is a monitoring architecture the right way to give guidance on how to write monitoring drafts.

Colin: Not sure if this will help write XR drafts but would provide guidance.

Jorg Ott: XR drafts not limited to monitoring.

Chair (Keith): What do you all think of the design team method we used for this document? Is that the way to go?

Roni: I think so, it helps in the review process.

Chair (Keith): Ok, we agree to ask Geoff to make a revised document. I will try to set up a conference call before christmas,  so we can discuss progress.

RTCP XR Report Blocks for Realtime Video Quality Monitoring

Qin Wu presenting.

Related draft: draft-wu-avt-rtcp-xr-quality-monitoring-04

Slides: avt-9.

Discusses changes since last version. Discusses different transport and application layer metrics and associated reporting  blocks. Do we wait for monitoring architecture completion before progressing work?
Request to accept as WG item.

Chair (Keith): Keith: with respect to WG item, we have only had one review on the list.

Dan: PMOL experience is that the framework and implementation can be run in parallel but framework might take longer.

Chair (Keith): Should we add this to the agenda of monitoring architecture meetings?

Colin: This would make sense

Glen Zorn: Doing this is parallel does not hold things up and thinks it is more efficient.

Chair (Keith): If conf calls on monitoring arch occur this will be added to the agenda.

Switching from unicast to multicast for multicast short time-shift

Roni presenting on behalf of Peilin Yang.

Related draft: draft-yang-avt-switch-multicast-short-timeshift-00

Slides: avt-10.

Roni: Issue with client not knowing when to switch from unicast to multicast. Problem is that for interactive services of  multi-cast sessions, each user has own unicast session, resulting in multiple unicast sessions.
Solution would be to have  unicast session speed up to catch up with multicast (for example using RTSP). Another option would be to use RTCP.

Colin: The server would know when the multicast and unicast sessions are in sync. The client does not need to know because  the server can tell it.

Jorg: You could send extra packets so the client knows which unicast packets are associated with which multi-cast packets  (i.e. using beacons)
Hassnaa: but how would you determine the frequency and make sure it fits with the user experience?

Discussion between JO, CP, Hassnaa, Magnus W regarding the mechanism for sync.

Roni: There is preference for RTSP solution. author to check and see if there are issues there. No conclusion will need to  take further discussion to list.

Multipath RTP

Jorg Ott presenting.

Related draft: draft-singh-avt-mprtp-01

Slides: avt-12.

Discusses general idea behing multi-path RTP. Next steps: draft restructering (interface announcements to be only RTCP),  discuss fast session establishment (burst RTCP). WG Item?

Chair (Keith): I would like to see more discussion on the mailing list before discussing WG item status.

Wolfgang Beck: Lack of interest may come from environment may not be suitable for this. May have a patent relating to  something similar. I remember a patent that does something similar using IP source routing.

Jorg: I would like a reference to that patent. Mobile phones do something similar to be able to switch between different  interfaces.

Roni: I understand the solution, but I think you need some use cases.

Martin Thompson: Ted Hardie doing some work on multipath D-TLS that might be of interest.

Jorg: Those are in the draft. I expect to have a new draft in a couple of weeks.

Chair (keith): More discussion on the list needed.

Chair (Keith): We are at the end of the agenda. Do we have anything else we have to discuss, maybe something from monday to  come back to?

No items identified.

Session ended at 14:22