Re: [AVTCORE] Additions to RFC5285bis? was Re: [avtext] Mirja Kühlewind's Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS and COMMENT)

David Singer <singer@apple.com> Wed, 15 June 2016 16:49 UTC

Return-Path: <singer@apple.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 14E5412D9D2 for <avt@ietfa.amsl.com>; Wed, 15 Jun 2016 09:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level:
X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 V9sWrvpl51Al for <avt@ietfa.amsl.com>; Wed, 15 Jun 2016 09:49:03 -0700 (PDT)
Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD6012D97C for <avt@ietf.org>; Wed, 15 Jun 2016 09:48:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1466009333; x=2329922933; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=g9xgH6GdJT3+HQJUyPSdDUD7X8vp7u8tJaKBZHdWmhM=; b=TRCj1+tbOCcPG5/7VCJLJnLjIYtcZvSTbAbXpI8Jbo9lHcI9I1RmqZNK8a9gzHOl aMK68XLA9sYwYfShviUFKsOcwCW417PjKW1wWZ2chyIB46WiF9/O9203Q8Qv5Z1u d/4jRW1mjNYKBBTzsH25bfU/M82wuwG7ygI6v50gG9uFKPoYooPdz3DpaW3yThnI XOSQ90UyiXPwEpuBA5Fm2QdI6zmEyg3CnFeegldKWgKlH5hLqv3WwzSsjbBBp8AP v967sLxePhZkKnXhN3q2G7ClS9yxploDvLKHuVLImGxNnMfsA1m8YQ1XBrKqvb86 bl0qr5xBLCBrTAF5ESpAyw==;
Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 57.BE.25552.5F681675; Wed, 15 Jun 2016 09:48:53 -0700 (PDT)
X-AuditID: 11973e16-f79bc6d0000063d0-48-576186f5eb18
Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id FE.6C.29065.4F681675; Wed, 15 Jun 2016 09:48:52 -0700 (PDT)
Received: from singda.apple.com (singda.apple.com [17.212.152.248]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O8T00CUJO1GFX40@nwk-mmpp-sz09.apple.com>; Wed, 15 Jun 2016 09:48:52 -0700 (PDT)
Sender: singer@apple.com
Content-type: multipart/alternative; boundary="Apple-Mail=_1D42522A-78DB-4517-920E-6B91C662F8C9"
MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: David Singer <singer@apple.com>
In-reply-to: <0BA323FF-C204-43FC-9535-7F3918AEFA53@csperkins.org>
Date: Wed, 15 Jun 2016 09:48:52 -0700
Message-id: <35E8DD48-11B4-43F3-8051-01DFC13D8AF8@apple.com>
References: <20160613125529.12490.86798.idtracker@ietfa.amsl.com> <65EAADDF-EE7F-414B-AF3F-45BA4B729500@csperkins.org> <57601B7E.3070208@kuehlewind.net> <51E6A56BD6A85142B9D172C87FC3ABBB86ED634A@nkgeml513-mbx.china.huawei.com> <a9cc4845-3eeb-23eb-0076-ca9008dc85c1@ericsson.com> <0BA323FF-C204-43FC-9535-7F3918AEFA53@csperkins.org>
To: Colin Perkins <csp@csperkins.org>
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUi2FAYofu1LTHcYN0jRouXPSvZLdrPnWCx +HjvBqvFjtevWCyOn3nH6sDqsWTJT6YAxigum5TUnMyy1CJ9uwSujJ/f5zEVrFvKWDG/8Shb A+PTPsYuRg4OCQETiVknwroYOYFMMYkL99azdTFycQgJ7GWU2LGkgx0iYSJx8eFuZhBbSGAZ k8TkD4oQRdOYJD7tvwKWEBaQkPj4cTILiM0skCTx818XE4jNK6AnMfloAxtEzStGidnNISA2 m4CqxIM5x8CO4BRwlFj0OwokzAIUXvxgJTvIfGaBx8wSf18eYYeYYyMx4eUsJojFV5kknu/a ArZABKhjx/F/jBCXyko8ObmIBaRIQuA6m8T+mZ9ZJzAKz0Jy1CwkR0HEtSWWLXzNDGFrSuzv Xs6CKa4h0fltIusCRrZVjEK5iZk5upl55nqJBQU5qXrJ+bmbGEHRM91ObAfjw1VWhxgFOBiV eHgl7BPChVgTy4orcw8xSnOwKInzevskhgsJpCeWpGanphakFsUXleakFh9iZOLglGpg7HYx XFWvNk962rYrry1qvrO7ulyPi7Zocz/2Sajz3HXmhlSruif65Ytn//ib9/HE58g5zh7TPMW+ cn9zFOjnrp0/+Zr+c4EU5Yi9Z3c/UZv7MX4x39d1q/6bLnr4/fy9Mk0dhhB3j8XGYW7X2g+a bXPvkvh/SJHR3Uzsa4/QKV4rs99nb6v/UWIpzkg01GIuKk4EAK9JTKh/AgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOIsWRmVeSWpSXmKPExsUi2FAcoPulLTHcoPeImcXLnpXsFu3nTrBY fLx3g9Vix+tXLBbHz7xjdWD1WLLkJ1MAYxSXTUpqTmZZapG+XQJXxs/v85gK1i1lrJjfeJSt gfFpH2MXIyeHhICJxMWHu5khbDGJC/fWs4HYQgLLmCQmf1DsYuQCsqcxSXzafwWsSFhAQuLj x8ksIDazQJLEz39dTCA2r4CexOSjDWwQNa8YJWY3h4DYbAKqEg/mHANaxsHBKeAoseh3FEiY BSi8+MFKdpD5zAKPmSX+vjzCDjHHRmLCy1lMEIuvMkk837UFbIEIUMeO4/+grpaVeHJyEcsE RoFZSO6YheQOiLi2xLKFr5khbE2J/d3LWTDFNSQ6v01kXcDItopRoCg1J7HSVC+xoCAnVS85 P3cTIzjcCyN2MP5fZnWIUYCDUYmHt8AxIVyINbGsuDL3EKMEB7OSCO+P5sRwId6UxMqq1KL8 +KLSnNTiQ4wTGYH+nMgsJZqcD4zGvJJ4QxMTAxNjYzNjY3MTc1oKK4nzzvMGukggPbEkNTs1 tSC1COYoJg5OqQbGg0yfDlrxsdcE/3t2+d0N21yTqebTIx7//rYmS9OJ2+naTgv3N/M445Yd XWgjkubH6rZ6U5VHO78pD+frh7leenUHJXq7axv05l6+oz3na5NxuNejZ7L/AlTnvwrmtmLz SvUQOsYid1WtlYHT4sKVEsu0y13Ra9gs7iVd2F7w4ujhLzxC2xqVWIozEg21mIuKEwFOrDf9 6gIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/UNfSykP-v73RSp90SeNl4bai5jM>
X-Mailman-Approved-At: Sat, 18 Jun 2016 20:33:20 -0700
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "avtext@ietf.org" <avtext@ietf.org>, draft-ietf-avtcore-rfc5285-bis@ietf.org, "jonathan@vidyo.com" <jonathan@vidyo.com>, IETF AVTCore WG <avt@ietf.org>, "avtext-chairs@ietf.org" <avtext-chairs@ietf.org>, =?utf-8?Q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>, "draft-ietf-avtext-splicing-notification@ietf.org" <draft-ietf-avtext-splicing-notification@ietf.org>
Subject: Re: [AVTCORE] =?utf-8?q?Additions_to_RFC5285bis=3F_was_Re=3A_=5Bavtex?= =?utf-8?q?t=5D_Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-avtext-spli?= =?utf-8?q?cing-notification-07=3A_=28with_DISCUSS_and_COMMENT=29?=
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: Wed, 15 Jun 2016 16:49:05 -0000

Looks to me like we need to loot and pillage from at least the SDES draft, and update (and split into sub-sections, as it’s already long and a mix of topics) section 4.1 of 5285.  Yes, a section on repetition considerations and reliability seems reasonable to me.

> On Jun 15, 2016, at 6:07 , Colin Perkins <csp@csperkins.org> wrote:
> 
> Hi Magnus,
> 
> I agree that this makes sense, and is probably better than having more general discussion in the splicing notification draft.
> 
> Colin
> 
> 
> 
>> On 15 Jun 2016, at 08:54, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
>> 
>> Hi,
>> (As individual)
>> 
>> I think we stumbled on one thing that maybe should be included in the update of RFC5285.
>> 
>> Namely the discussion and reasoning why a sender may need to repeat a RTP header extension. See below excerpt from the discussion:
>> 
>> Den 2016-06-15 kl. 09:22, skrev Huangyihong (Rachel):
>>> Hi Mirja,
>>> 
>>> As one of the authors, please see my replies inline.
>>> 
>>> BR, Rachel
>>> 
>>> -----邮件原件----- 发件人: Mirja Kühlewind [mailto:ietf@kuehlewind.net] 发送时
>> 
>>> 
>>>>> - Why is just having the RTCP message not sufficient? Why are the
>>>>> RTP extensions needed as well?
>>>> 
>>>> RTP and RTCP are unreliable. The usual practice for these types of
>>>> extension is to send data both in RTCP, and in some number of RTP
>>>> packets, to increase the chances of it arriving in a timely manner.
>>>> The draft is following standard practice here.
>>> 
>>> Thanks for clarification. That could be clarified in the text.
>>> Because the text says that RTCP is used because the RTP information
>>> might get lost. So I was wondering why you are not only using RTCP
>>> and make sure you send it sufficiently often. Saying that this is
>>> common practice would be helpful from my point of view. Is there a
>>> reference for this?
>>> 
>>> [Rachel]: It's more like conventional method to increase robustness.
>>> As far as I know, there's no formal document to record this. Maybe we
>>> can address this like this
>>> 
>>> OLD "
>>> 
>>> To increase robustness against such case, the document also defines
>>> a complementary RTCP packet type to carry the same Splicing Interval
>>> to the splicer.
>>> 
>>> "
>>> 
>>> NEW " To increase robustness against such case, the document also
>>> defines a new RTCP packet type to carry the same Splicing Interval
>>> to the splicer. Since RTCP is also unreliable and may not so
>>> immediate as the in-band way, it's only considered as a complement to
>>> RTP header extension. "
>>> 
>>> 
>>>>> - And is the RTCP message send only once or multiple time? This
>>>>> is not specified.
>>>> 
>>>> That’s implementation dependent, and based on the expected packet
>>>> loss rate, the importance of the data, and the frequency with which
>>>> updates need to be sent.
>>> 
>>> A recommendation or discussion should be provided here.
>>> 
>>> [Rachel]: I think in Section 2, we have already provided some
>>> guidance on how often the Splicing Interval to be sent, which is not
>>> just limited to RTP header extension, also includes RTCP message.
>>> 
>> 
>> This topic is also discussed in  	
>> draft-ietf-avtext-sdes-hdr-ext-07 Section 4.2.3.
>> 
>> From my perspective I think the general transmission issues that needs to be considered with RTP header extension should be included in the update of RFC5285. That way each extension don't have to repeat it, only discuss additions or specific considerations for their formats.
>> 
>> To note I think that from SDES header Extension there should be included the topics of;
>> 
>> - MTU handling
>> - How many transmissions and if one can know it has reached the receiver
>> - Update handling, especially for extensions with data that can be sent using both RTCP and RTP header extension.
>> 
>> Note, this is my suggestion as an individual. Please discuss and comment.
>> 
>> Cheers
>> 
>> Magnus Westerlund
>> 
>> ----------------------------------------------------------------------
>> Services, Media and Network features, Ericsson Research EAB/TXM
>> ----------------------------------------------------------------------
>> Ericsson AB                 | Phone  +46 10 7148287
>> Färögatan 6                 | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------
>> 
> 
> 
> 
> -- 
> Colin Perkins
> https://csperkins.org/ <https://csperkins.org/>
David Singer
Manager, Software Standards, Apple Inc.