From nobody Thu Dec 1 00:42:13 2016 Return-Path: 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 4D4DD129C31 for ; Thu, 1 Dec 2016 00:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=aruba.it 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 x6h0271Bq8yz for ; Thu, 1 Dec 2016 00:41:58 -0800 (PST) Received: from smtpcmd04135.aruba.it (smtpcmd04135.aruba.it [62.149.158.135]) by ietfa.amsl.com (Postfix) with ESMTP id D165B129C36 for ; Thu, 1 Dec 2016 00:41:47 -0800 (PST) Received: from lminiero.lan ([93.44.67.125]) by smtpcmd04.ad.aruba.it with bizsmtp id EYhg1u00K2i9R4V01YhhPX; Thu, 01 Dec 2016 09:41:44 +0100 Date: Thu, 1 Dec 2016 09:41:39 +0100 From: Lorenzo Miniero To: "Alvaro Retana" Message-ID: <20161201094139.7f6d12cb@lminiero.lan> In-Reply-To: <148044754162.11662.5213146159999935353.idtracker@ietfa.amsl.com> References: <148044754162.11662.5213146159999935353.idtracker@ietfa.amsl.com> Organization: Meetecho X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1480581704; bh=p5Vo+anyb72qIdc9dTYsA0/FnafqjG/sHLyLA4CKkAE=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=AdgIXuTkwQ/wLCAPU5myZu2BAXHPHWYt+MpeR8XwWiauvfzfQpQuWqCzDqR9mFthk w+JalYz5Mz7jUwi3JIpccgPNw3vzvAO7IHSelDOGk/7osSXcf2JaRigrawwRPvbV+D C7evi6vw9HMSsqsUhK0eiP7FaGUo90PBYX4cOgK61jb4mc8PWO1+NwbQvi/h6as82w uX3bLizm86KUqNI9sS6ILbCERy1gAINvjkDd17wmjB8TZgQ8odzqDzjCab6UpbjWD0 30Te3OamLanv1vzcD6JteOae+dXzWTqDMmQo6kYYn62haaAPzxB4+GgPeiXCYHnup0 AMpnSGPHeZPzw== Archived-At: Cc: draft-ietf-straw-b2bua-rtcp@ietf.org, christer.holmberg@ericsson.com, The IESG , straw-chairs@ietf.org, straw@ietf.org Subject: Re: [straw] Alvaro Retana's No Objection on draft-ietf-straw-b2bua-rtcp-15: (with 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 08:42:02 -0000 On Tue, 29 Nov 2016 11:25:41 -0800 "Alvaro Retana" wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-straw-b2bua-rtcp-15: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html for more > information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ > > Hi Alvaro, thanks for reviewing the document! Responses inline. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [1] As I understand it, a Media-Aware Relay is an instance of a > RTP/RTCP translator. I'm wondering whether the behavior in 3.2 > can/should be more broadly applied to other types of translators, and > not just to a media-aware B2BUA. ?? [Disclaimer: I am out of my > depth here...] > The scope of the WG is disciplining the behaviour of B2BUAs, mostly, so that's why the document is focused on those topologies in particular. > [2] The guidelines in 3.2 have a normative "MUST" attached to them: > "...a media-aware B2BUA MUST handle incoming RTCP messages to forward > following this guideline". However, some of the references are not > Normative. I assume that (as with the guidelines related to RFC3550) > the text in 3.2 represents a behavior beyond what is described in the > references, which implies to me that those references should be > Normative. The solution seems simple: move rfc3611, rfc5104, etc. to > be Normative references...but I-D.alvestrand-rmcat-remb is also > referenced, which not only expired 3 years ago, but it is marked as > Experimental. Can the expected behavior from > I-D.alvestrand-rmcat-remb be somehow defined in this document so that > the reference is not needed? > Thanks for the advice, I'll move the references as suggested. As to REMB, other reviews addressed the same point and I plan to remove references to that (which was originally added to address its extensive usage in WebRTC) and replace the examples/discussions with similar feedback, e.g., TMMBR. Thanks! Lorenzo > > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw From nobody Thu Dec 1 00:59:27 2016 Return-Path: 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 87B6B129C54 for ; Thu, 1 Dec 2016 00:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aruba.it 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 eF2DllhljOEb for ; Thu, 1 Dec 2016 00:59:16 -0800 (PST) Received: from smtpcmd04135.aruba.it (smtpcmd04135.aruba.it [62.149.158.135]) by ietfa.amsl.com (Postfix) with ESMTP id B5E9E129C53 for ; Thu, 1 Dec 2016 00:59:13 -0800 (PST) Received: from lminiero.lan ([93.44.67.125]) by smtpcmd04.ad.aruba.it with bizsmtp id EYyA1u01Z2i9R4V01YyASu; Thu, 01 Dec 2016 09:58:11 +0100 Date: Thu, 1 Dec 2016 09:58:10 +0100 From: Lorenzo Miniero To: "Alissa Cooper" Message-ID: <20161201095810.3fe8873c@lminiero.lan> In-Reply-To: <148044949206.11740.15020735400605260114.idtracker@ietfa.amsl.com> References: <148044949206.11740.15020735400605260114.idtracker@ietfa.amsl.com> Organization: Meetecho X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1480582691; bh=OO5NeS0oN2Ic25aQY1aTiz2a75vq+6y5DM6VDehF+Sw=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=M1t50QDimw5vMubrCCqVFgVWkp7Q77YO6lxSupQheDDWPJsWMaMnp2lk5OAZqTeFd KFWRbiQ0X3wjyK8zxXDuyxgKGhFiYxjqgpZ1R2YL6rSDXUVOKuVT1TpRgIr3t6Dav0 QSCpsrUVSODNVxNreBFsSpKk4NEc2wAfX+dbq2kzo9pC8mctqY33YaDfTfSZgMtsVZ 7ZHbcgOBOxuWHwA4enJ3BQU5iYE1WPvm0ya2/Yc0CbeKNO7DQ7mkLaxCdKBui3E2PN f1R5DDqderg9Cd5akRCH9ijaFeBW6Ru2x8kQEfKGKt2mCnDim97T/HCBo+a/NqHDV+ KRuXJyhzlQUVg== Archived-At: Cc: draft-ietf-straw-b2bua-rtcp@ietf.org, christer.holmberg@ericsson.com, The IESG , 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 08:59:23 -0000 On Tue, 29 Nov 2016 11:58:12 -0800 "Alissa Cooper" wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-straw-b2bua-rtcp-15: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html for more > information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ > > Hi Alissa, thanks for reviewing the document! A few comments inline. > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > = Section 3.1 = > > I think there is a lack of clarity in the recommendations here, > because "such attributes" aren't listed out anywhere and then later > it's not clear what the "mentioned attributes" are referring to. I've > proposed some edits below to try to clarify what I think the > recommendations are saying -- does this capture the intent? > > OLD > However, certain SDP attributes may > lead to call failures when forwarded by a media relay. Such > attributes SHOULD NOT be forwarded. One notable example is the > 'rtcp' [RFC3605] attribute, that UAC may make use of to explicitly > state the port they're willing to use for RTCP. Considering the > B2BUA would relay RTCP messages, the port as seen by the other UAC > involved in the communication would differ from the one negotiated > originally, and it MUST be rewritten accordingly. Apart from the > mentioned attributes, B2BUAs SHOULD forward all other SDP > attributes they don't have a reason not to forward, in order to avoid > breaking additional functionality endpoints may be relying on. > > NEW > However, certain SDP attributes may > lead to call failures when forwarded by a media relay. One notable > example is the > 'rtcp' [RFC3605] attribute, that UAC may make use of to explicitly > state the port it is willing to use for RTCP. Assuming that the > B2BUA would relay RTCP messages, the port as seen by the other UAC > involved in the communication would differ from the one negotiated > originally. The 'rtcp' attribute MUST be rewritten accordingly, > rather than being forwarded. Any other attributes known to the B2BUA > to cause call failures when forwarded SHOULD NOT be forwarded. B2BUAs > SHOULD forward all other SDP attributes in order to avoid breaking > additional functionality endpoints may be relying on. > It does, thanks for the proposed text! Alia and Ben proposed some minor revision to this in related comments, so I'll integrate the new text in the next version. > = 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. > (2) > "SR: [RFC3550] > If the B2BUA has changed the SSRC of the sender RTP stream a > Sender Report refers to, it MUST update the SSRC in the SR > packet header as well. If the B2BUA has changed the SSRCs of other > RTP streams too, and any of these streams are addressed in any of the > SR report blocks, it MUST update the related values in the SR > report blocks as well. If the B2BUA has also changed the base > RTP sequence number when forwarding RTP packets, then this change > needs to be properly addressed in the 'extended highest sequence > number received' field in the Report Blocks." > > Why is the recommendation about the extended highest sequence number > received not also a MUST? > You're right, I'll fix this. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > = Section 3.2 = > > s/properly address/reflected/ > Thanks! Lorenzo > > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw From nobody Thu Dec 1 01:02:49 2016 Return-Path: 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 99414129D05 for ; Thu, 1 Dec 2016 01:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aruba.it 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 U4Dv5m0VINRn for ; Thu, 1 Dec 2016 01:02:47 -0800 (PST) Received: from smtpcmd04135.aruba.it (smtpcmd04135.aruba.it [62.149.158.135]) by ietfa.amsl.com (Postfix) with ESMTP id C9B55129C68 for ; Thu, 1 Dec 2016 01:01:40 -0800 (PST) Received: from lminiero.lan ([93.44.67.125]) by smtpcmd04.ad.aruba.it with bizsmtp id EYyd1u00V2i9R4V01Yydpw; Thu, 01 Dec 2016 09:58:38 +0100 Date: Thu, 1 Dec 2016 09:58:36 +0100 From: Lorenzo Miniero To: "Ben Campbell" Message-ID: <20161201095836.0da4e320@lminiero.lan> In-Reply-To: <63D461D3-3575-4590-ACCB-155AAC9F96D5@nostrum.com> References: <148045829948.11748.1738734421697710936.idtracker@ietfa.amsl.com> <8A8BF586-01EE-4639-A072-BC8D8451D84B@nostrum.com> <63D461D3-3575-4590-ACCB-155AAC9F96D5@nostrum.com> Organization: Meetecho X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1480582718; bh=OzTHvxQ43HCZkifW6vIs2DHAbCN1od8tepk2jyhe3mw=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=Ryryy/2inz87ISjeAIDgc4V9rut8AQAShVxnV87/JEs5nubbNyxq4msgIGuNUOLLR Z1GgtFDSKxXgYrShVs4ii8Imh6Zmvn+99Aj0DYJKaFLA5UMb68abjXKdIzI0blBaLc +1xHt8E8/4Z0gVPk4pLLVjefWFs++z+QTvLWLirImAzmVa9fvgmMB0BTvuCW9zheGE 7oxUCXphDs7G7EVZt7aePOl6oCVjhb/ueW8y0lxgaaVU4bseNgK5+VnFGaXLfGdAjL wFFWBWLgbJ2Fp5YSKcLEBpenxtk51wpR9NHTliTFSJyZ0m8xGC76TzYxy7QSi+qGZR jBKB60n5U2PfA== Archived-At: Cc: straw@ietf.org, straw-chairs@ietf.org, The IESG , Christer Holmberg , Alia Atlas , draft-ietf-straw-b2bua-rtcp@ietf.org Subject: Re: [straw] Alia Atlas' No Objection on draft-ietf-straw-b2bua-rtcp-15: (with 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 09:02:49 -0000 On Tue, 29 Nov 2016 16:59:53 -0600 "Ben Campbell" wrote: > On 29 Nov 2016, at 16:56, Alia Atlas wrote: > > > Hi Ben, > > > > On Tue, Nov 29, 2016 at 5:46 PM, Ben Campbell > > wrote: > >> On 29 Nov 2016, at 16:24, Alia Atlas wrote: > >> > >> Alia Atlas has entered the following ballot position for > >>> draft-ietf-straw-b2bua-rtcp-15: No Objection > >>> > >>> When responding, please keep the subject line intact and reply to > >>> all > >>> email addresses included in the To and CC lines. (Feel free to > >>> cut this > >>> introductory paragraph, however.) > >>> > >>> > >>> Please refer to > >>> https://www.ietf.org/iesg/statement/discuss-criteria.html > >>> for more information about IESG DISCUSS and COMMENT positions. > >>> > >>> > >>> The document, along with other ballot positions, can be found > >>> here: > >>> https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ > >>> > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> COMMENT: > >>> ---------------------------------------------------------------------- > >>> > >>> I agree with Alissa that the set of attributes that fall into each > >>> category is just not clear or fully specified. > >>> I'm not sure about better wording - but at least indicating how to > >>> categorize the different attributes (if listing them > >>> all isn't reasonable) would help. Describing the category as > >>> "those that > >>> cause issues"' is not helpful. > >>> > >> > >> Hi Alia, > >> > >> Did you find Alissa's suggested wording helpful? > >> > > > > Not sufficiently.... > > > > > >> The problem is, these can't reasonably be enumerated. It's > >> basically the > >> set of any attributes that have implied assumptions that the > >> attribute > >> describes the immediate peer. > >> > > > > Right, I gathered that the set of attributes was too large - but > > your response starts to indicate the categories that could be used. > > > > I.e. instead of "Any other attributes known to the B2BUA to cause > > call failures when forwarded SHOULD NOT be forwarded." perhaps > > something like > > (wildly out of my core expertise of course) > > > > "Some attributes have an implied assumption that the attribute > > describes > > the immediate peer. A clear example of this is the 'rtcp' > > attribute, which > > describes the expected peer port. Other attributes might include the > > immediate peer's IP address, preferred transport, etc. In general, > > the guideline is to require rewriting of attributes that are > > implicitly describing the immediate peer. If in doubt during > > implementation, testing > > to determine whether a call failure occurs should be done." > > That seems like a reasonable clarification, assuming the authors > agree that the new first sentence adequately describes all the > problematic attributes (that is, there are no attributes I have > forgotten about that do not have that specific implication, but still > break things.) > Alia, Ben, thanks for proposing fixes to the text! I agree this does clarify the point we were trying to make, and significantly improves the paragraph. I'll integrate this in the next version of the document. Thanks! Lorenzo > Thanks! > > Ben. > > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw From nobody Thu Dec 1 01:04:21 2016 Return-Path: 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 1BA9D129C9C for ; Thu, 1 Dec 2016 01:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aruba.it 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 mOj1DF7CNBMx for ; Thu, 1 Dec 2016 01:04:01 -0800 (PST) Received: from smtpcmd04135.aruba.it (smtpcmd04135.aruba.it [62.149.158.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC47129C9F for ; Thu, 1 Dec 2016 01:01:56 -0800 (PST) Received: from lminiero.lan ([93.44.67.125]) by smtpcmd04.ad.aruba.it with bizsmtp id EYys1u00Q2i9R4V01Yys1n; Thu, 01 Dec 2016 09:58:52 +0100 Date: Thu, 1 Dec 2016 09:58:51 +0100 From: Lorenzo Miniero To: "Spencer Dawkins" Message-ID: <20161201095851.39fb8cd7@lminiero.lan> In-Reply-To: <148057381177.9603.6990677534643010984.idtracker@ietfa.amsl.com> References: <148057381177.9603.6990677534643010984.idtracker@ietfa.amsl.com> Organization: Meetecho X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1480582732; bh=b6LTLQTkAfyIsWcV6HfAMIWHJn7tvv+neR1lSC85gzM=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=iK4F6549H2llmsBXQ0fgsKvojZPaZK8F56iK0F8/XrVbrgeL7Vt2U1lkTmcFYhxVX aB+IkCy2sElqMGGgAQlbviX6uuRMLEHxJGOGiK7Vt4YiGlmHd9tRokQSRE4Lz3AIay /Ahdttsn0MXxYcffhjqNlb7KMGrzO9hTzVYdXoeVGwEqZvN2V2hyv6Ep1lyhpGnjvs AY17KlNpWx+9Pg6/nhpMzdK7O3Glx1DiUhNrNipfJpMbjrl45+DFf+v3ACGXH6iyRJ Gl7F0FwrWCw3RStry2s45Xrd5ReBMn1meHbKaW9q4j/f79OR16EfBB6ya+L9lDb7XE GVbGxXyZMKCvg== Archived-At: Cc: straw@ietf.org, christer.holmberg@ericsson.com, The IESG , straw-chairs@ietf.org, draft-ietf-straw-b2bua-rtcp@ietf.org Subject: Re: [straw] Spencer Dawkins' No Objection on draft-ietf-straw-b2bua-rtcp-15: (with 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 09:04:02 -0000 On Wed, 30 Nov 2016 22:30:11 -0800 "Spencer Dawkins" wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-straw-b2bua-rtcp-15: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html for more > information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for responding to Magnus's thorough TSV-ART review (for > reference, > https://www.ietf.org/mail-archive/web/tsv-art/current/msg00111.html). > > I'm inclined to agree with the resolutions you've proposed (for > reference, > https://www.ietf.org/mail-archive/web/tsv-art/current/msg00112.html), > but I do have one question - given that you want to include REMB, > because it's deployed in Chrome and Firefox, and given that > https://datatracker.ietf.org/doc/draft-alvestrand-rmcat-remb/ hasn't > moved in three years and RMCAT is doing something else, what's your > plan for publishing this draft as an RFC that's not stuck in MISSREF > forever? > > Hi Spencer, thanks for reviewing the document! I agree with you that this is an issue. The plan is to replace the parts where we talk about REMB with references to standard documents with similar purposes, e.g., TMMBR (which if I'm not mistaken has been implemented in Firefox to address the same requirement REMB fulfilled). Do you believe this change would fix the problem? Thanks! Lorenzo From nobody Thu Dec 1 06:38:24 2016 Return-Path: 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: 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 In-Reply-To: <20161201095810.3fe8873c@lminiero.lan> Date: Thu, 1 Dec 2016 09:35:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148044949206.11740.15020735400605260114.idtracker@ietfa.amsl.com> <20161201095810.3fe8873c@lminiero.lan> To: Lorenzo Miniero X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-straw-b2bua-rtcp@ietf.org, christer.holmberg@ericsson.com, IESG , 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = wrote: >=20 >> =3D Section 3.2 =3D >>=20 >> (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." >>=20 >> 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. >>=20 >=20 >=20 > 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=E2=80=99d have to explain what = you mean by =E2=80=9Cfeedback of the same type=E2=80=9D), 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=E2=80=99s 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 =20 From nobody Fri Dec 2 01:57:18 2016 Return-Path: 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 2DDAF129BBB; Fri, 2 Dec 2016 01:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 JIrKTaniRkng; Fri, 2 Dec 2016 01:57:09 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D7C1129BB3; Fri, 2 Dec 2016 01:57:08 -0800 (PST) X-AuditID: c1b4fb2d-4612998000001117-af-58414573bc76 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id A2.32.04375.37541485; Fri, 2 Dec 2016 10:57:07 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.319.2; Fri, 2 Dec 2016 10:57:04 +0100 To: Lorenzo Miniero References: <394e842e-d0bc-309f-86ac-8279741dd8a3@ericsson.com> <20161129123116.033312d7@lminiero.lan> From: Magnus Westerlund Message-ID: <088e785d-4758-2d77-4926-8fe165aee232@ericsson.com> Date: Fri, 2 Dec 2016 10:57:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <20161129123116.033312d7@lminiero.lan> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM2J7oG6xq2OEwYHNUhbbtyxgsrjV/JjV Ytq8j4wWs/YsYnFg8Viy5CeTR8fD++weXy5/ZgtgjuKySUnNySxLLdK3S+DKOPLnGHvBLKeK r+2H2BoYZ5t0MXJySAiYSPxfOY2xi5GLQ0hgHaPE26+/2CGcZYwSr2a0M4JUCQu4SvQv3cEE YosIaEnMmDsPLC4kkCHR8noeO4jNLFAgsaptHZjNJmAhcfNHIxuIzStgL7H/wQVmEJtFQEWi 7dt/MFtUIEbi07q/7BA1ghInZz5hAbE5BYwl/pz4ygQx00Ji5vzzjBC2vETz1tnMEHu1JRqa OlgnMArMQtI+C0nLLCQtCxiZVzGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIEhu3BLb91dzCu fu14iFGAg1GJh/eDlUOEEGtiWXFl7iFGCQ5mJRHe3S6OEUK8KYmVValF+fFFpTmpxYcYpTlY lMR5zVbeDxcSSE8sSc1OTS1ILYLJMnFwSjUwqkeUKB2wUz8TMk/37LxG2wdTV0wwqnsgJKJf d14n+e6J6HdxF49/+8940mmj0fLsvtKr0xXvPnhyV2x35tkzUwPklrm7XAgr+1Kx6MxRPc+N izZvVbIW/TMlRmWS2qaCMt9TOyoWzd4bUNcwu09G9bmTZrLEQ+Gk23K6KaKyCQ8fXTrrY53x VYmlOCPRUIu5qDgRAJ7BE8NXAgAA Archived-At: Cc: "tsv-art@ietf.org" , straw@ietf.org, "tsv-ads@tools.ietf.org" Subject: Re: [straw] TSV-ART review of draft-ietf-straw-b2bua-rtcp-15 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 09:57:13 -0000 Den 2016-11-29 kl. 12:31, skrev Lorenzo Miniero: > On Fri, 25 Nov 2016 15:49:01 +0100 > Magnus Westerlund wrote: > >> Hi, >> >> I have done this review as part of the TSVART's task to review >> documents with potential transport impact. >> >> Below you will find a number of comments on issues that I found. I >> think there are several significant issues below: 2, 3, 4, and 6. The >> rest would be good to address. I am sorry that this review is late in >> the process. >> > > > Hi Magnus, > > thanks for reviewing this again! > > >> >> 1. Section 3.1: I am surprised that there are no discussion for a >> Media Relay regarding a=rtcp-mux and its impact on where RTP/RTCP >> packets will flow and if a=rtcp attribute is at all relevant. I think >> there would be clearer if one in the context of a=rtcp also discusses >> a=rtcp-mux and how that impacts the actual transport layer flows that >> will result. >> > > > You're right, we talk about 'rtcp-mux' in 3.2 but not 3.1, I'll fix > this. Considering we're talking of a possibly/probably media-unaware > component, would you be ok with a text suggesting a 3.1 Media Relay > SHOULD reject 'rtcp-mux'? If the MR is able to demux RTP/RTCP then it's > looking at packets rather than just forwarding them, making it more of a > Media-aware Relay than a plain Media Relay. I would say that it is a SHOULD unless the signalling component has verified that demultiplexing can be performed without any RTP Payload Type rewrites, i.e. no overlap between any RTP PTs and the RTCP PT space. This is quite likely in many point to point via the MR scenarios, but becomes possibly difficult in any multiparty scenarios. > > >> 2. Section 3.1: >> While [RFC7022] can prevent this from >> happening, there may be implementations that don't make use of it. >> As such, a B2BUA MAY rewrite CNAME items if any potential >> collision is detected, even in the Media Relay case. If a B2BUA does >> indeed decide to rewrite CNAME items, though, then it MUST generate >> new CNAMEs following [RFC7022]. >> >> While the Media Relay is generally safe in regards to the use of RTP >> header extensions, this text above actually requires translation of >> the RTP header extension identified as >> "urn:ietf:params:rtp-hdrext:sdes:cname" [RFC7941]. Then also that >> needs to be translated. >> > > > Mh, this would also mean making a plain MR (or assuming it is) too aware > of the media it is handling, especially if it comes up to editing RTP > extensions. Anyway, since we're talking about CNAME rewriting, it makes > sense to refer to RFC7941 too where that's mentioned, so I'll update the > sections where that happens. Yes, I wonder if you should rather point out that one can't use an MR in this case, but can use a very basic Media-Aware Relay (Translator) that only translates the CNAME items, including the RTP header extension if negotiated. > > >> 3. Section 3.2: >> >> Also this section will need a discussion of RTP header extensions. So >> one set of header extensions that may be translated are any SDES >> items. So CNAME, MID, RID should be considered. Especially MID and >> RID as they are directly related to SDP they are likely to need >> translation. >> >> However, also the set of transport related information, like the ones >> that has been proposed for use with RMCAT but have not yet been >> approved. As they can have packet specific information, if one starts >> removing packets, then one may need to consider these also. >> > > > Isn't this widening the scope too much? The purpose of the draft is to > address RTCP-related problematics, and opening the door to RTP (even > just header extensions) could mean adding way more text and cases to > this than originally planned. I think the relevant level here is to point out that there exist RTP header extensions, and especially the SDES ones, i.e. pointer to RFC7941 that can result in that information that has been the responsibility of RTCP can show up in RTP and thus require translation of also RTP packets. This has potential MTU issues. > > >> 4. Section 3.2: SR Entry: >> >> I like to note that if an Media Relay act in the role of a SFU, then >> it needs to track in the outgoing SR, the relevant number of packets >> sent, total amount of bytes sent to that particular receiver, rather >> than what was received. Note, that as this is SR specific, it does >> not apply to RR. >> > > > Ok, I'll clarify this in the SR text. > > >> I note that SFU also requires sequence number rewriting, which >> affects other RTCP packet type that reference sequence numbers, like >> NACK. >> > > > That's already in the document, at least for NACKs themselves. Yes, but also RTCP SR needs to be locally generated based on what is actually sent. So, I think there is a point of pressing a generic clarification that SFU results in RTP sequence number rewrites affecting RTCP. > > >> 5. Section 3.2: >> >> REMB: [I-D.alvestrand-rmcat-remb] >> A media-aware B2BUA MUST properly rewrite the additional >> SSRC identifier(s) in REMB packets, if it changed the related RTP >> SSRC of the media sender. >> >> I assume that you have had some thought about the need to include >> this individual proposal. I do note that it is not clear if this ever >> will be published, especially considering the RMCAT WG's work on a >> different feedback format. >> > > > We had this in the beginning since most of our experimentation in this > field was based on WebRTC implementations, and REMB played a great deal > in that respect. Failing to adapt things would lead to recipients > possibly flooded with data they couldn't handle, due to missing or > broken feedback. > > I do know the REMB draft has been obsoleted for a while, but it's still > used in both Chrome and Firefox, and so I thought it made sense to keep > the related text there, as it is indeed still useful in the "real > world". If you believe we should rather remove it, or replace > references to REMB with something else, no problem from me. I think you should leave it in, I have no other example which actually has deployment, maybe something like this: REMB: [I-D.alvestrand-rmcat-remb] is a deployed application layer specific RTCP Payload-Specific Feedback message. If negotiated to be used a media-aware B2BUA MUST properly rewrite the additional SSRC identifier(s) in REMB packets, if it changed the related RTP SSRC of the media sender. > > >> 6. Section 3.2: >> >> In fact, while a Media Relay B2BUA may choose to >> use it on the side that supports it and not on the side that >> doesn't, there are other aspects to take into account before doing so. >> >> The above sentence indicates that it is okay to use reduced sized >> RTCP on one leg but not the other. I would strongly discourage that >> due to the issues that are raised. If one is going to "forward" a >> reduced size RTCP packet, that needs to be upgraded to a compliant >> RTCP compound packet. Which makes it bigger, and then RTCP bandwidth >> becomes an issue. I think the above sentence should be clearer that >> there are real issues here. And I think the conclusion should be to >> use it only if both legs support it. >> > > > I actually added that text after feedback from your previous review :-) > > https://www.ietf.org/mail-archive/web/straw/current/msg00336.html > > The text following the snippet you pasted tries indeed to convey exactly > the point you make, that is that if you decide to go that road there > are issues to be aware of. I'll try to make it clearer in the text that > the issues are actually more severe than one might think, and so advice > against negotiating it on one leg and not on the other. Thanks 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 ---------------------------------------------------------------------- From nobody Fri Dec 2 06:49:51 2016 Return-Path: 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 0E7371294E9; Fri, 2 Dec 2016 06:49:45 -0800 (PST) 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 rAKjCMBBaKMU; Fri, 2 Dec 2016 06:49:43 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 10C651294AA; Fri, 2 Dec 2016 06:49:42 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id r204so219139092ywb.0; Fri, 02 Dec 2016 06:49:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cVxCmVC+k+rkACx7td9tHU+jlKOXQtUXv/lv85VYZKo=; b=k31mUkSjZPnwFn6tJmohqZLKyGQ6gQzl0r7ZBww2juLnAvjERVjoHRKL13loaF31Kc phgI3kuGpKXMM95UOgjo+Az0RnJ1Os3KFpGH6dZgcthyJksWu2WAbWw5U/d1kJeX5SMT V9Ny32QeeAxoCGuFLP9PZfueqEfKfdI2b+uICMyXyG+GRHeb7zE36kAVFhRCYwQ9TNII le4Rcc1A6fcjkHoU+UlBVMoH+pq7l7GanX+vOlBJkIKLKW19QXMncvGbaoKFfUtVFu/6 13MfalOUf1bKIagwKbqyT6XJEgRv3l2qBhrj426bw4QkOyCbPfcrPYS+Q43rpDZnwkU9 HSHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cVxCmVC+k+rkACx7td9tHU+jlKOXQtUXv/lv85VYZKo=; b=NJDJevhGi0ESVo6eNtxg5xUb265u7ktZxQzbedTZjz1upuWtePrSGWs8rMLB5hYnHn RzwqSgUbQIBUX3NHprwEH3mv8DZUIPp7ibLnwCY92ToIsc3mI5o6yDlHQw0/ddonyNeu bdMOXVIUHIM4DIhJ+8On8Lc9UOdJ96fzWYY+frahrldHJg/Z8pEBtuHFLvy6tIvicb94 smrhQOrfkN7pv+pdVUhrNyco6TNYSZJ/oCQO2h8wFvFR3m7ydjQzSRg8E1b4JHouCE+X 7A9hKcEWZ5jV4pGTvfMZDrblcZwR9hkK7xXw5Aaef9+IiwMsBlIbe6WKRhCRJ8NsOLOb fI2w== X-Gm-Message-State: AKaTC027kWDUFYyXJQDqK7WbSUQYT7gt07PcqrIhe2LlxWRwX3lYi1eTBKXgRcqI/iLXkIVetU8SC8IJaNcqyg== X-Received: by 10.13.231.129 with SMTP id q123mr43373552ywe.19.1480690182208; Fri, 02 Dec 2016 06:49:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.164.40 with HTTP; Fri, 2 Dec 2016 06:49:41 -0800 (PST) In-Reply-To: <088e785d-4758-2d77-4926-8fe165aee232@ericsson.com> References: <394e842e-d0bc-309f-86ac-8279741dd8a3@ericsson.com> <20161129123116.033312d7@lminiero.lan> <088e785d-4758-2d77-4926-8fe165aee232@ericsson.com> From: Spencer Dawkins at IETF Date: Fri, 2 Dec 2016 08:49:41 -0600 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=94eb2c07639255641a0542ae0cb3 Archived-At: Cc: "tsv-art@ietf.org" , Lorenzo Miniero , straw@ietf.org, "tsv-ads@tools.ietf.org" Subject: Re: [straw] [Tsv-art] TSV-ART review of draft-ietf-straw-b2bua-rtcp-15 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 14:49:45 -0000 --94eb2c07639255641a0542ae0cb3 Content-Type: text/plain; charset=UTF-8 Lorenzo, On Fri, Dec 2, 2016 at 3:57 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Den 2016-11-29 kl. 12:31, skrev Lorenzo Miniero: > >> On Fri, 25 Nov 2016 15:49:01 +0100 >> Magnus Westerlund wrote: >> >> Hi, >>> >>> I have done this review as part of the TSVART's task to review >>> documents with potential transport impact. >>> >>> Below you will find a number of comments on issues that I found. I >>> think there are several significant issues below: 2, 3, 4, and 6. The >>> rest would be good to address. I am sorry that this review is late in >>> the process. >>> >> deleted down to > >> 5. Section 3.2: >>> >>> REMB: [I-D.alvestrand-rmcat-remb] >>> A media-aware B2BUA MUST properly rewrite the additional >>> SSRC identifier(s) in REMB packets, if it changed the related RTP >>> SSRC of the media sender. >>> >>> I assume that you have had some thought about the need to include >>> this individual proposal. I do note that it is not clear if this ever >>> will be published, especially considering the RMCAT WG's work on a >>> different feedback format. >>> >>> >> >> We had this in the beginning since most of our experimentation in this >> field was based on WebRTC implementations, and REMB played a great deal >> in that respect. Failing to adapt things would lead to recipients >> possibly flooded with data they couldn't handle, due to missing or >> broken feedback. >> >> I do know the REMB draft has been obsoleted for a while, but it's still >> used in both Chrome and Firefox, and so I thought it made sense to keep >> the related text there, as it is indeed still useful in the "real >> world". If you believe we should rather remove it, or replace >> references to REMB with something else, no problem from me. >> > > I think you should leave it in, I have no other example which actually has > deployment, maybe something like this: > > > REMB: [I-D.alvestrand-rmcat-remb] is a deployed application layer > specific RTCP Payload-Specific Feedback message. If negotiated to be used a > media-aware B2BUA MUST properly rewrite the additional SSRC > identifier(s) in REMB packets, if it changed the related RTP > SSRC of the media sender. This was mentioned in a few ballots (including mine) during IESG evaluation, so I'd like to confirm that Magnus's suggestion works for me. Thanks! Spencer --94eb2c07639255641a0542ae0cb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Lorenzo,

On Fri, Dec 2, 2016 at 3:57 AM, Magnus Westerlund <ma= gnus.westerlund@ericsson.com> wrote:
Den 2016-11-29 kl. 12:31, skrev Lorenzo Miniero:=
On Fri, 25 Nov 2016 15:49:01 +0100
Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:

Hi,

I have done this review as part of the TSVART's task to review
documents with potential transport impact.

Below you will find a number of comments on issues that I found. I
think there are several significant issues below: 2, 3, 4, and 6. The
rest would be good to address. I am sorry that this review is late in
the process.

deleted down to
=C2=A0

5. Section 3.2:

=C2=A0 =C2=A0 =C2=A0 =C2=A0REMB:=C2=A0 [I-D.alvestrand-rmcat-remb]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A media-aware B2BUA MUST properly rewrit= e the additional
SSRC identifier(s) in REMB packets, if it changed the related RTP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SSRC of the media sender.

I assume that you have had some thought about the need to include
this individual proposal. I do note that it is not clear if this ever
will be published, especially considering the RMCAT WG's work on a
different feedback format.



We had this in the beginning since most of our experimentation in this
field was based on WebRTC implementations, and REMB played a great deal
in that respect. Failing to adapt things would lead to recipients
possibly flooded with data they couldn't handle, due to missing or
broken feedback.

I do know the REMB draft has been obsoleted for a while, but it's still=
used in both Chrome and Firefox, and so I thought it made sense to keep
the related text there, as it is indeed still useful in the "real
world". If you believe we should rather remove it, or replace
references to REMB with something else, no problem from me.

 I think you should leave it in, I have no other example which actually has = deployment, maybe something like this:


REMB:=C2=A0 [I-D.alvestrand-rmcat-remb] is a deployed application layer spe= cific RTCP Payload-Specific Feedback message. If negotiated to be used a me= dia-aware B2BUA MUST properly rewrite the additional SSRC<= br> =C2=A0 =C2=A0 =C2=A0 identifier(s) in REMB packets, if it changed the relat= ed RTP
=C2=A0 =C2=A0 =C2=A0 SSRC of the media sender.

=
This was mentioned in a few ballots (including mine) during IESG= evaluation, so I'd like to confirm that Magnus's suggestion works = for me.

Thanks!

Spencer= =C2=A0
--94eb2c07639255641a0542ae0cb3-- From nobody Wed Dec 7 04:28:02 2016 Return-Path: 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 0F8EF129DED for ; Wed, 7 Dec 2016 04:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aruba.it 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 uy89TrKCREAq for ; Wed, 7 Dec 2016 04:27:54 -0800 (PST) Received: from smtpcmd0873.aruba.it (smtpcmd0873.aruba.it [62.149.156.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0876D129E77 for ; Wed, 7 Dec 2016 04:25:49 -0800 (PST) Received: from lminiero.lan ([93.44.66.66]) by smtpcmd08.ad.aruba.it with bizsmtp id H0Rn1u00f1RmSwV010RnsN; Wed, 07 Dec 2016 13:25:48 +0100 Date: Wed, 7 Dec 2016 13:25:47 +0100 From: Lorenzo Miniero To: Spencer Dawkins at IETF Message-ID: <20161207132547.57e14e87@lminiero.lan> In-Reply-To: References: <394e842e-d0bc-309f-86ac-8279741dd8a3@ericsson.com> <20161129123116.033312d7@lminiero.lan> <088e785d-4758-2d77-4926-8fe165aee232@ericsson.com> Organization: Meetecho X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1481113548; bh=hOHa89Q0pzqiK941jyqOhy2gohHSk23vGoULIeWzNWA=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=ksrlAFol4JJppsWzQ/zXmQ/sEBsDKZ8zNSn8CDFFd2GRoVt4h0CQPiHVqqJo+OIJf HEc+2BRxbT88yCdAw1KSbSxHSWs9tLDnqwpfmc4U34kz0MaJyQOQxN8JG21PbyGMdJ AjjxWMKArFNdt7eoF+zWpPjEYBC8XucpZ6VSPCWDW3pso2YIHKAbs3d9xdHmXO58S4 CcBC1x0tkQA4dRbd1K1b3f6qkStIT6KYI6G4FQs0c0xchZ07MSCrkPvMie/0SSV+aw xDonSOQGVFk76CIpIoLOM4VKczF42BEcrJvjCRnThHgiI88lGW/+pAYFjRygNNbtFb 4KXNQZsYHDQfg== Archived-At: Cc: Magnus Westerlund , straw@ietf.org, "tsv-ads@tools.ietf.org" , "tsv-art@ietf.org" Subject: Re: [straw] [Tsv-art] TSV-ART review of draft-ietf-straw-b2bua-rtcp-15 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 12:27:58 -0000 On Fri, 2 Dec 2016 08:49:41 -0600 Spencer Dawkins at IETF wrote: > Lorenzo, > > On Fri, Dec 2, 2016 at 3:57 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > > > Den 2016-11-29 kl. 12:31, skrev Lorenzo Miniero: > > > >> On Fri, 25 Nov 2016 15:49:01 +0100 > >> Magnus Westerlund wrote: > >> > >> Hi, > >>> > >>> I have done this review as part of the TSVART's task to review > >>> documents with potential transport impact. > >>> > >>> Below you will find a number of comments on issues that I found. I > >>> think there are several significant issues below: 2, 3, 4, and 6. > >>> The rest would be good to address. I am sorry that this review is > >>> late in the process. > >>> > >> > deleted down to > > > > > >> 5. Section 3.2: > >>> > >>> REMB: [I-D.alvestrand-rmcat-remb] > >>> A media-aware B2BUA MUST properly rewrite the additional > >>> SSRC identifier(s) in REMB packets, if it changed the related RTP > >>> SSRC of the media sender. > >>> > >>> I assume that you have had some thought about the need to include > >>> this individual proposal. I do note that it is not clear if this > >>> ever will be published, especially considering the RMCAT WG's > >>> work on a different feedback format. > >>> > >>> > >> > >> We had this in the beginning since most of our experimentation in > >> this field was based on WebRTC implementations, and REMB played a > >> great deal in that respect. Failing to adapt things would lead to > >> recipients possibly flooded with data they couldn't handle, due to > >> missing or broken feedback. > >> > >> I do know the REMB draft has been obsoleted for a while, but it's > >> still used in both Chrome and Firefox, and so I thought it made > >> sense to keep the related text there, as it is indeed still useful > >> in the "real world". If you believe we should rather remove it, or > >> replace references to REMB with something else, no problem from me. > >> > > > > I think you should leave it in, I have no other example which > > actually has deployment, maybe something like this: > > > > > > REMB: [I-D.alvestrand-rmcat-remb] is a deployed application layer > > specific RTCP Payload-Specific Feedback message. If negotiated to > > be used a media-aware B2BUA MUST properly rewrite the additional > > SSRC identifier(s) in REMB packets, if it changed the related RTP > > SSRC of the media sender. > > > This was mentioned in a few ballots (including mine) during IESG > evaluation, so I'd like to confirm that Magnus's suggestion works for > me. > Spencer, Magnus, sorry for this awfully late reply, busy days... thanks for the additional feedback! Just so that I'm sure we're on the same page, does this mean that we can keep the reference to the obsolete document as well, or should we just mention REMB without the reference itself? I'll work on a revised version of the document next week, as tomorrow and Friday it's holiday here in Italy. Thanks, Lorenzo > Thanks! > > Spencer From nobody Fri Dec 9 06:48:16 2016 Return-Path: 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 CDB8A129435; Fri, 9 Dec 2016 06:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 5yrnFDCh4CU7; Fri, 9 Dec 2016 06:48:10 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844451293E9; Fri, 9 Dec 2016 06:48:09 -0800 (PST) X-AuditID: c1b4fb2d-26a859800000561e-3d-584ac427fe4f Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 37.4D.22046.724CA485; Fri, 9 Dec 2016 15:48:07 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.319.2; Fri, 9 Dec 2016 15:48:07 +0100 To: Lorenzo Miniero , Spencer Dawkins at IETF References: <394e842e-d0bc-309f-86ac-8279741dd8a3@ericsson.com> <20161129123116.033312d7@lminiero.lan> <088e785d-4758-2d77-4926-8fe165aee232@ericsson.com> <20161207132547.57e14e87@lminiero.lan> From: Magnus Westerlund Message-ID: <93a45f63-ea97-77cf-ee29-a79369e55d14@ericsson.com> Date: Fri, 9 Dec 2016 15:48:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161207132547.57e14e87@lminiero.lan> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM2K7iq76Ea8Ig9nHbSy2b1nAZLFsyh5m i1vNj1ktps37yGgxa88iFgdWj52z7rJ7LFnyk8mj4+F9do8vlz+zBbBEcdmkpOZklqUW6dsl cGWcf/yMsWCLQsWDd89YGhgfSHYxcnJICJhItJ75ydjFyMUhJLCOUWLu8VYoZxmjROupNYwg VcICgRI/tu5nB7FFBFIl1sw4zQ5R1Mck8XfLPBaQBLNAgcSqtnVgRWwCFhI3fzSygdi8AvYS h+8eBrNZBFQkuub+ZgKxRQViJJYch+jlFRCUODnzCZjNKWAsseXRISCbA2imvcSDrWUQ4+Ul mrfOZgaxhQS0JRqaOlgnMArMQtI9C6FjFpKOBYzMqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJL NjECA/nglt+6OxhXv3Y8xCjAwajEw/vhqWeEEGtiWXFl7iFGCQ5mJRFevUNeEUK8KYmVValF +fFFpTmpxYcYpTlYlMR5zVbeDxcSSE8sSc1OTS1ILYLJMnFwSjUwLv7HqlspdFPpTPbTmRcm 3zV3fN6lr2+/qMfGoO2B9cabvZFMWTst3lor5Xi2+cm/PdhsXVA26+aqjr8dhk7ly84Wfrrk dPz/o1M66y17TS6+2HNS+cKidwfznuz39JBp7U3s3iBmrKqpFPjvvd73oni35X+vl6yx2BPE enp/2YL9GfxJvuXJSizFGYmGWsxFxYkAZfLUIGACAAA= Archived-At: Cc: "tsv-art@ietf.org" , straw@ietf.org, "tsv-ads@tools.ietf.org" Subject: Re: [straw] [Tsv-art] TSV-ART review of draft-ietf-straw-b2bua-rtcp-15 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 14:48:12 -0000 Den 2016-12-07 kl. 13:25, skrev Lorenzo Miniero: > On Fri, 2 Dec 2016 08:49:41 -0600 > Spencer Dawkins at IETF wrote: > >> Lorenzo, >> >> On Fri, Dec 2, 2016 at 3:57 AM, Magnus Westerlund < >> magnus.westerlund@ericsson.com> wrote: >> >>> Den 2016-11-29 kl. 12:31, skrev Lorenzo Miniero: >>> >>>> On Fri, 25 Nov 2016 15:49:01 +0100 >>>> Magnus Westerlund wrote: >>>> >>>> Hi, >>>>> >>>>> I have done this review as part of the TSVART's task to review >>>>> documents with potential transport impact. >>>>> >>>>> Below you will find a number of comments on issues that I found. I >>>>> think there are several significant issues below: 2, 3, 4, and 6. >>>>> The rest would be good to address. I am sorry that this review is >>>>> late in the process. >>>>> >>>> >> deleted down to >> >> >>> >>>> 5. Section 3.2: >>>>> >>>>> REMB: [I-D.alvestrand-rmcat-remb] >>>>> A media-aware B2BUA MUST properly rewrite the additional >>>>> SSRC identifier(s) in REMB packets, if it changed the related RTP >>>>> SSRC of the media sender. >>>>> >>>>> I assume that you have had some thought about the need to include >>>>> this individual proposal. I do note that it is not clear if this >>>>> ever will be published, especially considering the RMCAT WG's >>>>> work on a different feedback format. >>>>> >>>>> >>>> >>>> We had this in the beginning since most of our experimentation in >>>> this field was based on WebRTC implementations, and REMB played a >>>> great deal in that respect. Failing to adapt things would lead to >>>> recipients possibly flooded with data they couldn't handle, due to >>>> missing or broken feedback. >>>> >>>> I do know the REMB draft has been obsoleted for a while, but it's >>>> still used in both Chrome and Firefox, and so I thought it made >>>> sense to keep the related text there, as it is indeed still useful >>>> in the "real world". If you believe we should rather remove it, or >>>> replace references to REMB with something else, no problem from me. >>>> >>> >>> I think you should leave it in, I have no other example which >>> actually has deployment, maybe something like this: >>> >>> >>> REMB: [I-D.alvestrand-rmcat-remb] is a deployed application layer >>> specific RTCP Payload-Specific Feedback message. If negotiated to >>> be used a media-aware B2BUA MUST properly rewrite the additional >>> SSRC identifier(s) in REMB packets, if it changed the related RTP >>> SSRC of the media sender. >> >> >> This was mentioned in a few ballots (including mine) during IESG >> evaluation, so I'd like to confirm that Magnus's suggestion works for >> me. >> > > > Spencer, Magnus, > > sorry for this awfully late reply, busy days... thanks for the > additional feedback! Just so that I'm sure we're on the same page, does > this mean that we can keep the reference to the obsolete document as > well, or should we just mention REMB without the reference itself? I am fine with maintaining the reference, it makes it simpler to find. However, one could potentially argue that the combination with MUST makes this a normative reference to a draft document. It is possible that one should consider reformulating this in a more informative fashion just stating that it will be necessary to perform the translation for this message. Cheer Magnus > > I'll work on a revised version of the document next week, as tomorrow > and Friday it's holiday here in Italy. > > Thanks, > Lorenzo > > > >> Thanks! >> >> Spencer > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Dec 12 13:59:56 2016 Return-Path: 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 767E7129DA9; Mon, 12 Dec 2016 13:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no 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 3IS4D15xmqAW; Mon, 12 Dec 2016 13:59:52 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 B56FC129D84; Mon, 12 Dec 2016 13:59:52 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBCLxkbj056531 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 12 Dec 2016 15:59:47 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Magnus Westerlund" Date: Mon, 12 Dec 2016 15:59:46 -0600 Message-ID: <65AC39F1-2047-4368-9373-0FF8F04F480C@nostrum.com> In-Reply-To: <93a45f63-ea97-77cf-ee29-a79369e55d14@ericsson.com> References: <394e842e-d0bc-309f-86ac-8279741dd8a3@ericsson.com> <20161129123116.033312d7@lminiero.lan> <088e785d-4758-2d77-4926-8fe165aee232@ericsson.com> <20161207132547.57e14e87@lminiero.lan> <93a45f63-ea97-77cf-ee29-a79369e55d14@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5310) Archived-At: Cc: "tsv-art@ietf.org" , Lorenzo Miniero , Spencer Dawkins at IETF , "tsv-ads@tools.ietf.org" , straw@ietf.org Subject: Re: [straw] [Tsv-art] TSV-ART review of draft-ietf-straw-b2bua-rtcp-15 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 21:59:54 -0000 On 9 Dec 2016, at 8:48, Magnus Westerlund wrote: > Den 2016-12-07 kl. 13:25, skrev Lorenzo Miniero: >> On Fri, 2 Dec 2016 08:49:41 -0600 >> Spencer Dawkins at IETF wrote: >> >>> Lorenzo, >>> >>> On Fri, Dec 2, 2016 at 3:57 AM, Magnus Westerlund < >>> magnus.westerlund@ericsson.com> wrote: >>> >>>> Den 2016-11-29 kl. 12:31, skrev Lorenzo Miniero: >>>> >>>>> On Fri, 25 Nov 2016 15:49:01 +0100 >>>>> Magnus Westerlund wrote: >>>>> >>>>> Hi, >>>>>> >>>>>> I have done this review as part of the TSVART's task to review >>>>>> documents with potential transport impact. >>>>>> >>>>>> Below you will find a number of comments on issues that I found. >>>>>> I >>>>>> think there are several significant issues below: 2, 3, 4, and 6. >>>>>> The rest would be good to address. I am sorry that this review is >>>>>> late in the process. >>>>>> >>>>> >>> deleted down to >>> >>> >>>> >>>>> 5. Section 3.2: >>>>>> >>>>>> REMB: [I-D.alvestrand-rmcat-remb] >>>>>> A media-aware B2BUA MUST properly rewrite the >>>>>> additional >>>>>> SSRC identifier(s) in REMB packets, if it changed the related RTP >>>>>> SSRC of the media sender. >>>>>> >>>>>> I assume that you have had some thought about the need to include >>>>>> this individual proposal. I do note that it is not clear if this >>>>>> ever will be published, especially considering the RMCAT WG's >>>>>> work on a different feedback format. >>>>>> >>>>>> >>>>> >>>>> We had this in the beginning since most of our experimentation in >>>>> this field was based on WebRTC implementations, and REMB played a >>>>> great deal in that respect. Failing to adapt things would lead to >>>>> recipients possibly flooded with data they couldn't handle, due to >>>>> missing or broken feedback. >>>>> >>>>> I do know the REMB draft has been obsoleted for a while, but it's >>>>> still used in both Chrome and Firefox, and so I thought it made >>>>> sense to keep the related text there, as it is indeed still useful >>>>> in the "real world". If you believe we should rather remove it, or >>>>> replace references to REMB with something else, no problem from >>>>> me. >>>>> >>>> >>>> I think you should leave it in, I have no other example which >>>> actually has deployment, maybe something like this: >>>> >>>> >>>> REMB: [I-D.alvestrand-rmcat-remb] is a deployed application layer >>>> specific RTCP Payload-Specific Feedback message. If negotiated to >>>> be used a media-aware B2BUA MUST properly rewrite the additional >>>> SSRC identifier(s) in REMB packets, if it changed the related RTP >>>> SSRC of the media sender. >>> >>> >>> This was mentioned in a few ballots (including mine) during IESG >>> evaluation, so I'd like to confirm that Magnus's suggestion works >>> for >>> me. >>> >> >> >> Spencer, Magnus, >> >> sorry for this awfully late reply, busy days... thanks for the >> additional feedback! Just so that I'm sure we're on the same page, >> does >> this mean that we can keep the reference to the obsolete document as >> well, or should we just mention REMB without the reference itself? > > I am fine with maintaining the reference, it makes it simpler to find. > However, one could potentially argue that the combination with MUST > makes this a normative reference to a draft document. It is possible > that one should consider reformulating this in a more informative > fashion just stating that it will be necessary to perform the > translation for this message. That's an argument that I'm likely to make :-) Could this be reformulated to say something like: "[I-D.alvestrand-rmcat-remb] describes an RTCP Payload-Specific feedback message that reports the receiver's available bandwidth to the the sender. As of the time of this writing, REMB has been widely deployed, but has not been standardized. The REMB mechanism will not function correctly across a media-aware B2BUA that changes the SSRC of the media sender unless it also changes the SSRC values in the REMB packet." Thanks! Ben. From nobody Tue Dec 13 07:41:40 2016 Return-Path: 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 D94C11297F0 for ; Tue, 13 Dec 2016 07:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aruba.it 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 7eu_iN1FU-7H for ; Tue, 13 Dec 2016 07:41:36 -0800 (PST) Received: from smtpcmd0756.aruba.it (smtpcmd0756.aruba.it [62.149.156.56]) by ietfa.amsl.com (Postfix) with ESMTP id D4D9A1293FD for ; Tue, 13 Dec 2016 07:41:35 -0800 (PST) Received: from lminiero.lan ([93.44.42.61]) by smtpcmd07.ad.aruba.it with bizsmtp id KThY1u01A1KAoLl01ThZ4q; Tue, 13 Dec 2016 16:41:34 +0100 Date: Tue, 13 Dec 2016 16:41:32 +0100 From: Lorenzo Miniero To: "Ben Campbell" Message-ID: <20161213164132.19ddbea9@lminiero.lan> In-Reply-To: <65AC39F1-2047-4368-9373-0FF8F04F480C@nostrum.com> References: <394e842e-d0bc-309f-86ac-8279741dd8a3@ericsson.com> <20161129123116.033312d7@lminiero.lan> <088e785d-4758-2d77-4926-8fe165aee232@ericsson.com> <20161207132547.57e14e87@lminiero.lan> <93a45f63-ea97-77cf-ee29-a79369e55d14@ericsson.com> <65AC39F1-2047-4368-9373-0FF8F04F480C@nostrum.com> Organization: Meetecho X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1481643694; bh=XAryE6ekdPd2heWsw7JM1y2VOAbGcrfvKwbiKCL5N6g=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=B6Px/YPHaaPOsUNem+sSwAehVrj6HCt6FM8+oqQMoj6pxVD6m2Ffrk1hQ2rx7rDoP yk3zQhs9aCmDRo2EUBKKiZNZ6i126x2xJ6IKUZPnQZSxwnORvI0my7aIAy8yGIxplS xelli3NcCcAtN+iLJvEz/e8Fuf0xYXGzrZCCPcQwQZVI0RvG/4FmxeGk68BnKZWknq jEcJtnAuv7x17CUJ+KLGcvgRd/PWCmD1MlBzYn32TkRRaGeTDxt2WJtpBZk9ptFX4O urnETr96S9DWDYGDuutZGpUN2U/QCDTBm4vEF+c+Q+P/BO53OfxxwJtUy0GayfDVcG lh+DLnOAn3aSg== Archived-At: Cc: Magnus Westerlund , straw@ietf.org, Spencer Dawkins at IETF , "tsv-ads@tools.ietf.org" , "tsv-art@ietf.org" Subject: Re: [straw] [Tsv-art] TSV-ART review of draft-ietf-straw-b2bua-rtcp-15 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 15:41:40 -0000 On Mon, 12 Dec 2016 15:59:46 -0600 "Ben Campbell" wrote: > On 9 Dec 2016, at 8:48, Magnus Westerlund wrote: > > > Den 2016-12-07 kl. 13:25, skrev Lorenzo Miniero: > >> On Fri, 2 Dec 2016 08:49:41 -0600 > >> Spencer Dawkins at IETF wrote: > >> > >>> Lorenzo, > >>> > >>> On Fri, Dec 2, 2016 at 3:57 AM, Magnus Westerlund < > >>> magnus.westerlund@ericsson.com> wrote: > >>> > >>>> Den 2016-11-29 kl. 12:31, skrev Lorenzo Miniero: > >>>> > >>>>> On Fri, 25 Nov 2016 15:49:01 +0100 > >>>>> Magnus Westerlund wrote: > >>>>> > >>>>> Hi, > >>>>>> > >>>>>> I have done this review as part of the TSVART's task to review > >>>>>> documents with potential transport impact. > >>>>>> > >>>>>> Below you will find a number of comments on issues that I > >>>>>> found. I > >>>>>> think there are several significant issues below: 2, 3, 4, and > >>>>>> 6. The rest would be good to address. I am sorry that this > >>>>>> review is late in the process. > >>>>>> > >>>>> > >>> deleted down to > >>> > >>> > >>>> > >>>>> 5. Section 3.2: > >>>>>> > >>>>>> REMB: [I-D.alvestrand-rmcat-remb] > >>>>>> A media-aware B2BUA MUST properly rewrite the > >>>>>> additional > >>>>>> SSRC identifier(s) in REMB packets, if it changed the related > >>>>>> RTP SSRC of the media sender. > >>>>>> > >>>>>> I assume that you have had some thought about the need to > >>>>>> include this individual proposal. I do note that it is not > >>>>>> clear if this ever will be published, especially considering > >>>>>> the RMCAT WG's work on a different feedback format. > >>>>>> > >>>>>> > >>>>> > >>>>> We had this in the beginning since most of our experimentation > >>>>> in this field was based on WebRTC implementations, and REMB > >>>>> played a great deal in that respect. Failing to adapt things > >>>>> would lead to recipients possibly flooded with data they > >>>>> couldn't handle, due to missing or broken feedback. > >>>>> > >>>>> I do know the REMB draft has been obsoleted for a while, but > >>>>> it's still used in both Chrome and Firefox, and so I thought it > >>>>> made sense to keep the related text there, as it is indeed > >>>>> still useful in the "real world". If you believe we should > >>>>> rather remove it, or replace references to REMB with something > >>>>> else, no problem from me. > >>>>> > >>>> > >>>> I think you should leave it in, I have no other example which > >>>> actually has deployment, maybe something like this: > >>>> > >>>> > >>>> REMB: [I-D.alvestrand-rmcat-remb] is a deployed application > >>>> layer specific RTCP Payload-Specific Feedback message. If > >>>> negotiated to be used a media-aware B2BUA MUST properly rewrite > >>>> the additional SSRC identifier(s) in REMB packets, if it changed > >>>> the related RTP SSRC of the media sender. > >>> > >>> > >>> This was mentioned in a few ballots (including mine) during IESG > >>> evaluation, so I'd like to confirm that Magnus's suggestion works > >>> for > >>> me. > >>> > >> > >> > >> Spencer, Magnus, > >> > >> sorry for this awfully late reply, busy days... thanks for the > >> additional feedback! Just so that I'm sure we're on the same page, > >> does > >> this mean that we can keep the reference to the obsolete document > >> as well, or should we just mention REMB without the reference > >> itself? > > > > I am fine with maintaining the reference, it makes it simpler to > > find. However, one could potentially argue that the combination > > with MUST makes this a normative reference to a draft document. It > > is possible that one should consider reformulating this in a more > > informative fashion just stating that it will be necessary to > > perform the translation for this message. > > That's an argument that I'm likely to make :-) > > Could this be reformulated to say something like: > > "[I-D.alvestrand-rmcat-remb] describes an RTCP Payload-Specific > feedback message that reports the receiver's available bandwidth to > the the sender. As of the time of this writing, REMB has been widely > deployed, but has not been standardized. The REMB mechanism will not > function correctly across a media-aware B2BUA that changes the SSRC > of the media sender unless it also changes the SSRC values in the > REMB packet." > Hi Ben, as usual, thanks for the precious suggestions! I'll integrate the text you propose in the next version of the document, which I plan to submit in the next few days. Thanks, Lorenzo > > Thanks! > > Ben. > > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw From nobody Wed Dec 14 00:10:07 2016 Return-Path: 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 6ABAF129CAB; Wed, 14 Dec 2016 00:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 RkSLw7DlvKE7; Wed, 14 Dec 2016 00:10:03 -0800 (PST) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (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 ABECD129CAE; Wed, 14 Dec 2016 00:10:02 -0800 (PST) Received: by mail-yb0-x22e.google.com with SMTP id v78so9577215ybe.3; Wed, 14 Dec 2016 00:10:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4jlbzQgBYVrOPZMTPqkTcxyoz1xkJwhOxuQTVeGH9gU=; b=es/MrjjUQWnOwpDVUH0Nm66fokEeREkl1wCT3jTzljfddLPx/tQLtKH+wyx4XEy6HH T/WZXGwpAypkobY6uPFWFhgCPT/0b+yykwg5jUbAfA15DNS/YHT0rt/HnPrF4Y1C3AZS qeUEVRhCnrShbI2tkoQ1GfI56UbgAOdwUpyIdnyK1J2/44RsrphZEISFSXePEs2/ojcw we54Ei5XxsQR6iIcZJq17beUb7U6tKYIyAMmB0Yvtwt+hO5s8aDpSwJ61K8ToMHYg5/g rUwhzxDbKvxSX+hSwEWQZAPXqALYUjrxl9ghIcn0oc2QVVeCkfVDtHXxh1Jft6blhVVM qp2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4jlbzQgBYVrOPZMTPqkTcxyoz1xkJwhOxuQTVeGH9gU=; b=lE5WCPEVeY8vn9gWc5EH0oIT0sHVCt2VvDKi7bqKbvLTT04TsiImfAwg15G7z8bytH oG/trfIa2APbcaHZFMuCi2F7fwpJ1g3tJbCFNVj4L8vGqA//eXbLOB2HO6WPsZdg8jth uZCbO26Wf2/oLAc44rmlNkiDugL1vDGQMXPt7YzyiqAiT+JJ3enMqP3X5mUhMerJ+Sz/ Kgztr64rAsASOm4WhUXX59tjzGH4Hf0IrYnqE+nRKbVqKDjlQMjp6SjZtxb35oKiCZ/i qLZLAf5hOERV/hyhGzCjklLSa+5YXWQKPL6vlBdbNvDaFoXLSd9wxpp4GvjZ+lI864Il N1+Q== X-Gm-Message-State: AKaTC03gJ7DW22O30tLgPibxiaJ6UMUOGYkTt3QWtXLgX0trQBt0abKJlXpxyoedQ/WgwHdzSNy3oGeRjTOa6A== X-Received: by 10.13.232.199 with SMTP id r190mr95244053ywe.152.1481703001940; Wed, 14 Dec 2016 00:10:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.176.5 with HTTP; Wed, 14 Dec 2016 00:10:01 -0800 (PST) Received: by 10.37.176.5 with HTTP; Wed, 14 Dec 2016 00:10:01 -0800 (PST) In-Reply-To: <20161213164132.19ddbea9@lminiero.lan> References: <394e842e-d0bc-309f-86ac-8279741dd8a3@ericsson.com> <20161129123116.033312d7@lminiero.lan> <088e785d-4758-2d77-4926-8fe165aee232@ericsson.com> <20161207132547.57e14e87@lminiero.lan> <93a45f63-ea97-77cf-ee29-a79369e55d14@ericsson.com> <65AC39F1-2047-4368-9373-0FF8F04F480C@nostrum.com> <20161213164132.19ddbea9@lminiero.lan> From: Spencer Dawkins at IETF Date: Wed, 14 Dec 2016 02:10:01 -0600 Message-ID: To: Lorenzo Miniero Content-Type: multipart/alternative; boundary=94eb2c0870fa17efa3054399ddec Archived-At: Cc: tsv-ads@tools.ietf.org, Ben Campbell , Magnus Westerlund , straw@ietf.org, tsv-art@ietf.org Subject: Re: [straw] [Tsv-art] TSV-ART review of draft-ietf-straw-b2bua-rtcp-15 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 08:10:05 -0000 --94eb2c0870fa17efa3054399ddec Content-Type: text/plain; charset=UTF-8 Hi, Ben, On Dec 13, 2016 11:41 PM, "Lorenzo Miniero" wrote: On Mon, 12 Dec 2016 15:59:46 -0600 "Ben Campbell" wrote: > On 9 Dec 2016, at 8:48, Magnus Westerlund wrote: > > > Den 2016-12-07 kl. 13:25, skrev Lorenzo Miniero: > >> On Fri, 2 Dec 2016 08:49:41 -0600 > >> Spencer Dawkins at IETF wrote: > >> > >>> Lorenzo, > >>> > >>> On Fri, Dec 2, 2016 at 3:57 AM, Magnus Westerlund < > >>> magnus.westerlund@ericsson.com> wrote: > >>> > >>>> Den 2016-11-29 kl. 12:31, skrev Lorenzo Miniero: > >>>> > >>>>> On Fri, 25 Nov 2016 15:49:01 +0100 > >>>>> Magnus Westerlund wrote: > >>>>> > >>>>> Hi, > >>>>>> > >>>>>> I have done this review as part of the TSVART's task to review > >>>>>> documents with potential transport impact. > >>>>>> > >>>>>> Below you will find a number of comments on issues that I > >>>>>> found. I > >>>>>> think there are several significant issues below: 2, 3, 4, and > >>>>>> 6. The rest would be good to address. I am sorry that this > >>>>>> review is late in the process. > >>>>>> > >>>>> > >>> deleted down to > >>> > >>> > >>>> > >>>>> 5. Section 3.2: > >>>>>> > >>>>>> REMB: [I-D.alvestrand-rmcat-remb] > >>>>>> A media-aware B2BUA MUST properly rewrite the > >>>>>> additional > >>>>>> SSRC identifier(s) in REMB packets, if it changed the related > >>>>>> RTP SSRC of the media sender. > >>>>>> > >>>>>> I assume that you have had some thought about the need to > >>>>>> include this individual proposal. I do note that it is not > >>>>>> clear if this ever will be published, especially considering > >>>>>> the RMCAT WG's work on a different feedback format. > >>>>>> > >>>>>> > >>>>> > >>>>> We had this in the beginning since most of our experimentation > >>>>> in this field was based on WebRTC implementations, and REMB > >>>>> played a great deal in that respect. Failing to adapt things > >>>>> would lead to recipients possibly flooded with data they > >>>>> couldn't handle, due to missing or broken feedback. > >>>>> > >>>>> I do know the REMB draft has been obsoleted for a while, but > >>>>> it's still used in both Chrome and Firefox, and so I thought it > >>>>> made sense to keep the related text there, as it is indeed > >>>>> still useful in the "real world". If you believe we should > >>>>> rather remove it, or replace references to REMB with something > >>>>> else, no problem from me. > >>>>> > >>>> > >>>> I think you should leave it in, I have no other example which > >>>> actually has deployment, maybe something like this: > >>>> > >>>> > >>>> REMB: [I-D.alvestrand-rmcat-remb] is a deployed application > >>>> layer specific RTCP Payload-Specific Feedback message. If > >>>> negotiated to be used a media-aware B2BUA MUST properly rewrite > >>>> the additional SSRC identifier(s) in REMB packets, if it changed > >>>> the related RTP SSRC of the media sender. > >>> > >>> > >>> This was mentioned in a few ballots (including mine) during IESG > >>> evaluation, so I'd like to confirm that Magnus's suggestion works > >>> for > >>> me. > >>> > >> > >> > >> Spencer, Magnus, > >> > >> sorry for this awfully late reply, busy days... thanks for the > >> additional feedback! Just so that I'm sure we're on the same page, > >> does > >> this mean that we can keep the reference to the obsolete document > >> as well, or should we just mention REMB without the reference > >> itself? > > > > I am fine with maintaining the reference, it makes it simpler to > > find. However, one could potentially argue that the combination > > with MUST makes this a normative reference to a draft document. It > > is possible that one should consider reformulating this in a more > > informative fashion just stating that it will be necessary to > > perform the translation for this message. > > That's an argument that I'm likely to make :-) > > Could this be reformulated to say something like: > > "[I-D.alvestrand-rmcat-remb] describes an RTCP Payload-Specific > feedback message that reports the receiver's available bandwidth to > the the sender. As of the time of this writing, REMB has been widely > deployed, but has not been standardized. The REMB mechanism will not > function correctly across a media-aware B2BUA that changes the SSRC > of the media sender unless it also changes the SSRC values in the > REMB packet." > Hi Ben, as usual, thanks for the precious suggestions! I'll integrate the text you propose in the next version of the document, which I plan to submit in the next few days. I think your proposed text is a good way to handle this. Spencer Thanks, Lorenzo > > Thanks! > > Ben. > > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw --94eb2c0870fa17efa3054399ddec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Ben,

On Dec 13, 2016 11:41 PM, "Lorenzo Miniero" <= ;lorenzo@meetecho.com> wrote= :
On Mon, 12 Dec 2016 15:59:46 -0600
"Ben Campbell" <ben@nostrum= .com> wrote:

> On 9 Dec 2016, at 8:48, Magnus Westerlund wrote:
>
> > Den 2016-12-07 kl. 13:25, skrev Lorenzo Miniero:
> >> On Fri, 2 Dec 2016 08:49:41 -0600
> >> Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> >>
> >>> Lorenzo,
> >>>
> >>> On Fri, Dec 2, 2016 at 3:57 AM, Magnus Westerlund < > >>> magnus.= westerlund@ericsson.com> wrote:
> >>>
> >>>> Den 2016-11-29 kl. 12:31, skrev Lorenzo Miniero:
> >>>>
> >>>>> On Fri, 25 Nov 2016 15:49:01 +0100
> >>>>> Magnus Westerlund <magnus.westerlund@ericsson.com> wrote: > >>>>>
> >>>>> Hi,
> >>>>>>
> >>>>>> I have done this review as part of the TSVART= 's task to review
> >>>>>> documents with potential transport impact. > >>>>>>
> >>>>>> Below you will find a number of comments on i= ssues that I
> >>>>>> found. I
> >>>>>> think there are several significant issues be= low: 2, 3, 4, and
> >>>>>> 6. The rest would be good to address. I am so= rry that this
> >>>>>> review is late in the process.
> >>>>>>
> >>>>>
> >>> deleted down to
> >>>
> >>>
> >>>>
> >>>>> 5. Section 3.2:
> >>>>>>
> >>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 REMB:=C2=A0 [I-D.a= lvestrand-rmcat-remb]
> >>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A med= ia-aware B2BUA MUST properly rewrite the
> >>>>>> additional
> >>>>>> SSRC identifier(s) in REMB packets, if it cha= nged the related
> >>>>>> RTP SSRC of the media sender.
> >>>>>>
> >>>>>> I assume that you have had some thought about= the need to
> >>>>>> include this individual proposal. I do note t= hat it is not
> >>>>>> clear if this ever will be published, especia= lly considering
> >>>>>> the RMCAT WG's work on a different feedba= ck format.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> We had this in the beginning since most of our ex= perimentation
> >>>>> in this field was based on WebRTC implementations= , and REMB
> >>>>> played a great deal in that respect. Failing to a= dapt things
> >>>>> would lead to recipients possibly flooded with da= ta they
> >>>>> couldn't handle, due to missing or broken fee= dback.
> >>>>>
> >>>>> I do know the REMB draft has been obsoleted for a= while, but
> >>>>> it's still used in both Chrome and Firefox, a= nd so I thought it
> >>>>> made sense to keep the related text there, as it = is indeed
> >>>>> still useful in the "real world". If yo= u believe we should
> >>>>> rather remove it, or replace references to REMB w= ith something
> >>>>> else, no problem from me.
> >>>>>
> >>>>
> >>>> I think you should leave it in, I have no other examp= le which
> >>>> actually has deployment, maybe something like this: > >>>>
> >>>>
> >>>> REMB:=C2=A0 [I-D.alvestrand-rmcat-remb] is a deployed= application
> >>>> layer specific RTCP Payload-Specific Feedback message= . If
> >>>> negotiated to be used a media-aware B2BUA MUST proper= ly rewrite
> >>>> the additional SSRC identifier(s) in REMB packets, if= it changed
> >>>> the related RTP SSRC of the media sender.
> >>>
> >>>
> >>> This was mentioned in a few ballots (including mine) duri= ng IESG
> >>> evaluation, so I'd like to confirm that Magnus's = suggestion works
> >>> for
> >>> me.
> >>>
> >>
> >>
> >> Spencer, Magnus,
> >>
> >> sorry for this awfully late reply, busy days... thanks for th= e
> >> additional feedback! Just so that I'm sure we're on t= he same page,
> >> does
> >> this mean that we can keep the reference to the obsolete docu= ment
> >> as well, or should we just mention REMB without the reference=
> >> itself?
> >
> > I am fine with maintaining the reference, it makes it simpler to<= br> > > find. However, one could potentially argue that the combination > > with MUST makes this a normative reference to a draft document. I= t
> > is possible that one should consider reformulating this in a more=
> > informative fashion just stating that it will be necessary to
> > perform the translation for this message.
>
> That's an argument that I'm likely to make :-)
>
> Could this be reformulated to say something like:
>
> "[I-D.alvestrand-rmcat-remb] describes an RTCP Payload-Specific > feedback message that reports the receiver's available bandwidth t= o
> the the sender. As of the time of this writing, REMB has been widely > deployed, but has not been standardized. The REMB mechanism will not > function correctly across a media-aware B2BUA that changes the SSRC > of the media sender unless it also changes the SSRC values in the
> REMB packet."
>


Hi Ben,

as usual, thanks for the precious suggestions! I'll integrate the text<= br> you propose in the next version of the document, which I plan to submit
in the next few days.
<= br>
I think your proposed text is a good way to hand= le this.

Spencer


Thanks,
Lorenzo


>
> Thanks!
>
> Ben.
>
> _______________________________________________
> straw mailing list
> straw@ietf.org
> https://www.ietf.org/mailman/listinfo/straw=


--94eb2c0870fa17efa3054399ddec-- From nobody Fri Dec 16 09:59:13 2016 Return-Path: X-Original-To: straw@ietf.org Delivered-To: straw@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FDF129408; Fri, 16 Dec 2016 09:59:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148191114960.14724.4796370312557222753.idtracker@ietfa.amsl.com> Date: Fri, 16 Dec 2016 09:59:09 -0800 Archived-At: Cc: straw@ietf.org Subject: [straw] I-D Action: draft-ietf-straw-b2bua-rtcp-16.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 17:59:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sip Traversal Required for Applications to Work of the IETF. Title : Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs) Authors : Lorenzo Miniero Sergio Garcia Murillo Victor Pascual Filename : draft-ietf-straw-b2bua-rtcp-16.txt Pages : 19 Date : 2016-12-16 Abstract: SIP Back-to-Back User Agents (B2BUAs) are often designed to also be on the media path, rather than just intercepting signalling. This means that B2BUAs often implement an RTP/RTCP stack as well, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, though, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP messages get lost because of mismatches in the reported data. This document defines the proper behaviour B2BUAs should follow when also acting on the signalling/media plane in order to preserve the end-to-end functionality of RTCP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-straw-b2bua-rtcp-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 16 10:03:01 2016 Return-Path: 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 5D20712985F for ; Fri, 16 Dec 2016 10:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=aruba.it 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 O5jKjyqFlDQA for ; Fri, 16 Dec 2016 10:02:57 -0800 (PST) Received: from smtpcmd04135.aruba.it (smtpcmd04135.aruba.it [62.149.158.135]) by ietfa.amsl.com (Postfix) with ESMTP id E22C51279EB for ; Fri, 16 Dec 2016 10:02:56 -0800 (PST) Received: from lminiero.lan ([93.44.75.170]) by smtpcmd04.ad.aruba.it with bizsmtp id Li2u1u00r3gT5ud01i2vt0; Fri, 16 Dec 2016 19:02:55 +0100 Date: Fri, 16 Dec 2016 19:02:53 +0100 From: Lorenzo Miniero To: straw@ietf.org Message-ID: <20161216190253.3f7b0225@lminiero.lan> In-Reply-To: <148191114960.14724.4796370312557222753.idtracker@ietfa.amsl.com> References: <148191114960.14724.4796370312557222753.idtracker@ietfa.amsl.com> Organization: Meetecho X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1481911375; bh=7hgRyic1gk5t1wmPRkDp8EhE03o+D25BfoRzGlC+wP8=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=cCS9po8CxhaZWPOlyKApRKOF0aYt29SKXSTJkmnaB6yEOvO3Vdbj6XA7BcQY+s2dF VY0TuFpB90PgIG5Khg17GoGF0LTuj7Qo2ndcvp22p8q9envUTSs2UZOq6GAWDJAYoY 2cbgrSCyat8dxKyKuf/IydtOCCljjB2QR2OMXj6KVyjFU2X4rSRs2mk7VHiYLzAixl 6d3DKroCc7sSvssfkFYg2DOuVN5YnrJXE8czMz7cPdJ7gLHFslOn7jRO+baruGbfPy ejvyr4oimSj3vqCo3CfNLxu9rY2m9fp/f5yWQH5vd4bS7wsYTv5PmtDCgqXx/HCj0i Jkxbzeag3IQ4g== Archived-At: Subject: Re: [straw] I-D Action: draft-ietf-straw-b2bua-rtcp-16.txt 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 18:03:00 -0000 Dear all, this version should address all the IESG reviews I've received. Please let me know if I missed something, or if any of the points that were addressed are still an issue. Thanks! Lorenzo On Fri, 16 Dec 2016 09:59:09 -0800 internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Sip Traversal Required > for Applications to Work of the IETF. > > Title : Guidelines to support RTCP end-to-end in > Back-to-Back User Agents (B2BUAs) Authors : Lorenzo Miniero > Sergio Garcia Murillo > Victor Pascual > Filename : draft-ietf-straw-b2bua-rtcp-16.txt > Pages : 19 > Date : 2016-12-16 > > Abstract: > SIP Back-to-Back User Agents (B2BUAs) are often designed to also be > on the media path, rather than just intercepting signalling. This > means that B2BUAs often implement an RTP/RTCP stack as well, thus > leading to separate multimedia sessions that the B2BUA correlates > and bridges together. If not disciplined, though, this behaviour can > severely impact the communication experience, especially when > statistics and feedback information contained in RTCP messages get > lost because of mismatches in the reported data. > > This document defines the proper behaviour B2BUAs should follow > when also acting on the signalling/media plane in order to preserve > the end-to-end functionality of RTCP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-16 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-straw-b2bua-rtcp-16 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw From nobody Fri Dec 16 13:42:40 2016 Return-Path: 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 02FFB129435; Fri, 16 Dec 2016 13:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=unavailable autolearn_force=no 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 JxN5H3uLt3qx; Fri, 16 Dec 2016 13:42:31 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E76B0126CD8; Fri, 16 Dec 2016 13:42:30 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBGLgNIO060290 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 16 Dec 2016 15:42:23 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Alissa Cooper" , "Lorenzo Miniero" Date: Fri, 16 Dec 2016 15:42:22 -0600 Message-ID: In-Reply-To: References: <148044949206.11740.15020735400605260114.idtracker@ietfa.amsl.com> <20161201095810.3fe8873c@lminiero.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5310) Archived-At: Cc: IESG , straw@ietf.org, draft-ietf-straw-b2bua-rtcp@ietf.org, straw-chairs@ietf.org, christer.holmberg@ericsson.com 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 21:42:32 -0000 Hi, please see inline: On 1 Dec 2016, at 8:35, Alissa Cooper wrote: > Hi Lorenzo, > >> On Dec 1, 2016, at 3:58 AM, Lorenzo Miniero >> 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. > I see that version 16 at least partially addresses this. the text added an some examples to help clarify "...of the same type: "(e.g., a specific XR block type, or specific Feedback messages)" Unless I missed something, the text does not attempt the more comprehensive review that Alissa mentioned. Such a review could add quite a bit of effort, and I'm not sure the working group has the energy for that these days. Would it make sense to add some disclaimer text to the effect of "This document does not attempt to analyze the impact of dropping or aggregating each existing XR block or RTCP message"? Thanks! Ben. From nobody Sat Dec 17 01:10:51 2016 Return-Path: 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 640B212985A for ; Sat, 17 Dec 2016 01:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aruba.it 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 mQ2JeGCZMuCA for ; Sat, 17 Dec 2016 01:10:49 -0800 (PST) Received: from smtpcmd01218.aruba.it (smtpcmd0641.aruba.it [62.149.156.41]) by ietfa.amsl.com (Postfix) with ESMTP id B7016129859 for ; Sat, 17 Dec 2016 01:10:48 -0800 (PST) Received: from lminiero ([93.33.169.45]) by smtpcmd06.ad.aruba.it with bizsmtp id Lx9l1u00B0z6a7R01x9lL7; Sat, 17 Dec 2016 10:09:46 +0100 Date: Sat, 17 Dec 2016 10:09:44 +0100 From: Lorenzo Miniero To: "Ben Campbell" Message-ID: <20161217100944.5034a402@lminiero> In-Reply-To: References: <148044949206.11740.15020735400605260114.idtracker@ietfa.amsl.com> <20161201095810.3fe8873c@lminiero.lan> Organization: Meetecho X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1481965786; bh=q/fMyEAxe/VCQBG3RL+JMQVTe9OTkM1P4/gGgGgAJME=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=n7uW4DFa0aQ2HUfmRfqnv/hdbO27XdIMm4DixxqQ3k3cOIxZ7i1ApLc/G4QzduiMr OZ1+qDGw7g60eaLd3DbbBPPnhJJhBLsjrNXvbvwdX3TKEyycWxcW48DHJcQ31d5Ufk eKUIjhj2glNWOpfsDCPgsMPvMLIbcmWeN8lKDdQ1Eg/sf56hj72Yu8I2vN1Lkrpoob eJctR2rH/rjmPqkMabUkArwVGE5OkcU4JS7fQkmiLGeWg5UtBDL798EqgXKTFALJ6t mbMfgMbbkdwE4W6NxB51FH/NJ7tZmzbrtJvTkAhkNKkin7K0xEVusDyz1sFyBgj3Dp EE8bNzjkZRjbA== Archived-At: Cc: Alissa Cooper , straw-chairs@ietf.org, straw@ietf.org, IESG , christer.holmberg@ericsson.com, draft-ietf-straw-b2bua-rtcp@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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2016 09:10:50 -0000 On Fri, 16 Dec 2016 15:42:22 -0600 "Ben Campbell" wrote: > Hi, please see inline: >=20 > On 1 Dec 2016, at 8:35, Alissa Cooper wrote: >=20 > > Hi Lorenzo, > > =20 > >> On Dec 1, 2016, at 3:58 AM, Lorenzo Miniero =20 > >> wrote: > >> =20 > >>> =3D Section 3.2 =3D > >>> > >>> (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=20 > >>> 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. > >>> =20 > >> > >> > >> 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=20 > >> 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. =20 > > > > That would help somewhat (although you=E2=80=99d have to explain what y= ou=20 > > mean by =E2=80=9Cfeedback of the same type=E2=80=9D), but I think there= is a=20 > > broader question here about all of the possible information sent=20 > > within an RTCP message and the effects of selectively dropping or=20 > > aggregating RTCP messages on that information. I just picked out > > the RFC 7002 example because it=E2=80=99s 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. > > =20 >=20 > I see that version 16 at least partially addresses this. the text > added an some examples to help clarify "...of the same type: >=20 > "(e.g., a specific XR block type, or specific Feedback messages)" >=20 > Unless I missed something, the text does not attempt the more=20 > comprehensive review that Alissa mentioned. Such a review could add=20 > quite a bit of effort, and I'm not sure the working group has the > energy for that these days. Would it make sense to add some > disclaimer text to the effect of "This document does not attempt to > analyze the impact of dropping or aggregating each existing XR block > or RTCP message"? >=20 Hi Ben, you're right, I didn't delve into the details of each possible XR block, as that would have been quite complex in such a short time. The text I added was basically aimed at specifying that bad things can happen if you drop RTCP packet type X (whether X is an XR report/block or something else) and then you let the next packet of same type X through instead, without some logic/criterion/adaptation behind it. I can definitely add the statement you suggested if you believe it can remove the ambiguity from the meaning of the paragraph. Thanks! Lorenzo > Thanks! >=20 > Ben. >=20 > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw From nobody Sat Dec 17 11:33:27 2016 Return-Path: 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 7ADAB129A50 for ; Sat, 17 Dec 2016 11:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no 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 ssdLcEiTaSIs for ; Sat, 17 Dec 2016 11:33:24 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C2BB71293DC for ; Sat, 17 Dec 2016 11:33:24 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBHJXLlT086823 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 17 Dec 2016 13:33:22 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Lorenzo Miniero" Date: Sat, 17 Dec 2016 13:33:22 -0600 Message-ID: <66EDEDE6-0B9E-484D-88DF-7EC31049FDE7@nostrum.com> In-Reply-To: <20161217100944.5034a402@lminiero> References: <148044949206.11740.15020735400605260114.idtracker@ietfa.amsl.com> <20161201095810.3fe8873c@lminiero.lan> <20161217100944.5034a402@lminiero> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5310) Archived-At: Cc: Alissa Cooper , straw-chairs@ietf.org, straw@ietf.org, IESG , christer.holmberg@ericsson.com, draft-ietf-straw-b2bua-rtcp@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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2016 19:33:26 -0000 On 17 Dec 2016, at 3:09, Lorenzo Miniero wrote: > On Fri, 16 Dec 2016 15:42:22 -0600 > "Ben Campbell" wrote: > >> Hi, please see inline: >> >> On 1 Dec 2016, at 8:35, Alissa Cooper wrote: >> >>> Hi Lorenzo, >>> >>>> On Dec 1, 2016, at 3:58 AM, Lorenzo Miniero >>>> 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. >>> >> >> I see that version 16 at least partially addresses this. the text >> added an some examples to help clarify "...of the same type: >> >> "(e.g., a specific XR block type, or specific Feedback messages)" >> >> Unless I missed something, the text does not attempt the more >> comprehensive review that Alissa mentioned. Such a review could add >> quite a bit of effort, and I'm not sure the working group has the >> energy for that these days. Would it make sense to add some >> disclaimer text to the effect of "This document does not attempt to >> analyze the impact of dropping or aggregating each existing XR block >> or RTCP message"? >> > > > Hi Ben, > > you're right, I didn't delve into the details of each possible XR > block, as that would have been quite complex in such a short time. The > text I added was basically aimed at specifying that bad things can > happen if you drop RTCP packet type X (whether X is an XR report/block > or something else) and then you let the next packet of same type X > through instead, without some logic/criterion/adaptation behind it. I > can definitely add the statement you suggested if you believe it can > remove the ambiguity from the meaning of the paragraph. Let's see what Alissa thinks about how this fits her discuss comment. Alissa? Thanks! Ben. From nobody Mon Dec 19 06:39:36 2016 Return-Path: X-Original-To: straw@ietf.org Delivered-To: straw@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBB4129B00; Mon, 19 Dec 2016 06:39:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148215837560.19418.14083606543396040086.idtracker@ietfa.amsl.com> Date: Mon, 19 Dec 2016 06:39:35 -0800 Archived-At: Cc: straw@ietf.org, christer.holmberg@ericsson.com, draft-ietf-straw-b2bua-rtcp@ietf.org, straw-chairs@ietf.org Subject: [straw] Alissa Cooper's No Objection on draft-ietf-straw-b2bua-rtcp-16: (with COMMENT) X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 14:39:35 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-straw-b2bua-rtcp-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my comments. From nobody Mon Dec 19 06:46:10 2016 Return-Path: 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 3EFCF12996D; Mon, 19 Dec 2016 06:46:09 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=s2UK8oeR; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=XlRTxN2T 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 FbJOsVi7ew2E; Mon, 19 Dec 2016 06:46:08 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B773128B38; Mon, 19 Dec 2016 06:36:56 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 7AD8B206CE; Mon, 19 Dec 2016 09:36:55 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Mon, 19 Dec 2016 09:36:55 -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=A3kJeaPj/lXDSk8 KJAmzhMk3a1o=; b=s2UK8oeRdZEXAJTY/DJbLAsR/vay3qq7fTtDFO2sx5mfgfi 34EKNWwOO7Z54wU8U7jAFAkXXYf+ujAMS+MJ8CEZPjptBiUWSTWr7XKNJwoW1OjV 0MAJW+ofzGsoR/eZMA4fPvgaA8Hjsq3JxZdNEdAbQAyU9S7KI4+baoOMOE9I= 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=A3kJeaPj/lXDSk8KJAmzhMk3a1o=; b=XlRTxN2T1SSCug+hsCed n9wj5EOpg3YBNwcCbrTL4+5SZxCdGbwWc2GfwD3ZNM0gngjIOQWehrNs0YlDT67j +BBAlTgTeuEOzKIsWBQ4ApOA5vsXdmY61Mp1IZgB4qLSXmrvqn4ZZ+NeMo+ziC2H EmacfD207vHiOr09oLSoYr8= X-ME-Sender: X-Sasl-enc: lLWrio0cyyGHQtuVGSGzCfJ+JVfPhN6Ja4+KsUCKZUAt 1482158215 Received: from dhcp-10-150-9-184.cisco.com (unknown [173.38.117.75]) by mail.messagingengine.com (Postfix) with ESMTPA id 069EF7E88E; Mon, 19 Dec 2016 09:36:55 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Mon, 19 Dec 2016 09:36:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9C68B093-1F7D-4B32-979F-33A745D7D8C0@cooperw.in> References: <148044949206.11740.15020735400605260114.idtracker@ietfa.amsl.com> <20161201095810.3fe8873c@lminiero.lan> To: Ben Campbell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: straw-chairs@ietf.org, straw@ietf.org, IESG , christer.holmberg@ericsson.com, Lorenzo Miniero , draft-ietf-straw-b2bua-rtcp@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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 14:46:09 -0000 I cleared, I think the update provided is good enough. Thanks. Alissa > On Dec 16, 2016, at 4:42 PM, Ben Campbell wrote: >=20 > Hi, please see inline: >=20 > On 1 Dec 2016, at 8:35, Alissa Cooper wrote: >=20 >> Hi Lorenzo, >>=20 >>> On Dec 1, 2016, at 3:58 AM, Lorenzo Miniero = wrote: >>>=20 >>>> =3D Section 3.2 =3D >>>>=20 >>>> (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." >>>>=20 >>>> 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. >>>>=20 >>>=20 >>>=20 >>> 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. >>=20 >> That would help somewhat (although you=E2=80=99d have to explain what = you mean by =E2=80=9Cfeedback of the same type=E2=80=9D), 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=E2=80=99s 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. >>=20 >=20 > I see that version 16 at least partially addresses this. the text = added an some examples to help clarify "...of the same type: >=20 > "(e.g., a specific XR block type, or specific Feedback messages)" >=20 > Unless I missed something, the text does not attempt the more = comprehensive review that Alissa mentioned. Such a review could add = quite a bit of effort, and I'm not sure the working group has the energy = for that these days. Would it make sense to add some disclaimer text to = the effect of "This document does not attempt to analyze the impact of = dropping or aggregating each existing XR block or RTCP message"? >=20 > Thanks! >=20 > Ben. >=20 From nobody Mon Dec 19 07:55:53 2016 Return-Path: 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 6FBB5129B9D for ; Mon, 19 Dec 2016 07:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no 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 LEnu5LLCe8bg for ; Mon, 19 Dec 2016 07:55:50 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9E52B129B86 for ; Mon, 19 Dec 2016 07:55:49 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBJFtmST038424 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 19 Dec 2016 09:55:48 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Alissa Cooper" Date: Mon, 19 Dec 2016 09:55:47 -0600 Message-ID: <864710EE-D8D2-498E-8097-CB33EA55D57C@nostrum.com> In-Reply-To: <9C68B093-1F7D-4B32-979F-33A745D7D8C0@cooperw.in> References: <148044949206.11740.15020735400605260114.idtracker@ietfa.amsl.com> <20161201095810.3fe8873c@lminiero.lan> <9C68B093-1F7D-4B32-979F-33A745D7D8C0@cooperw.in> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5318) Archived-At: Cc: straw-chairs@ietf.org, straw@ietf.org, IESG , christer.holmberg@ericsson.com, Lorenzo Miniero , draft-ietf-straw-b2bua-rtcp@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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 15:55:52 -0000 Thanks! I assume that means the most recent update to the draft without additional clarification. Lorenzo and Christer: Let's stick with with the text in the latest revision. I sent a separate email to Stephen to see if he is ready to clear with this version. Thanks! Ben. On 19 Dec 2016, at 8:36, Alissa Cooper wrote: > I cleared, I think the update provided is good enough. Thanks. > > Alissa > >> On Dec 16, 2016, at 4:42 PM, Ben Campbell wrote: >> >> Hi, please see inline: >> >> On 1 Dec 2016, at 8:35, Alissa Cooper wrote: >> >>> Hi Lorenzo, >>> >>>> On Dec 1, 2016, at 3:58 AM, Lorenzo Miniero >>>> 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. >>> >> >> I see that version 16 at least partially addresses this. the text >> added an some examples to help clarify "...of the same type: >> >> "(e.g., a specific XR block type, or specific Feedback messages)" >> >> Unless I missed something, the text does not attempt the more >> comprehensive review that Alissa mentioned. Such a review could add >> quite a bit of effort, and I'm not sure the working group has the >> energy for that these days. Would it make sense to add some >> disclaimer text to the effect of "This document does not attempt to >> analyze the impact of dropping or aggregating each existing XR block >> or RTCP message"? >> >> Thanks! >> >> Ben. >> From nobody Tue Dec 20 04:23:56 2016 Return-Path: X-Original-To: straw@ietf.org Delivered-To: straw@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A98C129668; Tue, 20 Dec 2016 04:23:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148223663521.23838.15497143199357356083.idtracker@ietfa.amsl.com> Date: Tue, 20 Dec 2016 04:23:55 -0800 Archived-At: Cc: straw@ietf.org, christer.holmberg@ericsson.com, draft-ietf-straw-b2bua-rtcp@ietf.org, straw-chairs@ietf.org Subject: [straw] Stephen Farrell's No Objection on draft-ietf-straw-b2bua-rtcp-16: (with COMMENT) X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 12:23:55 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-straw-b2bua-rtcp-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for handling my discuss point. Sorry for being a bit slow in clearing that. - The security considerations section is (still!) pretty good, thanks! From nobody Tue Dec 20 04:37:47 2016 Return-Path: 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 5B5CE1295A5; Tue, 20 Dec 2016 04:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 GQlJThkNws9G; Tue, 20 Dec 2016 04:37:44 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A5A612967C; Tue, 20 Dec 2016 04:37:43 -0800 (PST) X-AuditID: c1b4fb25-3f77f980000042ea-44-58592615c9af Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id 26.2D.17130.51629585; Tue, 20 Dec 2016 13:37:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0319.002; Tue, 20 Dec 2016 13:37:40 +0100 From: Christer Holmberg To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's No Objection on draft-ietf-straw-b2bua-rtcp-16: (with COMMENT) Thread-Index: AQHSWrvvMy3QCKEqYU2AzG32H5WlEKEQ1wCA Date: Tue, 20 Dec 2016 12:37:39 +0000 Message-ID: References: <148223663521.23838.15497143199357356083.idtracker@ietfa.amsl.com> In-Reply-To: <148223663521.23838.15497143199357356083.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-ID: <29A7B7BA4FC4054E904065AC1D73531B@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsUyM2K7ja6oWmSEwaLNyhar+6ezWMz4M5HZ Yvrea+wWz1d+Y7a41fyY1YHVY233VTaPJUt+MgUwRXHZpKTmZJalFunbJXBlHLy+nKXgGEfF jvalrA2Ms9i7GDk5JARMJJ7cPsXSxcjFISSwjlFi+sz5zBDOEkaJlzN3ADkcHGwCFhLd/7RB GkQEPCUe9kE0MAusZJRYtaCdCSQhLBAv8eDpQVaIogSJLReOQNlGEqvvzwSzWQRUJW5cWQJW zytgLbF05wM2EFtIwE9i6ocWVpBdnAL+EuenJoGEGQXEJL6fWgNWziwgLnHryXwmiKMFJJbs Oc8MYYtKvHz8D6xVVEBPYs39MIiwksSPDZdYIFp1JBbs/sQGYVtLfOlbzQ5ha0ssW/iaGeIa QYmTM5+wTGAUn4Vk2ywk7bOQtM9C0j4LSfsCRtZVjKLFqcVJuelGxnqpRZnJxcX5eXp5qSWb GIGxeHDLb9UdjJffOB5iFOBgVOLh3TAvIkKINbGsuDL3EKMEB7OSCO9u5cgIId6UxMqq1KL8 +KLSnNTiQ4zSHCxK4rxmK++HCwmkJ5akZqemFqQWwWSZODilGhi7U/tqz9Qd3Vtwb2uj3ILU S24Rqb1S1Ukmv/z6J4kZH/8q7yq1Q0dtiuLRJS4yIRYRR3kfX9yRevjKJJXaXw0L7n9Q9to4 29k/eWKhEtORBx/1zwQwOXDaLVme3VFXcUDgkkd2w7N9BVcNlkW4zJmtdbo47vWnqy4r9rCu OfX9nULZjSeBi/yVWIozEg21mIuKEwGAM9GSwQIAAA== Archived-At: Cc: "straw@ietf.org" , "draft-ietf-straw-b2bua-rtcp@ietf.org" , "straw-chairs@ietf.org" Subject: Re: [straw] Stephen Farrell's No Objection on draft-ietf-straw-b2bua-rtcp-16: (with 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 12:37:45 -0000 (As co-chair) Excellent! Thank you very much to everyone! :) Regards, Christer On 20/12/16 14:23, "Stephen Farrell" wrote: >Stephen Farrell has entered the following ballot position for >draft-ietf-straw-b2bua-rtcp-16: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > > >Thanks for handling my discuss point. Sorry for being a >bit slow in clearing that. > >- The security considerations section is (still!) pretty good, >thanks! > > From nobody Thu Dec 22 08:19:37 2016 Return-Path: X-Original-To: straw@ietf.org Delivered-To: straw@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6891412954D; Thu, 22 Dec 2016 08:19:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148242357540.22553.13037298171630589060.idtracker@ietfa.amsl.com> Date: Thu, 22 Dec 2016 08:19:35 -0800 Archived-At: Cc: straw@ietf.org Subject: [straw] I-D Action: draft-ietf-straw-b2bua-rtcp-17.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 16:19:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sip Traversal Required for Applications to Work of the IETF. Title : Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs) Authors : Lorenzo Miniero Sergio Garcia Murillo Victor Pascual Filename : draft-ietf-straw-b2bua-rtcp-17.txt Pages : 19 Date : 2016-12-22 Abstract: SIP Back-to-Back User Agents (B2BUAs) are often designed to also be on the media path, rather than just intercepting signalling. This means that B2BUAs often implement an RTP/RTCP stack as well, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, though, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP messages get lost because of mismatches in the reported data. This document defines the proper behaviour B2BUAs should follow when also acting on the signalling/media plane in order to preserve the end-to-end functionality of RTCP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-straw-b2bua-rtcp-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 22 09:26:41 2016 Return-Path: X-Original-To: straw@ietf.org Delivered-To: straw@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BC7127058; Thu, 22 Dec 2016 09:26:33 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148242759352.22587.15365389254504347468.idtracker@ietfa.amsl.com> Date: Thu, 22 Dec 2016 09:26:33 -0800 Archived-At: Cc: ben@nostrum.com, straw@ietf.org, straw-chairs@ietf.org, The IESG , christer.holmberg@ericsson.com, draft-ietf-straw-b2bua-rtcp@ietf.org, rfc-editor@rfc-editor.org Subject: [straw] Protocol Action: 'Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs)' to Proposed Standard (draft-ietf-straw-b2bua-rtcp-17.txt) X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 17:26:34 -0000 The IESG has approved the following document: - 'Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs)' (draft-ietf-straw-b2bua-rtcp-17.txt) as Proposed Standard This document is the product of the Sip Traversal Required for Applications to Work Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ Technical Summary SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also be on the media path, rather than just intercepting signalling. This means that B2BUAs often implement an RTP/RTCP stack as well, whether to act as media transcoders or to just passthrough the media themselves, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, though, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP packets get lost because of mismatches in the reported data. This document defines the proper behaviour B2BUAs should follow when also acting on the signalling/media plane in order to preserve the end-to-end functionality of RTCP. Working Group Summary The WG path of this document was reasonably short and efficient. Several technical comments were made during reviews and all were resolved with consensus. There is consensus in the STRAW WG to publish this document. Document Quality The guidelines and procedures in the document is based on input and experience from the implementer community. Personnel Who is the Document Shepherd? Christer Holmberg (christer.holmberg@ericsson.com -- STRAW WG co-chair) Who is the Responsible Area Director? Ben Campbell