Subject: Re: [payload] #5: Section 3.1.2: "MANE" definition

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Dec 2013 07:46:36 +0000

I am ok with using “MANE” for the last paragraph of Section 4.8, since presumably an SFU will not do NAL re-packetization. 

The last paragraph in Section 9 can also use the term MANE but it needs a bit of wordsmithing, perhaps.   When dealing with SST, even discarding packets requires the SRTP authentication session key, because the sequence no. needs to be rewritten (this is not true for Multi-SSRC transport).  The need for the SRTP encryption session key exists if a field utilized by the encryption transform is modified.  For example, if the MANE changes the PT, Sequence No, SSRC or CSRC fields and the f8 transform (defined in RFC 3711) is being used, then the packet will need to be decrypted and encrypted, even if all the information needed to decide to forward the packet was placed outside the payload (e.g. in an RTP extension).   For other transforms, fewer fields may trigger decrypt/encrypt, but avoiding it entirely seems only possible for “source projecting" SFUs/MANEs (which let the SSRC pass through similar to an RTP translator), which to my knowledge have never been implemented. 

Also, a MANE must have access to SRTCP master keys, so if RTCP/RTP multiplexing is used, then access to SRTP master keys is a given. 

From: [email-masked]
Sent: ‎Tuesday‎, ‎December‎ ‎10‎, ‎2013 ‎7‎:‎05‎ ‎PM
To: payload issue tracker, [email-masked], [email-masked]
Cc: [email-masked], Wang, Ye-Kui

Hi Bernard,

A global substitute may be the wrong thing to do.

In many instances, an SFU can do what is attributed into a MANE¹s
operation.  However, in section 4.8 (last paragraph) and section 9
(security) final paragraph, MANEs perform operations that are outside the
scope of an SFU (at least as I understand the SFU).

So here is what I suggest:
1. Add informative reference to topologies-update
2. Add definition of Selective Forwarding Unit (SFU), refer to
topologies-update.
3. Keep definition of MANE.  Add note indicating that an SFU is one form
of a MANE.
4. Replace MANE with SFU in all instances except section 4.8 last
paragraph and section 9 last paragraph

Does that work?

Stephan

On 12.9.2013, 18:38 , "payload issue tracker"
<[email-masked]> wrote:

>#5: Section 3.1.2:   "MANE" definition
>
> media aware network element (MANE): A network element, such as a
>    middlebox or application layer gateway that is capable of parsing
>    certain aspects of the RTP payload headers or the RTP payload and
>    reacting to their contents.
>
>       Informative note: The concept of a MANE goes beyond normal
>       routers or gateways in that a MANE has to be aware of the
>       signaling (e.g., to learn about the payload type mappings of the
>       media streams), and in that it has to be trusted when working
>       with SRTP.  The advantage of using MANEs is that they allow
>       packets to be dropped according to the needs of the media coding.
>       For example, if a MANE has to drop packets due to congestion on a
>       certain link, it can identify and remove those packets whose
>       elimination  produces  the  least  adverse  effect  on  the  user
>       experience.  After dropping packets, MANEs must rewrite RTCP
>       packets  to  match  the  changes  to  the  RTP  packet  stream  as
>       specified in Section 7 of [RFC3550].
>
> [BA] In draft-ietf-avtcore-rtp-topologies-update the term "Selective
> Forwarding Unit" is being used.  Should SFU be substituted for MANE here?
> I'd prefer that, because the MANE definition is showing its age:
>
> a. Today's SFUs parse payload headers, but if an RTP extension were to
> expose scalability info (e.g. LayerId, TID) that might not be necessary.
>
> b. While SFUs do need info transported in signaling protocols (e.g.
> transport and demultiplexing info), this doesn't mean they need contain a
> signaling parser.
>
> c. The requirement for access to SRTP encryption session keys is not an
> architectural requirement but rather is a consequence of the design of
> encryption transports (which always depend on SSRC, and sometimes also
> other fields (e.g. f8 defined in RFC 3711 depends on PT, Sequence No,
>etc.
> in addition),  SFU design choices (e.g. need to rewrite PTs, support for
> RTP/RTCP multiplexing (which implies access to SRTP master keys), support
> for SST vs. MST (which could avoid Sequence Number rewrites), allocation
> of SSRCs vs. "source projection" (which would avoid SSRC rewriting,
>etc.).
>
>-- 
>-------------------------------------+------------------------------------
>-
> Reporter:                           |      Owner:  draft-ietf-payload-
>  [email-masked]          |  [email-masked]
>     Type:  defect                   |     Status:  new
> Priority:  major                    |  Milestone:  milestone1
>Component:  rtp-h265                 |    Version:  1.0
> Severity:  Active WG Document       |   Keywords:
>-------------------------------------+------------------------------------
>-
>
>Ticket URL: <http://tools.ietf.org/wg/payload/trac/ticket/5>
>payload <http://tools.ietf.org/payload/>
>