Internet DRAFT - draft-grozev-perc-ssrc

draft-grozev-perc-ssrc







Network Working Group                                          B. Grozev
Internet-Draft                                                   E. Ivov
Intended status: Standards Track                               Atlassian
Expires: September 29, 2017                                A. Gouaillard
                                                                   CoSMo
                                                          March 28, 2017


   Allowing Synchronisation Source (SSRC) and Timestamp Rewriting in
                Privacy Enhanced RTP Conferencing (PERC)
                       draft-grozev-perc-ssrc-00

Abstract

   Privacy Enhanced RTP Conferenceing allows middle boxes (MDs) to
   overwrite a certain set of fields in RTP packets, as long as they
   preserve their original values in the Original Header Block (OHB).
   This draft discusses the option of extending the OHB so that it would
   also include the RTP timestamp and Synchornization Source identifier
   (SSRC) within the set of fields an SSRC can modify.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 29, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Grozev, et al.         Expires September 29, 2017               [Page 1]

Internet-Draft                SSRC rewrite                    March 2017


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Extended Original Header Block (OHB) Format . . . . . . . . .   3
   4.  Alternative format  . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   In multi-endpoint RTP conferences, packet forwarding middleboxes
   (e.g.  Selecting Forwarding Units (SFUs)) adapt to variable bandwidth
   conditions by selectively dropping a subset of the packets when
   forwarding traffic to some or all recipients.  These dropped packets
   may correspond to certain participants, but more importantly
   simulcast layers.

   A common model for implementing simulcast consists in having senders
   send multiple resolutions to the middlebox, each with its own SSRC,
   as well as distinct sequence number and timestamp spaces.
   Middleboxes on the other hand, often choose to only make receivers
   aware of a single SSRC, timestamp and sequence number space, as shown
   on the figure below.


    +------+                     +-----+                     +--------+
    |      |--SSRC1 Timestamp1-->|     |                     |        |
    |Sender|--SSRC2 Timestamp2-->| SFU |--SSRC4 Timestamp4-->|Receiver|
    |      |--SSRC3 Timestamp3-->|     |                     |        |
    +------+                     +-----+                     +--------+


                      Figure 1: Trickle State Updates

   The advantage of this model consists in the fact that receivers
   require no custom logic to support it as all they ever see is a
   single incoming video stream.




Grozev, et al.         Expires September 29, 2017               [Page 2]

Internet-Draft                SSRC rewrite                    March 2017


   In its current state the PERC double specification does not allow for
   SSRC and timestamps to be overwritten, which makes it impossible for
   SFUs to continue operating in this manner.  This document therefore
   defines an extended OHB format and explains the specifics of
   implementing SSRC and timestamp rewriting within a PERC environment.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Extended Original Header Block (OHB) Format

   The OHB header extension is defined in the "double" draft
   [I-D.ietf-perc-double].  The current version defines a structure
   which can contain atmost the original RTP Payload Type (PT) and SEQ
   fields, and this restricts the MD to only modifying thesetwo fields,
   while, as explained before, for the simulcast usecase the MD may also
   need to modify the SSRC and the timestamp.

   This specification extends the OBH structure so that it can contain
   the additional fields needed for the WebRTC 1.0 simulcast use case.
   It still uses the 4-bit length field of the header extension header
   [RFC5285] to encode the structure of the remainingbytes.
   Specifically, it encodes which of these four fields will be present
   in the following bytes: Payload Type (PT, 1 byte, including an extra
   R-bit), Sequence Number (SEQ, 2 bytes), SSRC(4 bytes), Timestamp (TS,
   4 bytes).

   If the length field has a value of 0, 1 or 2 (indicating that there
   are respectively 1, 2 or 3 more bytes), then the format is exactly
   the same as in the current draft.  This means that an endpoint which
   implements the extended format can workwith the current format
   without modification.

   The following table lists the fields which are encoded (and the order
   in which they are included) for the different values of the length
   field and the R-bit.  The R-bit is the most significant bit (MSB) of
   the PT field, and is present if and only if the PT field is present.
   If the extension includes the PT field, it consists of an R-bit (MSB)
   and 7 bits for the original RTP Payload Type.  The R-bit is used to
   encode which fields are included, when there is ambiguity.








Grozev, et al.         Expires September 29, 2017               [Page 3]

Internet-Draft                SSRC rewrite                    March 2017


         +---+-----------------+--------------+
         |len| R-bit set       |R-bit not set |
         +---+-----------------+--------------+
         | 0 |PT               |              |
         | 1 |SEQ              |              |
         | 2 |PT, SEQ          |              |
         | 3 |SSRC             |              |
         | 4 |PT, SSRC         | PT, TS       |
         | 5 |SEQ, SSRC        |              |
         | 6 |PT, SEQ, SSRC    | PT, SEQ, TS  |
         | 7 |SSRC, TS         |              |
         | 8 |PT, SSRC, TS     |              |
         | 9 |SEQ, SSRC, TS    |              |
         | 10|PT, SEQ, SSRC, TS|              |
         +---+-----------------+--------------+


                           Figure 2: OHB Fields

   The fields encoded in the OHB header extension, for different values
   of the length field and the R-bit.

4.  Alternative format

   In the context of SVC an MD might need to modify the M bit of RTP
   packets (for example when the higher layers of a frame are dropped,
   and the frame terminates "early").

   The original format from the "double" draft [I-D.ietf-perc-double],
   as well as the format described above don't allow for the M bit to be
   modified.

   One more bit of information which may be desired to be transported
   from a PERC sender to an MD is whether a packet contains actual
   payload, or consists only of padding (i.e. discardable data).

   These two bits can be transported with the following alternative
   format for the OHB header extension:


          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |   ID  |  len  |P|S|s|T|M|p|0 0|
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 3: Alternative OHB format




Grozev, et al.         Expires September 29, 2017               [Page 4]

Internet-Draft                SSRC rewrite                    March 2017


   Where:

      P specifies the presence of a Payload Type byte.

      S specifies the presence of a Sequence Number field (2 bytes).

      s specifies the presence of a SSRC field (4 bytes).

      T specifies the presence of a Timestamp field (4 bytes).

      M contains the original value of the M bit.

      p is a padding-only bit, which indicates that the packet contains
      only padding and can be discarded.

5.  Security Considerations

6.  Acknowledgements

   Sergio Garcia Murillo raised the need for MDs to overwrite the M-bit
   and suggested the alternative extra-byte encoding described in
   Section 4.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

7.2.  Informative References

   [I-D.ietf-perc-double]
              Jennings, C., Jones, P., and A. Roach, "SRTP Double
              Encryption Procedures", draft-ietf-perc-double-03 (work in
              progress), March 2017.

   [RFC5285]  Singer, D. and H. Desineni, "A General Mechanism for RTP
              Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
              2008, <http://www.rfc-editor.org/info/rfc5285>.

Authors' Addresses







Grozev, et al.         Expires September 29, 2017               [Page 5]

Internet-Draft                SSRC rewrite                    March 2017


   Boris Grozev
   Atlassian
   303 Colorado Street, #1600
   Austin  78701
   USA

   Phone: +1-512-640-3000
   Email: bgrozev@atlassian.com


   Emil Ivov
   Atlassian
   303 Colorado Street, #1600
   Austin  78701
   USA

   Phone: +1-512-640-3000
   Email: eivov@atlassian.com


   Alexandre Gouaillard
   CoSMo Software Consulting
   28 Bukit Pasoh Rd
   Singapore  089842
   Singapore

   Phone: +65-9270-9152
   Email: alex.gouaillard@cosmosoftware.io























Grozev, et al.         Expires September 29, 2017               [Page 6]