Subject: [AVT] Draft notes for AVT session 1

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 30 Jul 2010 07:42:37 +0200

Below find the draft notes for session 1 of the AVT working group.

Any comments or corrections welcome. Please email.

Thanks to Ingemar and Enrico for the notetaking during the session.

regards

Keith

----------------------------------------------------------------------------------

AVT Working group, Tuesday, 17:10-18:10
=======================================

Chairs: Keith Drage, Roni Even

Agenda
------

[Slidepack avt-0.pdf]

Only slides 1 to 5 presented, rest to be presented in Friday session.

Keith presents the agenda for Tuesday and Friday. Couple of changes
due to speakers availability.

  No questions nor comments.

MPEG2TS preamble breakout will be thursday 11:45-12:45
AVT status presentation on Friday.

ECN
---

Slidepack avt-3.pdf]

Colin Perkins presents ECN for RTP over UDP/IP.

Relates to draft draft-ietf-avt-ecn-for-rtp-02

[Slide 5, "Fragmentation and Reasembly: RTCP"]

Major update of mixers translators section. Personal note: Rescaling of RTCP in transcoders may impact on ConEx functionality  (needs a closer look).

Question to the group: is scaling the right thing to do?

  Ingemar Johansson: rescaling could have some impact on the
  congestion. Colin: that's something we have to check.

[Slide 8, "Open Issues and Next Steps"]

Quick check revealed 10 or so people had read the draft, and it was expected that the document should be ready for WGLC  before the next meeting.

Keith: is the new registration table requested from IANA and covering ICE still required, and if so should it be AVT or  MMUSIC? 

Colin: yes, 

Keith: Should it be in a separate document?

COlin: Should be done in this document.

Keith will check with MMUSIC chairs and WG that they are OK with this.

[Back to slide 5, "Fragmentation and Reasembly: RTCP"]

Ali Begen: scaling depends on the pattern you follow for sending the RTP packets in the first place. 

Bob Briscoe: it seems it is not about the number of bytes, but the number of packets. Should be otherwise. Scale according to  number of bytes instead.

Splicing for MPEG2-TS
---------------------

[Slide pack avt-1.pdf]

Relates to draft draft-xia-avt-splicing-for-mpeg2ts-ps-01

Ning Zong presents the splicing probem statement

[Slide "Potential Solution"]

Dave Oran: all the examples are about video, what about the audio?

Roni: it is not about the actual splicing. The problem is that you have already the information. Dave: the output stream is  totally different from the input. It looks like there's only one splice point, there may be more. 

Colin: the presentation is ignoring the MPEG2 stuff, just focusing on the RTP packets. 

Roni: the problem is how do you create the new stream, or you just do the splicing in the initial stream?

Dave: this is a solution, not a problem statement. 

Roni: kind of agree. 

Dave: is the splicing exceeding SCTE-30 marking? If not, the
 splicing would be detected anyway. 

Roni: yes. 

Dave: understand the problem statement now, which he didn't reading the draft.

Jonathan Lennox: you need to rewrite RTP headers forever, without touching the body.

[Slide "Next Steps"]

Question: do people think there is a problem?

Colin: it seems there is a problem. You are changing the number of RTP packets, so the problem is rewriting the headers  forever. It's annoying, but it's feasible. The translation is feasible, it may be useful to document how you do that.
  solution is backwards compatible.

Bill Versteg: the industry is moving to different technology for carrying MPEG2. 

Question as to whether the draft should be general or specific to the MPEG 2. To be general would need to know the splice  points which are different for each encoding.

Jonathan: the process could be described as: there is a stream, then something happens -- ADs -- then everything gets back to  normal. 

Dave: you need to know for how long the splice lasts. [Further discussion between Colin and Dave over each other and not at  microphone.]

Keith: Requested authors to please improve the draft in the light of the comments made. 
In particular the problem statement  needs to be made clearer. We will then consider whether to adopt in future.

Monitoring Architecture for RTP
-------------------------------

[Slidepack avt-2.pdf]

Relates to draft draft-hunt-avt-monarch-01

Roni presents about the scope of a monitoring architechture for RTP.

[Slide 4, "In more detail (1b) - scope of monarch-00"]

Al Morton: you are not going to define all metrics? 

Colin: initially the problem with metric drafts is that people abandoned metrics that were not reusable. It will be important  to find a way to define reusable metrics.

Dan Romascanu: instead of speaking of the architecture of the whole building we should speak of the architecture of only one  floor.

[Slide 7, "Questions"]

Question: do we want the narrow scope or the broad scope?

Colin: it is a nice draft. Draft -00 is too broad, -01 too narrow. -01 was preferred. 

Roni: can you send this comment on the list?

Dan: Work will be useful. Focus on what you have expertize in. But on the other hand we don't have a generic monitoring  architecture in the OPS area.

Ali: how much interest there is in this? How many XR are actually used.

Roni: it's a chicken and egg. A lots of reports are available, need to decide a way to go.

Qin Wu: we want an RTCP monitoring architecture. How to report these metrics to the monitoring center is not clear. 
Liked -00  better because he wanted the full picture.

Roni: talk to Ron, may want to use SNMP.

Colin: Historically we have bundled too many metrics into a single report. Fine for one application but does not allow reuse.  we have not defined application specific metrics. RTP has a monitoring architecture, the point is how to define useful  metrics.
 RFC 1889 provides the monitoring architecture for RTP and this is looking at ways of enhancing.

Dan referred to RFC 4710, RFC 4711 and RFC 4712 in the OPS area.

Ingemar: in 3GPP there are people working in QoE metrics. Reuse. 

Keith: is it SA4? 

Ingemar: not sure.

Roni: send comments to the list.

Anwar Siddiqui: scope question. Are you going to write a protocol, or just an architecture? 

Roni: no protocol. 

Colin: there are protocol pieces in the draft, but it's just about how to use existing protocols.

Keith: how many people would be interested in some future conference calls between now and the next IETF meeting to discuss  further? 9-10 indicated interest.

---

From: Roni Even <[email-masked]>
Date: Fri, 30 Jul 2010 09:47:12 +0300

Keith
Thanks for the having the notes,
Two comments

1. For splicing. I think that Colin mentioned that it is a general problem
of inserting an RTP stream to another stream in the middle and can be
addressed as a general case and not splicing specific.

2. On monitoring architecture " Roni: talk to Ron, may want to use SNMP". I
probably said Dan but not sure

Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> DRAGE, Keith (Keith)
> Sent: Friday, July 30, 2010 8:43 AM
> To: IETF AVT WG
> Subject: [AVT] Draft notes for AVT session 1
> 
> Major update of mixers translators section. Personal note: Rescaling of
> RTCP in transcoders may impact on ConEx functionality  (needs a closer
> look).
> 
> Quick check revealed 10 or so people had read the draft, and it was
> expected that the document should be ready for WGLC  before the next
> meeting.
> 
> Keith: is the new registration table requested from IANA and covering
> ICE still required, and if so should it be AVT or  MMUSIC?
> 
> Colin: yes,
> 
> Bob Briscoe: it seems it is not about the number of bytes, but the
> number of packets. Should be otherwise. Scale according to  number of
> bytes instead.
> 
> 
> Splicing for MPEG2-TS
> ---------------------
> 
> [Slide pack avt-1.pdf]
> 
> Roni: it is not about the actual splicing. The problem is that you have
> already the information. Dave: the output stream is  totally different
> from the input. It looks like there's only one splice point, there may
> be more.
> 
> Colin: it seems there is a problem. You are changing the number of RTP
> packets, so the problem is rewriting the headers  forever. It's
> annoying, but it's feasible. The translation is feasible, it may be
> useful to document how you do that.
> Question as to whether the draft should be general or specific to the
> MPEG 2. To be general would need to know the splice  points which are
> different for each encoding.
> 
> Jonathan: the process could be described as: there is a stream, then
> something happens -- ADs -- then everything gets back to  normal.
> 
> Dave: you need to know for how long the splice lasts. [Further
> discussion between Colin and Dave over each other and not at
> microphone.]
> 
> In particular the problem statement  needs to be made clearer. We will
> then consider whether to adopt in future.
> 
> 
> Colin: initially the problem with metric drafts is that people
> abandoned metrics that were not reusable. It will be important  to find
> a way to define reusable metrics.
> 
> Dan Romascanu: instead of speaking of the architecture of the whole
> building we should speak of the architecture of only one  floor.
> 
> [Slide 7, "Questions"]
> 
> Dan: Work will be useful. Focus on what you have expertize in. But on
> the other hand we don't have a generic monitoring  architecture in the
> OPS area.
> 
> Qin Wu: we want an RTCP monitoring architecture. How to report these
> metrics to the monitoring center is not clear.
> Colin: Historically we have bundled too many metrics into a single
> report. Fine for one application but does not allow reuse.  we have not
> defined application specific metrics. RTP has a monitoring
> architecture, the point is how to define useful  metrics.
> 
> Keith: how many people would be interested in some future conference
> calls between now and the next IETF meeting to discuss  further? 9-10
> indicated interest.
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt