Re: [straw] Alissa Cooper's Discuss on draft-ietf-straw-b2bua-rtcp-15: (with DISCUSS and COMMENT)

Alissa Cooper <alissa@cooperw.in> Thu, 01 December 2016 14:38 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: straw@ietfa.amsl.com
Delivered-To: straw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505D21296F9; Thu, 1 Dec 2016 06:38:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=PJMxdirF; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=PqFWuz7k
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 L4mUSPDW_1Jg; Thu, 1 Dec 2016 06:38:18 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01DFB1298A6; Thu, 1 Dec 2016 06:35:54 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 48809204F2; Thu, 1 Dec 2016 09:35:53 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 01 Dec 2016 09:35:53 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=1gX2gx+WLigtjrG ZivuOZpIO6K8=; b=PJMxdirFtigF6Ra4s5ZW7tF4xr89WwZIRKd/iMSlNGFIlnP DdhyUTGTZD6Sp3pIOsSCMMzupgoOqX6QTbobrLsW84KvjOQQGfJweCPqWy3KHO7X SJ1BUghEZ0oiScYkac8vM1orNdT4BJHCTM+Nzgg9XWmShbFLn0RBEHSDrR/s=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=1gX2gx+WLigtjrGZivuOZpIO6K8=; b=PqFWuz7kYn2wnKLdNII+ vcT940UJ7aqRndyUt4+frg5sbCXeI/gi8R2lgAMAnsHE/uHh6tQzAdY5Bs/HsMr2 8hsEQFJVBpG0l9a0gjnIg9aUsbNUaQMBw01tMWBeUAjacqwozO7Dx/slAT1HGCwp z+iXzn/ZtCY8Jzst4tBtYBE=
X-ME-Sender: <xms:STVAWCL0FLn009Xn9wzrBTqNxcefZgW8495NBabS7x7qWzbxtRIuQQ>
X-Sasl-enc: wORgEvKChreuvxwl6TzZSKUsaN/rMXd2cZMR2zz9J9jp 1480602953
Received: from dhcp-10-150-9-159.cisco.com (unknown [173.38.117.93]) by mail.messagingengine.com (Postfix) with ESMTPA id CB25A7E330; Thu, 1 Dec 2016 09:35:52 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <20161201095810.3fe8873c@lminiero.lan>
Date: Thu, 01 Dec 2016 09:35:52 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <E08D2C56-38AE-4E35-BF39-748395F510A5@cooperw.in>
References: <148044949206.11740.15020735400605260114.idtracker@ietfa.amsl.com> <20161201095810.3fe8873c@lminiero.lan>
To: Lorenzo Miniero <lorenzo@meetecho.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/straw/uCxMrStNuGmG4E3RvJR-HASWXRE>
Cc: draft-ietf-straw-b2bua-rtcp@ietf.org, christer.holmberg@ericsson.com, IESG <iesg@ietf.org>, straw-chairs@ietf.org, straw@ietf.org
Subject: Re: [straw] Alissa Cooper's Discuss on draft-ietf-straw-b2bua-rtcp-15: (with DISCUSS and COMMENT)
X-BeenThere: straw@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" <straw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/straw>, <mailto:straw-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/straw/>
List-Post: <mailto:straw@ietf.org>
List-Help: <mailto:straw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/straw>, <mailto:straw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2016 14:38:23 -0000

Hi Lorenzo,

> On Dec 1, 2016, at 3:58 AM, Lorenzo Miniero <lorenzo@meetecho.com> wrote:
> 
>> = Section 3.2 =
>> 
>> (1)
>> "It is worthwile to point out that such a B2BUA may not necessarily
>>   forward all the packets it receives, though.  Selective Forwarding
>>   Units (SFU) [RFC7667], for instance, may aggregate or drop incoming
>>   RTCP messages, while at the same time originating new ones on their
>>   own.  For the messages that are forwarded and/or aggregated,
>> though, it's important to make sure the information is coherent."
>> 
>> I don't see much beyond this text that discusses the implications of
>> dropping and aggregating RTCP messages. Is this written down in
>> another document? If not, I'm wondering about what happens with RTCP
>> information aside from identifiers, SSRCs, and sequence numbers in
>> these cases. E.g., if a B2BUA drops one RTCP message containing an
>> RFC 7002 block but forwards the next one containing such a block,
>> won't the interval and the discard count reported to the receiver be
>> wrong? I assume there are a lot of cases involving XR blocks where
>> this could be a problem, but this document doesn't address those
>> cases.
>> 
> 
> 
> Good point. Do you think adding some text like "A B2BUA SHOULD NOT
> randomly drop or forward RTCP feedback of the same type within the
> context of the same session, as that may lead to confusing, if not
> broken, feedback to the recipients of the message." would help clarify
> the consequences of such a behaviour? If you think it's worthwhile, I
> might add as an example the RFC 7002 block one you presented.

That would help somewhat (although you’d have to explain what you mean by “feedback of the same type”), but I think there is a broader question here about all of the possible information sent within an RTCP message and the effects of selectively dropping or aggregating RTCP messages on that information. I just picked out the RFC 7002 example because it’s a document produced somewhat recently by one of my WGs, but I think a more comprehensive review of all the XR blocks and other RTCP info is warranted, *if* B2BUAs are actually currently dropping or aggregating this info.

Alissa