Subject: [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

From: Adam Fineberg <[email-masked]>
Date: Wed, 17 Jul 2013 15:36:50 -0700

Hi,

I'm working on WebRTC services and have found that while developing 
services that forward VP8 video streams if we want to take advantage of 
the VP8 temporal scaling we must get the temporal layer information from 
the RTP header which requires us to decrypt the SRTP packets.  This is 
undesirable both because the middlebox needs to have acesss to the keys 
as well as the because of the added overhead of the decrypt/encrypt 
cycle.  This draft proposes an RTP header extension that will allow us 
to use the VP8 temporal layer information included in the header 
extension and therefore do forwarding without SRTP decryption.  Comments 
welcome.

Regards,
Adam Fineberg
[email-masked]

-------- Original Message --------
Subject: 	New Version Notification for 
draft-fineberg-avtext-temporal-layer-ext-00.txt
Date: 	Tue, 09 Jul 2013 10:02:05 -0700
From: 	[email-masked]
To: 	Adam Fineberg <[email-masked]>

A new version of I-D, draft-fineberg-avtext-temporal-layer-ext-00.txt
has been successfully submitted by Adam Fineberg and posted to the
IETF repository.

Filename:	 draft-fineberg-avtext-temporal-layer-ext
Revision:	 00
Title:		 A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
Creation date:	 2013-07-08
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
Status:          http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
Htmlized:        http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00

Abstract:
    This document defines a mechanism by which packets of Real-Time
    Tranport Protocol (RTP) video streams encoded with the VP8 codec can
    indicate, in an RTP header extension, the temporal layer information
    about the frame encoded in the RTP packet.  This information can be
    used in a middlebox performing bandwidth management of streams
    without requiring it to decrypt the streams.

The IETF Secretariat

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 25 Jul 2013 12:49:25 -0400

Hi, Adam –

(Speaking as an individual.)

I think there’s a problem with the use case as you’ve described here, which I think calls into question the usefulness of the whole mechanism.

As I understand you, you’re planning to send a single VP8 stream containing all the layers, and then have a media-aware middlebox selectively drop some of the stream’s packets to do temporal scaling without needing the middlebox to be in the crypto context.

Unfortunately, RTP doesn’t really let you do this.  The problem is that by just dropping packets without rewriting RTP sequence numbers or RTCP sender reports, this is going to look like enormous packet loss to RTP (which, in a sense, it is).  A middlebox like this – which is acting as a media-modifying RTP translator, in RTP terminology – needs to rewrite RTP headers and RTCP sender reports in order to keep the stream and its metadata consistent and valid.

Unfortunately, the translator needs to have the crypto keys in order to make these modifications, so I’m not sure this header extension adds much benefit over just validating the authentication, decrypting (say) the initial block of the packet (wherever the temporal layer information is known to be), modifying the headers, and then re-authenticating the packet.

Is there something I’m missing here?

From: Adam Fineberg [mailto:[email-masked]]
Sent: Wednesday, July 17, 2013 6:37 PM
To: [email-masked]
Subject: [avtext] Fwd: New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Hi,

I'm working on WebRTC services and have found that while developing services that forward VP8 video streams if we want to take advantage of the VP8 temporal scaling we must get the temporal layer information from the RTP header which requires us to decrypt the SRTP packets.�� This is undesirable both because the middlebox needs to have acesss to the keys as well as the because of the added overhead of the decrypt/encrypt cycle.�� This draft proposes an RTP header extension that will allow us to use the VP8 temporal layer information included in the header extension and therefore do forwarding without SRTP decryption.�� Comments welcome.

Regards,
Adam Fineberg
[email-masked]<mailto:[email-masked]>

-------- Original Message --------
Subject:

New Version Notification for draft-fineberg-avtext-temporal-layer-ext-00.txt

Date:

Tue, 09 Jul 2013 10:02:05 -0700

From:

[email-masked]<mailto:[email-masked]>

To:

Adam Fineberg <[email-masked]><mailto:[email-masked]>

IETF repository.

Revision:       00

Number of pages: 6

Abstract:

The IETF Secretariat

---

From: Adam Fineberg <[email-masked]>
Date: Thu, 25 Jul 2013 20:35:10 -0700

Jonathan,

Thanks for the feedback.  You are of course correct, I'm not sure why I 
forgot about the authentication of the RTP header.  The intent was not 
to have to perform the crypto on the payload of course but it would 
still require header changes which therefore needs the header 
re-authenticated.

Regards,
Adam

On 7/25/13 9:49 AM, Jonathan Lennox wrote:
> I think there’s a problem with the use case as you’ve described here, 
> which I think calls into question the usefulness of the whole mechanism.
>
> As I understand you, you’re planning to send a single VP8 stream 
> containing all the layers, and then have a media-aware middlebox 
> selectively drop some of the stream’s packets to do temporal scaling 
> without needing the middlebox to be in the crypto context.
>
> Unfortunately, RTP doesn’t really let you do this.  The problem is 
> that by just dropping packets without rewriting RTP sequence numbers 
> or RTCP sender reports, this is going to look like enormous packet 
> loss to RTP (which, in a sense, it is).  A middlebox like this – which 
> is acting as a media-modifying RTP translator, in RTP terminology – 
> needs to rewrite RTP headers and RTCP sender reports in order to keep 
> the stream and its metadata consistent and valid.
>
> Unfortunately, the translator needs to have the crypto keys in order 
> to make these modifications, so I’m not sure this header extension 
> adds much benefit over just validating the authentication, decrypting 
> (say) the initial block of the packet (wherever the temporal layer 
> information is known to be), modifying the headers, and then 
> re-authenticating the packet.
>
> *From:*Adam Fineberg [mailto:[email-masked]]
> *Sent:* Wednesday, July 17, 2013 6:37 PM
> *To:* [email-masked]
> *Subject:* [avtext] Fwd: New Version Notification for 
> services that forward VP8 video streams if we want to take advantage 
> of the VP8 temporal scaling we must get the temporal layer information 
> from the RTP header which requires us to decrypt the SRTP packets.�� 
> This is undesirable both because the middlebox needs to have acesss to 
> the keys as well as the because of the added overhead of the 
> decrypt/encrypt cycle.�� This draft proposes an RTP header extension 
> that will allow us to use the VP8 temporal layer information included 
> in the header extension and therefore do forwarding without SRTP 
> decryption.�� Comments welcome.
>
> Regards,
> Adam Fineberg
>
> [email-masked] <mailto:[email-masked]>
>
> *Subject: *
> New Version Notification for 
> *Date: *
> *From: *
> [email-masked] <mailto:[email-masked]>
>
> *To: *
>
> 	
>
> Adam Fineberg <[email-masked]> <mailto:[email-masked]>
>
> URL:http://www.ietf.org/internet-drafts/draft-fineberg-avtext-temporal-layer-ext-00.txt
> Status:http://datatracker.ietf.org/doc/draft-fineberg-avtext-temporal-layer-ext
> Htmlized:http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext-00
>   
>   
> Abstract: