Subject: [AVT] Draft AVT agenda

From: Colin Perkins <[email-masked]>
Date: Mon, 03 Dec 2001 01:28:56 -0500

Folks,

Enclosed is the draft agenda for the AVT working group meeting at the Salt
Lake City IETF. Please send comments and corrections to the working group
chairs, by Tuesday 4th December.

Those who have agenda time scheduled are requested to prepare a summary of
the issues they wish to discuss, and to send this to the mailing list ahead
of the meeting. This gives folks that won't be attending the opportunity to 
post their comments and concerns, and potentially even reach some consensus, 
before the meeting time is consumed. It also gives other participants the 
opportunity to consider the issue in more depth. Summary messages should be 
sent to the mailing list by Tuesday 4th December.

We also request that all presenters send us their slides ahead of time. This 
has multiple purposes:

  - It streamlines the presentation process by having the presentations on 
    a single laptop.

  - It avoids the delay that sometimes occurs in getting the presentations
    sent to us after the meeting, for inclusion in the minutes.

  - It allows us to preview the presentations to see if they are following 
    the guidelines for what should be covered during the meeting.

Those presenting new drafts: briefly describe the basic problem and your
proposed solution, discuss known issues, limitations and problems, outline
where you want input from the working group, and how you wish us to proceed.
When presenting work which has been previously discussed: describe only the
changes from the previous draft, highlight unresolved problems, and propose
future directions. Presenters are reminded of the requirements for disclosure 
of intellectual property relating to contributions, in section 10 of RFC 2026. 

Agenda time is conditional on sending both a summary of open issues and a
copy of your slides ahead of the meeting.

We strongly encourage all participants to read all relevent drafts before 
the meeting, and to comment on the open issues raised on the mailing list. 

Thanks for your assistance to try to conduct an effective meeting.

Colin & Steve

===============================================================================
Audio/Video Transport WG (AVT)

Monday, December 10 at 1930-2200
Wednesday, December 12 at 0900-1130
===================================

CHAIRS: Steve Casner <[email-masked]>
        Colin Perkins <[email-masked]>

AGENDA:

Session 1:

- Introduction and status (Casner/Perkins)				10
	Published or with RFC editor:
		RFC 3158
		draft-ietf-avt-dv-audio-04.txt
		draft-ietf-avt-dv-video-04.txt
	Under revision after IESG review:
		draft-ietf-avt-rtp-amr-10.txt
	Last call:
		draft-ietf-avt-crtp-enhance-03.txt
		draft-ietf-avt-tcrtp-04.txt
		draft-ietf-avt-uxp-01.txt
		draft-ietf-avt-ulp-02.txt 
		draft-ietf-avt-rtp-cn-04.txt

- RTP Payload formats for MPEG-4
	draft-ietf-avt-mpeg4-multiSL-02.txt 		(Gentric)	10
	draft-ietf-avt-mpeg4-simple-00.txt		(van der Meer)	10
	draft-curet-avt-rtp-mpeg4-flexmux-01.txt 	(Roux)		10

- RTP payload format for GSM EFR speech			(Barany)	15
	draft-barany-avt-efr-00.txt
	draft-ietf-avt-profile-new-12.txt section 4.5.9

- RTP Payload Format for EVRC, SMV and Frame-Based Vocoders (Li)	15
	draft-li-avt-vocoder-00.txt 

- RTP Payload Format for AC-3 Streams 			(Flaks)		15
	draft-flaks-avt-rtp-ac3-00.txt

- MWPP: A resilient MIDI RTP packetization 		(Lazzaro)	15
	draft-lazzaro-avt-mwpp-midi-nmp-00.txt

- RTP Payload Format for Distributed Speech Recognition	(Xie)		15
	draft-ietf-avt-dsr-00.txt

Session 2: 

- RTP payload format for JPEG 2000 video streams 	(Edwards)	15
	draft-edwards-avt-rtp-jpeg2000-00.txt

- Update to RTP specification and profile		(Casner)	15
	draft-ietf-avt-rtp-new-11.txt, .ps
	draft-ietf-avt-profile-new-12.txt, .ps
	draft-ietf-avt-rtp-mime-06.txt 
	draft-ietf-avt-rtcp-bw-05.txt

- Secure RTP profile					(Carrara)	15
	draft-ietf-avt-srtp-02.txt

- RTP extensions for classification and priority
	draft-carlberg-rtp-classifier-extension-00.txt	(Carlberg)	 5
	draft-polk-avt-rtpext-res-pri-00.txt		(Polk)		 5
	Discussion							10

- Extended RTP Profile for RTCP-based Feedback		(Ott)		15
	draft-ietf-avt-rtcp-feedback-01.txt
	draft-burmeister-avt-rtcp-feedback-sim-00.txt

- RTP retransmission
	draft-leon-retransmission-01.txt		(Leon)		15
	draft-ietf-avt-rtp-selret-03.txt

- RTCP Extension for SSM Sessions with Unicast feedback (Chesterfield)	15
	draft-chesterfield-avt-rtcpssm-02.txt

- Extending RTCP for call quality metrics		(Massad)	 5

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www1.ietf.org/mailman/listinfo/avt

---

From: "Noriyuki SATO" <[email-masked]>
Date: Mon, 3 Dec 2001 21:09:28 +0900

Dear AVT experts,

I'm the one of the authors of RTCP-based Feedback draft.
I'm sorry that my posted takes your time. I'd like to have your constructive comments.

"draft-ietf-avt-rtcp-feedback-01.txt" was reviced from -00 in this turn.
There is one of the new functions named "Generic Info" described in the section 6.3.
This is the Joerg's new proposal into which he wanted to reflect my comments.
There was not enough time to discuss about it, so that there seemed to be some misunderstandings.

I have a conecern about this function.

I don't disagee with the feedback suppression but generic info doesn't seem appropriate for
payload-specific format.
So I think it is better to delete the generic info or not to force the payload-specific to
be compounded with generic info.

My proposals are
 - not to apply the generic info to payload-specific
 - to discard or ignore the feedback which semantic is not understandable from other
   participants but take it into account of the timer calculation (or not to react)
 - correction of misleading part about malcious group in the security consideration section

It is because
 - Not feedback suppression but timer calculation and timing rule avoids the implosions of
   feedback.
 - Payload specific feedback will not harm if the participants which could not understand
   it igonre that.
 - Malcious groups can use not only the payload specific but also generic.
   The need is not to react.

The details are as follows.

The draft describes the function "Feedback suppression" that aimed to obtain much more
effect of feedback.

In the section 6.3 was described as follows about "Generic Info".

 "AVPF entities MUST include Generic INFO messages along with any payload-specific ones
 in compound RTCP packets (early as well as regularly scheduled ones).
 The INFO message(s) MUST cover all the RTP packets to which the payload-specific 
 message(s) apply.  This is to avoid that AVPF entities that do not understand the 
 payload-specific messages unnecessarily suppress their feedback messages. "

The messages of Generic NACK/ACK and Generic Info are the messages to send the information
of packet lost (or not lost) for consecutive 15 packets. These messages corresponded into 
packet loss exactly.

On the other hand, payload-specific messages not exactly correspond to packet loss.
These messages carry the information corresponding into either status of CODECs or applications'.

There are some cases possibly.

 - the case that the receivers need to send different messages each other even if the recent
   consecutive 15 packet loss pattern were same between the receivers.
 - the case that they need to send same messages even if the recent consecutive 15 packet loss 
   pattern were different between the receivers,
   (For example, in the video codec case, when different packets for same regions of
   videoframes, the receiver may need to send same messages.)
 - etc.

Thus, I think
"The feedback suppression function for the payload-specific messages may not depend on
 the generic info because the Generic Info carry the information for the packet loss,
 and on the other hand, payload-specific info messages carry the information for the 
 status of codec or applications. So, payload-specific should not be compounded with 
 generic info."

In the last part of page 29, it is described some misleadings.

Malcious group can use the generic NACK/ACK format to attack.
The point is "do not react to the message from malcious groups".

If the receiver recieves the feedback message which the receiver cannot undestand,
the receiver should discard ( or ignor) that messages but it must be taken account into 
timer calculation. Those doesnt't cause any implosion of feedback. 
Avoiding feedback implosion depends on timer calculation and keeping RTCP bandwidth.

I don't disagee with the feedback suppression but generic info doesn't seem appropriate for
payload-specific format.

Comments are welcome.

Best Regards,

Noriyuki SATO
Oki Electric Industry Co., Ltd.
([email-masked])
-----

---

From: Hideaki Kimata <[email-masked]>
Date: Tue, 04 Dec 2001 03:04:27 +0900

Dear Sato-san, and experts,

I fully agree with you.

Best regards,
Hideaki Kimata
NTT Cyber Space Laboratories

On Mon, 3 Dec 2001 21:09:28 +0900

-- 
Hideaki Kimata <[email-masked]>

---

From: Julian Chesterfield <[email-masked]>
Date: Fri, 07 Dec 2001 09:34:18 -0800

Colin Perkins wrote:

> of the meeting.

Draft Title:  RTCP Extension for Single Source Multicast Sessions with
                            Unicast RTCP feedback

Status:  2nd revision

Draft:
http://search.ietf.org/internet-drafts/draft-chesterfield-avt-rtcpssm-02.txt

We plan to present the updates to the draft since version 01. Changes are:

- Draft has been slightly restructured with more focus on security issues.

- The RSI packet is modularised to allow more flexibility as to the level of
feedback provided to the receivers. A new report block format LJS (Loss Jitter
Summary) is now included to address this.

- New SDP session level attributes are addressed in the draft.

- The source is no longer allowed to change reporting formats during a session

- The complexity involved in the Mixer/translator rules has been removed.

- The problem of identifying SSRC collisions is addressed. Proposal is to require
the source to maintain record of
SSRC,IP address mappings. This should enable differentiation between the vast
majority of collisions.

Open issues:
- Does the RSI + LJS packet format address the flexibility requirements of
applications.

- Is it reasonable to require the source to maintain IP address and SSRC mappings?
Is there a better way to identify
SSRC collisions?

- Are the security measures currently outlined in the draft sufficient?

- Are there any scenarios which are not covered by the draft but would need to be
clarified?

A postscript and html version of the draft including examples on how to create and
process LJS report blocks is
available from:-

https://multicast.research.att.com/rtcp_ssm

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 07 Dec 2001 19:18:32 -0600

> the issues they wish to discuss, and to send this to the mailing list ahead

  RTP Payload Format for Distributed Speech Recognition (DSR) 
                 <draft-ietf-avt-dsr-00.txt>

  Changes: 
       1. Frame Pair Counter (FPC) removed - can be inferred by 
          packet length.
       2. E (End of speech) flag removed - replaced with the use 
          of NULL FP which gives better support to discontinuous 
          transmission.
       3. The 1-byte payload header is eliminated.
       4. Support for Discontinuous Transmission better clarified.

  Open issues – none.

-Qiaobing