Subject: [payload] Extended sequence numbers and video payloads

From: Henrik Lundin <[email-masked]>
Date: Wed, 12 Oct 2011 16:26:10 +0200

I'd like to get the payload list readers' opinions on the topic of extended
sequence numbers.

In draft-ietf-payload-rtp-howto-01, Section 5.1.6, it is stated that "as a
rule of thumb, it must not be possible to wrap the sequence number space in
less than 2 minutes (TCP maximum segment lifetime)". If earlier wrapping can
happen, one should provide an extended sequence number field.

Some quick calculations reveal that at an MTU size of 1500 bytes, a video
bitrate of approximately 6.5 Mbps is sufficient to produce 2^16 (jam-packed)
packets in 2 minutes.

It seems to me that the recently written RTP payload format for H.264/AVC
and H.264/SVC does not mention sequence number extension (please, correct me
if I'm wrong). Nor does the older H.263 RTP format mention this.

What is your opinion on this matter? Should future video RTP formats follow
what the HOWTO suggests, or stick to current practice as manifested in the
H.264 formats?

Thanks for your input,
/Henrik

-- 
Henrik Lundin | WebRTC Software Eng | [email-masked] | +46 70 646 13 41

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 12 Oct 2011 07:34:36 -0700

Extended seqnum is something you report in RTCP, which has provisions for it already. Or did I misread your question?

-acbegen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Henrik Lundin
> Sent: Wednesday, October 12, 2011 10:26 AM
> To: [email-masked]
> Subject: [payload] Extended sequence numbers and video payloads
> 
> I'd like to get the payload list readers' opinions on the topic of extended sequence numbers.
> 
> In draft-ietf-payload-rtp-howto-01, Section 5.1.6, it is stated that "as a rule of thumb, it must not be possible to wrap the
> sequence number space in less than 2 minutes (TCP maximum segment lifetime)". If earlier wrapping can happen, one
> should provide an extended sequence number field.
> 
> Some quick calculations reveal that at an MTU size of 1500 bytes, a video bitrate of approximately 6.5 Mbps is sufficient to
> produce 2^16 (jam-packed) packets in 2 minutes.
> 
> It seems to me that the recently written RTP payload format for H.264/AVC and H.264/SVC does not mention sequence
> number extension (please, correct me if I'm wrong). Nor does the older H.263 RTP format mention this.
> 
> What is your opinion on this matter? Should future video RTP formats follow what the HOWTO suggests, or stick to current
> practice as manifested in the H.264 formats?
> 
> Thanks for your input,
> /Henrik
> 
> --

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 12 Oct 2011 10:43:06 -0400

The motivation behind the two minute rule never compelled me.  However, even
if it were deemed compelling by the folks here, the place to introduce
longer sequence numbers would IMO have to be a generic "high nitrate"
extension header, rather a payload format.
Stephan

From:  Henrik Lundin <[email-masked]>
Date:  Wed, 12 Oct 2011 16:26:10 +0200
To:  <[email-masked]>
Subject:  [payload] Extended sequence numbers and video payloads

Thanks for your input,
/Henrik

_______________________________________________ payload mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/payload

---

From: Henrik Lundin <[email-masked]>
Date: Wed, 12 Oct 2011 16:59:36 +0200

True, I am talking about the sequence number field in the RTP header.

/Henrik

On Wed, Oct 12, 2011 at 4:43 PM, Stephan Wenger <[email-masked]> wrote:

> I think he's talking about the 16 bit sequence number field in the RTP
> header.
> Stephan
>
> On 10.12.2011 10:34 , "Ali C. Begen (abegen)" <[email-masked]> wrote:
>
> >Extended seqnum is something you report in RTCP, which has provisions for
> >it already. Or did I misread your question?
> >
> >-acbegen
> >
> >> In draft-ietf-payload-rtp-howto-01, Section 5.1.6, it is stated that
> >>"as a rule of thumb, it must not be possible to wrap the
> >> sequence number space in less than 2 minutes (TCP maximum segment
> >>lifetime)". If earlier wrapping can happen, one
> >> Some quick calculations reveal that at an MTU size of 1500 bytes, a
> >>video bitrate of approximately 6.5 Mbps is sufficient to
> >> It seems to me that the recently written RTP payload format for
> >>H.264/AVC and H.264/SVC does not mention sequence
> >> What is your opinion on this matter? Should future video RTP formats
> >>follow what the HOWTO suggests, or stick to current
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/payload
>
>
>

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 12 Oct 2011 10:43:40 -0400

---

From: "Wang, Ye-Kui" <[email-masked]>
Date: Wed, 12 Oct 2011 17:14:16 +0000

+1

BR, YK

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephan Wenger
Sent: Wednesday, October 12, 2011 7:43 AM
To: [email-masked]
Subject: Re: [payload] Extended sequence numbers and video payloads

The motivation behind the two minute rule never compelled me.  However, even if it were deemed compelling by the folks here, the place to introduce longer sequence numbers would IMO have to be a generic "high nitrate" extension header, rather a payload format.
Stephan

From: Henrik Lundin <[email-masked]<mailto:[email-masked]>>
Date: Wed, 12 Oct 2011 16:26:10 +0200
To: <[email-masked]<mailto:[email-masked]>>
Subject: [payload] Extended sequence numbers and video payloads

In draft-ietf-payload-rtp-howto-01, Section 5.1.6, it is stated that "as a rule of thumb, it must not be possible to wrap the sequence number space in less than 2 minutes (TCP maximum segment lifetime)". If earlier wrapping can happen, one should provide an extended sequence number field.

Some quick calculations reveal that at an MTU size of 1500 bytes, a video bitrate of approximately 6.5 Mbps is sufficient to produce 2^16 (jam-packed) packets in 2 minutes.

It seems to me that the recently written RTP payload format for H.264/AVC and H.264/SVC does not mention sequence number extension (please, correct me if I'm wrong). Nor does the older H.263 RTP format mention this.

What is your opinion on this matter? Should future video RTP formats follow what the HOWTO suggests, or stick to current practice as manifested in the H.264 formats?

Thanks for your input,
/Henrik

--
Henrik Lundin | WebRTC Software Eng | [email-masked]<mailto:[email-masked]> | +46 70 646 13 41

_______________________________________________ payload mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/payload

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 12 Oct 2011 15:02:02 -0400

s/nitrate/bitrate/ :-)
S.

Sent from my iPhone

On Oct 12, 2011, at 13:14, "Wang, Ye-Kui" <[email-masked]> wrote:

> _______________________________________________ payload mailing list [email-masked] https://www.ietf.org/mailman/listinfo/payload

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Oct 2011 08:51:58 +0200

On 2011-10-12 16:43, Stephan Wenger wrote:
> The motivation behind the two minute rule never compelled me.  However,
> even if it were deemed compelling by the folks here, the place to
> introduce longer sequence numbers would IMO have to be a generic "high
> nitrate" extension header, rather a payload format.
> Stephan

Probably not a bad suggestion. Still payload formats would need to
indicate the need to support them and under which circumstances. We also
have the question if that header extension then truly follows the rules
for header extensions being possible to ignore.

About the 2 minutes. That is picked based on the TCP Maximum Segment
Lifetime, i.e. a time where any packet is guaranteed to have expired in.
In almost all networks the real time until a packet will have expired is
shorter. And lets say we do the calculation using 5 seconds, that is 24
times longer. Which then would cover around 150 Mbps of well packed video.

Henrik is correct that at least H.264 should have modes with extended
sequence numbers due to that it is possible to have bit-streams that
surpass with certainty the rate of wrapping which is safe in RTP.

However, the HOWTO is written after the H.264 payload format was written
the first time. In fact quite a lot of the video discussion are based on
that particular payload format.

I guess Henrik's question are in relation to WP8. My counter question is
what is the highest bit-rate it can produce? If it can produce in excess
of 100 Mbps I think the extended sequence number needs to be seriously
considered.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Henrik Lundin <[email-masked]>
Date: Fri, 21 Oct 2011 09:28:00 +0200

> of 100 Mbps I think the extended sequence number needs to be seriously

Yes, my question is in relation to VP8. After consulting some VP8 experts,
the answer is that in theory there is no upper limit (there is a limit on
image size, but the frame rate can be arbitrarily high). But in practice, it
is  limited to somewhere around 20 Mbps. I take it we can omit the SN
extension for now.