[AVTCORE] adressing header extnsion trasmission consideration in RFC5285-bis
"Roni Even" <ron.even.tlv@gmail.com> Sun, 10 July 2016 11:24 UTC
Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DCD12B038 for <avt@ietfa.amsl.com>; Sun, 10 Jul 2016 04:24:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQf_-9aVs2GO for <avt@ietfa.amsl.com>; Sun, 10 Jul 2016 04:24:14 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D26001288B8 for <avt@ietf.org>; Sun, 10 Jul 2016 04:24:13 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id f126so61672200wma.1 for <avt@ietf.org>; Sun, 10 Jul 2016 04:24:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:thread-index :content-language; bh=e0KPesJSXPygITaH00AkG1NTuECoVK8pLCK59dvi5Ng=; b=VhFeYilGcFdoYb5JxFYG1IpoebNqqMCjuPgTqy7JdzfMQL9JH4qbA+fUuFpSXtXUze w1ppOr9Rpwe+8LugSJ1fWfkeE4T/CsijRB4fATHex271IISNmZ4w2MflfguGbRNfZJf4 evGrKvd4+UYU0HU+AJ9v8Uqww0SlXE/WtqFsT0rjHcG+LsmyFZ8jdKne2cWqSuqJT73i 1/7jaPvH/DQwLRX2HbYfTJenDcDv4M9sp1r9Bl4Ge6Pzj9ANjVZAzie/iMyXQIMn/CHK 3wcnffa8kCn28O0bWKd4u6xhKruMVHKKEolSgsHbdQ85u+dHR6a49BKZeGBx83OqmgVT ZX7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :thread-index:content-language; bh=e0KPesJSXPygITaH00AkG1NTuECoVK8pLCK59dvi5Ng=; b=fCamXSnR1qklJP6pnArNKlOMQqVNDUa3+QKAYD4O6BNACGKo59vUX0OapntrseOfhE 2B0M9a829pQF0mNoYKMmIdBSuyPV4lzzfzqKNqg8hjORKeINOJP7JeB1o0JSHZ1GxeJe bhGfYYeKbmA7w9DTKkTLzr7L9Hae4oppd1pPrSevZwl/IrGVidyNmc5Nt0JjFrPQweTj oray2X8hRC7buAI1LMe0knS1hB/Oa40wdH7SZl7c9ZDGbMYO83/IWHW/rj53QP4PA/LR yKDyh/ZPypf+ywJMhojXXx6a1OxvQVpkkZ0hkB72aYlrnIf3EteJ4bKKx3zccPNcYl25 XbMQ==
X-Gm-Message-State: ALyK8tJUGwW6kLAf0N97l2BNh4Qc1QDVoj2IJNffcGgr0NQd8EoOqrvIoM5b87w1vFLhJw==
X-Received: by 10.28.37.134 with SMTP id l128mr7022346wml.49.1468149852323; Sun, 10 Jul 2016 04:24:12 -0700 (PDT)
Received: from RoniPC (bzq-79-182-128-68.red.bezeqint.net. [79.182.128.68]) by smtp.gmail.com with ESMTPSA id o142sm11885468wme.20.2016.07.10.04.24.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 10 Jul 2016 04:24:11 -0700 (PDT)
From: Roni Even <ron.even.tlv@gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, Bo Burman <bo.burman@ericsson.com>
Date: Sun, 10 Jul 2016 14:21:54 +0300
Message-ID: <071501d1da9d$442cc380$cc864a80$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0716_01D1DAB6.697B3400"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdHam9lfqAb/HOb9TWGlTOd8ikenJw==
Content-Language: he
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/QZ3iPQ_gjzZyy-CVB7NxrwIOJow>
Cc: "Desineni, Harikishan" <hdesinen@quicinc.com>, avt@ietf.org, singer@apple.com
Subject: [AVTCORE] adressing header extnsion trasmission consideration in RFC5285-bis
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Jul 2016 11:24:17 -0000
Hi guys, During the IESG review of draft-ietf-avtext-splicing-notification the issue of when and how often an RTP sender should send the RTP header extension to provide high probability for the arrival of the header extension. On the email thread it was clear that this is a general topic and it should be better addressed in the rfc5285-bis draft. Dave Singer suggested that we use the text from section 4.2.3 of draft-ietf-avtext-sdes-hdr-ext-07. I looked at the text and it make sense to use it changing the reference from SDES RTP header extension to any header extension. I suggest to add a sub section 4.1.1 in 4.1 about Transmission considerations with the following text. 4.1.1 Transmission Considerations As is good network practice, data SHOULD only be transmitted when needed. The RTP header extension SHOULD only be present in a packet if that packet also contains one or more extension elements, as defined here. An extension element SHOULD only be present in a packet when needed; the signaling setup of extension elements indicates only that those elements can be present in some packets, not that they are in fact present in all (or indeed, any) packets. some general considerations for getting the header extensions delivered to the receiver: 1. The probability for packet loss and burst loss determine how many repetitions of the header extensions will be required to reach a targeted delivery probability, and if burst loss is likely, what distribution would be needed to avoid getting all repetitions of the header extensions lost in a single burst. 2. If a set of packets are all needed to enable decoding, there is commonly no reason for including the header extension in all of these packets, as they share fate. Instead, at most one instance of the header extension per independently decodable set of media data would be a more efficient use of the bandwidth. 3. How early the Header Extension item information is needed, from the first received RTP data or only after some set of packets are received, can guide if the header extension(s) should be in all of the first N packets or be included only once per set of packets, for example once per video frame. 4. The use of RTP level robustness mechanisms, such as RTP retransmission [RFC4588], or Forward Error Correction, e.g., [RFC5109] may treat packets differently from a robustness perspective, and header extensions should be added to packets that get a treatment corresponding to the relative importance of receiving the information. As a summary, the number of header extension transmissions should be tailored to a desired probability of delivery taking the receiver population size into account. For the very basic case, N repetitions of the header extensions should be sufficient, but may not be optimal. N is selected so that the header extension target delivery probability reaches 1-P^N, where P is the probability of packet loss. For point to point or small receiver populations, it might also be possible to use feedback, such as RTCP, to determine when the information in the header extensions has reached all receivers and stop further repetitions. Feedback that can be used includes the RTCP XR Loss RLE report block [RF C3611], which will indicate successful delivery of particular packets. If the RTP/AVPF Transport Layer Feedback Messages for generic NACK [RFC4585] is used, it can indicate the failure to deliver an RTP packet with the header extension, thus indicating the need for further repetitions. The normal RTCP report blocks can also provide an indicator of successful delivery, if no losses are indicated for a reporting interval covering the RTP packets with the header extension. Note that loss of an RTCP packet reporting on an interval where RTP header extension packets were sent, does not necessarily mean that the RTP header extension packets themselves were lost. The question is if this text make sense and also should we have the same text in both drafts? I will do some more editorial changes to section 4.1 and also have the last part of 4.1 as "4.1.2 header extension type considerations" Thanks Roni Even