Subject: [payload] Payload WG notes - Please read

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 21 Jul 2015 16:05:52 +0000

Please have a look and send any corrections to the chairs by July 28th. Presenters, please fill in the gaps denoted by a question mark.

Thanks.
-acbegen

IETF 93 - Payload Notes
Chairs: Roni Even, Ali Begen
Note takers: Stephan Wenger, Mo Zanaty
Jabber scribe: Jonathan Lennox

Payload Status Update Chairs
https://www.ietf.org/proceedings/93/slides/slides-93-payload-0.pdf
 
H265: SDP directorate review by Flemming Andreasen noted no overall
grammar and no formal grammar for fmtp parameters. No interoperability issues,
so no change needed, according to Stephan, Magnus Westerlund, others. Magnus:
recommendation in how-to: when you have complex parameters, then you should
include ABNF.  Otherwise not.
Stephan: there is an ABNF in the draft for one complex parameter.

VP9 RTP Payload Format (Magnus Flodman)
draft-ietf-payload-vp9-00 <http://tools.ietf.org/id/draft-ietf-payload-vp9-00>
https://www.ietf.org/proceedings/93/slides/slides-93-payload-3.pdf
 
Flexible and Non-Flexible GOF (Group of Frames) structure: Mo thinks
this may be useful for other codecs, authors have no issues with reusing this.
Stephan noted that other codecs (e.g. H.264/5) have other means to convey this
within the payload itself not in payload headers.

Flexible FEC RTP Payload Format (Varun Singh)
draft-ietf-payload-flexible-fec-scheme-00 <http://tools.ietf.org/id/draft-ietf-payload-flexible-fec-scheme-00>
https://www.ietf.org/proceedings/93/slides/slides-93-payload-1.pdf
 
Bernard Aboba: How can a sender signal specific FEC patterns, like only
protect the base layer of SRST RTP streams? Authors clarified that no static
signaling (e.g. SDP) is necessary since the sender is free to pick dynamic
patterns and all receivers must handle this.
 
Slide 8: open issue: 
Jonathan: putting SSRC into RTP payload is scary (layer violation)
Mo: we are already in layer violation due to SN; could go Fecframe model
Jonathan: ??? something about Perc, 
fec over encrypted payload
 
Magnus: Dislikes no support for jumbo packets > 4KB. Better to
support 64KB packets and expand the FEC header. Stephan agrees with expansion.
 
Different opinions expressed on whether source flow SSRC(s) should be
included in the FEC header, or other identifiers like MID or the newly proposed
ESID/RSID. Also different views on signaling multiple source flows.
Result: Need a side meeting to decide what source flow identifier is
used to associate with a FEC repair flow and how to handle multiple source
flows. Varun will lead and copy the list.

MELPe Codec (Roni Even for Victor Demjanenko)
draft-demjanenko-payload-melpe-03 <http://tools.ietf.org/id/draft-demjanenko-payload-melpe-03>
https://www.ietf.org/proceedings/93/slides/slides-93-payload-4.pdf
 
Stephan has read it and thinks it is a well written RTP payload format
draft. No other reviewers, so chairs will ask the list to review.

Interleaved RTP Payload Format (Rachel Huang)
draft-huang-payload-rtp-interleave-00 <http://tools.ietf.org/id/draft-huang-payload-rtp-interleave-00>
https://www.ietf.org/proceedings/93/slides/slides-93-payload-2.pdf
 
Jonathan: Note that PT must be the same.
Rachel: yes
Jonathan: assumption aggregation never changes number of packets.  
Rachel: yes
Jonathan: with more flexible sequence number mechanism, you could do better
Rachel: yes
Imed: Interleave an IDR, what’s the gain?
Rachel: ???

---

From: Varun Singh <[email-masked]>
Date: Wed, 22 Jul 2015 09:43:43 +0200

Below is the outcome of the side meeting: provide corrections if I the
summary is inaccurate.

It was decided that
1. We will need to revisit how FEC operates with PERC-enabled middleboxes.
This is currently a non-goal.
2. an identifier will be in the FEC payload. For now this is SSRC. However,
if a needed this could be replaced by another identifier (e.g., RSID). .

3. keep the encapsulated length as 16 bits. Add the 4 bits of SSRC Counter
elsewhere, this is still TBD.

To summarise the version 3/3 in the slides was accepted.

Cheers,

Varun

On Tue, Jul 21, 2015 at 6:05 PM, Ali C. Begen (abegen) <[email-masked]>
wrote:
>
> Please have a look and send any corrections to the chairs by July 28th.
Presenters, please fill in the gaps denoted by a question mark.
> draft-ietf-payload-vp9-00 <
http://tools.ietf.org/id/draft-ietf-payload-vp9-00>
> draft-ietf-payload-flexible-fec-scheme-00 <
http://tools.ietf.org/id/draft-ietf-payload-flexible-fec-scheme-00>
> draft-demjanenko-payload-melpe-03 <
http://tools.ietf.org/id/draft-demjanenko-payload-melpe-03>
> draft-huang-payload-rtp-interleave-00 <
http://tools.ietf.org/id/draft-huang-payload-rtp-interleave-00>
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload

-- 
http://www.callstats.io

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 22 Jul 2015 08:52:47 +0000

On Jul 22, 2015, at 9:43 AM, Varun Singh <[email-masked]<mailto:[email-masked]>> wrote:

Below is the outcome of the side meeting: provide corrections if I the summary is inaccurate.

It was decided that
1. We will need to revisit how FEC operates with PERC-enabled middleboxes. This is currently a non-goal.
2. an identifier will be in the FEC payload. For now this is SSRC. However, if a needed this could be replaced by another identifier (e.g., RSID). .

3. keep the encapsulated length as 16 bits. Add the 4 bits of SSRC Counter elsewhere, this is still TBD.

On point 2 — my opinion in the side meeting was that even if we define identifiers like RSID in the future, the identifier in FlexFEC should nonetheless remain an SSRC.  The reason is that the FEC receiver needs to know, after an SSRC change, whether the packets being FEC’d come from the old SSRC or the new SSRC.

It was also pointed out that the FEC format, as a degenerate case, can also perform retransmission (by creating a FEC packet that covers only a single source packet).  This may be able to resolve some of the annoyances of the RFC 4588 RTX format, notably in a BUNDLE context — it avoids payload type explosion (because the source PT is in the packet), and gives you stream association automatically.

---

From: "Roni Even" <[email-masked]>
Date: Wed, 22 Jul 2015 12:02:36 +0300

Hi Ali,
On Melpe, we will ask the list to adopt this work as a WG item since it is within the scope of the working group and the current version has all the required information based on RTP howto, this was what both Stephan and I (as individual) said at the microphone

H.265 does not need any change and can progress

On VP9 - need to decide on payload header or payload - go to the list?

Roni

-----Original Message-----
From: payload [mailto:[email-masked]] On Behalf Of Ali C. Begen (abegen)
Sent: Tuesday, July 21, 2015 7:06 PM
To: [email-masked]
Subject: [payload] Payload WG notes - Please read

Thanks.
-acbegen

IETF 93 - Payload Notes

H265: SDP directorate review by Flemming Andreasen noted no overall grammar and no formal grammar for fmtp parameters. No interoperability issues, so no change needed, according to Stephan, Magnus Westerlund, others. Magnus:
recommendation in how-to: when you have complex parameters, then you should include ABNF.  Otherwise not.
Stephan: there is an ABNF in the draft for one complex parameter.

Flexible and Non-Flexible GOF (Group of Frames) structure: Mo thinks this may be useful for other codecs, authors have no issues with reusing this.
Stephan noted that other codecs (e.g. H.264/5) have other means to convey this within the payload itself not in payload headers.

Bernard Aboba: How can a sender signal specific FEC patterns, like only protect the base layer of SRST RTP streams? Authors clarified that no static signaling (e.g. SDP) is necessary since the sender is free to pick dynamic patterns and all receivers must handle this.
 
Slide 8: open issue: 
 
Magnus: Dislikes no support for jumbo packets > 4KB. Better to support 64KB packets and expand the FEC header. Stephan agrees with expansion.
 
Different opinions expressed on whether source flow SSRC(s) should be included in the FEC header, or other identifiers like MID or the newly proposed ESID/RSID. Also different views on signaling multiple source flows.
Result: Need a side meeting to decide what source flow identifier is used to associate with a FEC repair flow and how to handle multiple source flows. Varun will lead and copy the list.

Stephan has read it and thinks it is a well written RTP payload format draft. No other reviewers, so chairs will ask the list to review.

---

From: Varun Singh <[email-masked]>
Date: Wed, 22 Jul 2015 13:13:30 +0200

On Wed, Jul 22, 2015 at 10:52 AM, Jonathan Lennox <[email-masked]> wrote:
>
> On Jul 22, 2015, at 9:43 AM, Varun Singh <[email-masked]> wrote:
>
> On point 2 — my opinion in the side meeting was that even if we define
> identifiers like RSID in the future, the identifier in FlexFEC should
> nonetheless remain an SSRC.  The reason is that the FEC receiver needs to
> know, after an SSRC change, whether the packets being FEC’d come from the
> old SSRC or the new SSRC.

If there is agreement on SSRC, I will not put any editor's note or
placeholder for replacing it.

>
> It was also pointed out that the FEC format, as a degenerate case, can also
> perform retransmission (by creating a FEC packet that covers only a single
> source packet).  This may be able to resolve some of the annoyances of the
> RFC 4588 RTX format, notably in a BUNDLE context — it avoids payload type
> explosion (because the source PT is in the packet), and gives you stream
> association automatically.

True, I will add some text related to this. However, if we want to use
this in rtcweb, rtp-usage may want to express an opinion on using this
in addition to RFC4588?

-- 
http://www.callstats.io

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 22 Jul 2015 11:21:49 +0000

Varun,

Please write down the changes you propose in the WG draft (start a new thread please) and we should wait for comments in the list before you incorporate them.

Thanks.

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 28 Jul 2015 06:58:53 +0000

Sorry, didn't notice it until now^^.

Imed: Interleave an IDR, what’s the gain?
Rachel: Only applying interleaving on IDR frames helps to reduce the delay caused by interleaving, which is now considered by some ISPs who provide 4K IPTV services still on DSL access network.

BR,
Rachel

> Sent: Wednesday, July 22, 2015 12:06 AM
> To: [email-masked]
> grammar and no formal grammar for fmtp parameters. No interoperability
> issues, so no change needed, according to Stephan, Magnus Westerlund,
> others. Magnus:
> Flexible and Non-Flexible GOF (Group of Frames) structure: Mo thinks this may
> be useful for other codecs, authors have no issues with reusing this.
> Stephan noted that other codecs (e.g. H.264/5) have other means to convey
> this within the payload itself not in payload headers.
> 
> 
> draft-ietf-payload-flexible-fec-scheme-00
> <http://tools.ietf.org/id/draft-ietf-payload-flexible-fec-scheme-00>
> Bernard Aboba: How can a sender signal specific FEC patterns, like only protect
> the base layer of SRST RTP streams? Authors clarified that no static signaling
> (e.g. SDP) is necessary since the sender is free to pick dynamic patterns and all
> receivers must handle this.
> 
> Slide 8: open issue:
> Magnus: Dislikes no support for jumbo packets > 4KB. Better to support 64KB
> packets and expand the FEC header. Stephan agrees with expansion.
> 
> Result: Need a side meeting to decide what source flow identifier is used to
> associate with a FEC repair flow and how to handle multiple source flows.
> Varun will lead and copy the list.
> 
> 
> draft-demjanenko-payload-melpe-03
> <http://tools.ietf.org/id/draft-demjanenko-payload-melpe-03>
> Stephan has read it and thinks it is a well written RTP payload format draft. No
> other reviewers, so chairs will ask the list to review.
> 
> 
> draft-huang-payload-rtp-interleave-00
> <http://tools.ietf.org/id/draft-huang-payload-rtp-interleave-00>