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

From: "payload issue tracker" <[email-masked]>
Date: Tue, 10 Dec 2013 02:38:50 -0000

#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/>

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 11 Dec 2013 03:05:34 +0000

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