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]
