Internet DRAFT - draft-grozev-perc-double-rtx

draft-grozev-perc-double-rtx







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


        Using RTX with Privacy Enhanced RTP Conferencing (PERC)
                    draft-grozev-perc-double-rtx-00

Abstract

   This document describes the use of the RTX format for RTP packet
   retransmission in the context of a PERC (Privacy Enhanced RTP
   Conferenceing) conference.

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
   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.





Grozev & Ivov          Expires September 29, 2017               [Page 1]

Internet-Draft                 RTX double                     March 2017


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Terminating RTX . . . . . . . . . . . . . . . . . . . . . . .   2
   4.  RTP Padding . . . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   4

1.  Introduction

   In multi-endpoint RTP conferences it is desired for middleboxes (e.g.
   Selecting Forwarding Units (SFUs), or in the case of PERC Media
   Distributors (MDs)) to terminate RTP packet retransmission, because
   this can reduce the retransmission delay and the unnecessary
   retransmission of packets.  In the context of PERC, if RTX is handled
   as a regular media stream, then an MD can not terminate packet
   retransmission.

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.  Terminating RTX

   The RTX format (RFC 4588) uses the first two bytes of the RTP payload
   (the Original Sequence Number field (OSN)) to transport the RTP
   sequence number of the retransmitted packet.

   If the procedure used for regular media streams is also used for RTX,
   the MD does not have access to the OSN field, because it is E2E
   encrypted as part of the RTP payload, and this prevents it from
   terminating retransmissions.

   In the context of PERC, RTX should be performed only HBH.  That is,
   the payload of the RTX packet must be encrypted with the HBH context,
   but not with the E2E context.

   Specifically, when an entity retransmits a packet using RTX it:

   1.  Takes an E2E encrypted packet to be retransmitted.




Grozev & Ivov          Expires September 29, 2017               [Page 2]

Internet-Draft                 RTX double                     March 2017


   2.  Applies the RTX transformation (replaces the SSRC, payload type
       and sequence number, and inserts the OSN field in the payload.

   3.  Performs the HBH SRTP transformation.

4.  RTP Padding

   RFC3550 allows an RTP packet to contain only padding, and no payload.
   The number of padding bytes is contained in the last byte of the
   payload, and it is encrypted by SRTP.

   In the context of PERC, an MD does not have access to the padding
   length field of an RTX packet, and therefore it can not determine
   whether the packet contains non-padding payload or not.

   RTX packets with padding only are currently used by some bandwidth
   estimation algorithms when probing for additional bandwidth
   availability.  Bandwidth estimations have a strictly hop-by-hop
   context, so MDs therefore usually terminate them by recognizing and
   dropping all incoming probe packets.  They then generate new ones for
   their own estimations.

   In order to recognize an incoming packet as a probe-only one, an MD
   needs to inspect its last octet and compare it to the overall length
   of the payload.  Yet, in a PERC scenario this last octet is protected
   by PERC's end-to-end encryption and will hence be unreadable to the
   MD.  The MD will therefore have no choice but to treat this as a
   regular RTX packet: replace its sequence number, payload type, and
   SSRC and forward it to receivers that would likely fail in
   unpredictable ways (e.g., either failing SRTP authentication or maybe
   even feeding garbage data to their decoders).

   A similar problem also exists for probe packets the the MD generates
   and that receivers have no way to reliably recognize.

   In order for MDs and receivers to properly terminate bandwidth
   estimation, it is therefore necessary for an MD to reliably recognize
   such padding-only packets.

   The use of a single "padding-only" bit in any new or existing RTP
   header extension is ony way to achieve this.  PERC MDs are already
   likely to rely on the framemarking header extension
   [I-D.ietf-avtext-framemarking] and we propose transporting this bit
   there.  We propose to use the first bit of the unused bits in the
   format for non-scalable streams, which is marked as the P bit in the
   diagram below.





Grozev & Ivov          Expires September 29, 2017               [Page 3]

Internet-Draft                 RTX double                     March 2017


     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  ID=? |  L=0  |S|E|I|D|P 0 0 0|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                        Figure 1: Extension Format

5.  Security Considerations

6.  Acknowledgements

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-avtext-framemarking]
              Berger, E., Nandakumar, S., and M. Zanaty, "Frame Marking
              RTP Header Extension", draft-ietf-avtext-framemarking-04
              (work in progress), March 2017.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <http://www.rfc-editor.org/info/rfc3550>.

   [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
              DOI 10.17487/RFC4588, July 2006,
              <http://www.rfc-editor.org/info/rfc4588>.

   [RFC7667]  Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
              DOI 10.17487/RFC7667, November 2015,
              <http://www.rfc-editor.org/info/rfc7667>.

Authors' Addresses







Grozev & Ivov          Expires September 29, 2017               [Page 4]

Internet-Draft                 RTX double                     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

































Grozev & Ivov          Expires September 29, 2017               [Page 5]