[rmcat] Review of rmcat-cc-codec-interactions
"Michael Ramalho (mramalho)" <mramalho@cisco.com> Tue, 16 February 2016 21:59 UTC
Return-Path: <mramalho@cisco.com>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3FA1A8A98 for <rmcat@ietfa.amsl.com>; Tue, 16 Feb 2016 13:59:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.506
X-Spam-Level:
X-Spam-Status: No, score=-14.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 VphOuqDfrsk5 for <rmcat@ietfa.amsl.com>; Tue, 16 Feb 2016 13:59:11 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8669D1A8A92 for <rmcat@ietf.org>; Tue, 16 Feb 2016 13:59:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12436; q=dns/txt; s=iport; t=1455659951; x=1456869551; h=from:to:subject:date:message-id:mime-version; bh=QpOB8VraTQGmiaqVvTKjAdAmFbIPGJP12OnNV2HXr4U=; b=aHz5jgGkfmlLtgRphztf973WT/4Y4kOa/nyr0v0V2EuKJGDQLLx7vI9R EtB+oqCvgHyAaQHQy2nximrOlDZTXTrRC0TdomBLS3UJGGN9N1c2gAMup RWU7accYWx7F2K/HtSkGvrzcrlCEA1osXDjF1vM7Mcxt7kR97Jdoih0vY I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAgA9m8NW/51dJa1egm5MUnO6LgENgWeHTjgUAQEBAQEBAX8LhEgtXgGBACYBBBuIEpxSnnQBAQEBBgEBAQEBG4YRhDWEDIRgBZZ/AYEWjDuOeo4/AR4BAUKBfYFmiA09fAEBAQ
X-IronPort-AV: E=Sophos; i="5.22,456,1449532800"; d="scan'208,217"; a="77407701"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2016 21:59:10 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u1GLxAZ4018115 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <rmcat@ietf.org>; Tue, 16 Feb 2016 21:59:10 GMT
Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 16 Feb 2016 15:59:08 -0600
Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1104.009; Tue, 16 Feb 2016 15:59:08 -0600
From: "Michael Ramalho (mramalho)" <mramalho@cisco.com>
To: "rmcat@ietf.org" <rmcat@ietf.org>
Thread-Topic: Review of rmcat-cc-codec-interactions
Thread-Index: AdFpBT+VvJLrH95+Q4CjBDwjlIgDCA==
Date: Tue, 16 Feb 2016 21:59:07 +0000
Message-ID: <cbfb25002da84c24b5eb70b298731926@XCH-ALN-017.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.213.84]
Content-Type: multipart/alternative; boundary="_000_cbfb25002da84c24b5eb70b298731926XCHALN017ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rmcat/sd1vqfPM4iHV2ObXuVw2J3K16Po>
Subject: [rmcat] Review of rmcat-cc-codec-interactions
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rmcat/>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Feb 2016 21:59:15 -0000
All, I have reviewed draft-zanaty-rmcat-cc-codec-interactions. My only comments concern Section 5.2.2 (Startup Ramp). In what follows I have added two sentences and modified a sentence in this section. ****EXISTING TEXT**** 5.2.2. Startup Ramp Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an important moment in a conversation. Rapid rate adaptation during startup is therefore important. The codec should minimize its startup media rate as much as possible without adversely impacting the user experience, and support a strategy for rapid rate ramp. The CC should allow the highest startup media rate as possible without adversely impacting network conditions, and also support rapid rate ramp until stabilizing on the available bandwidth. Startup can be viewed as a negotiation between the codec and the CC. The codec requests a startup rate and ramp, and the CC responds with the allowable parameters which may be lower/slower. The RMCAT requirements also include the possibility of bandwidth history to further accelerate or even eliminate startup ramp time. While this is highly desirable from an application viewpoint, it may be less acceptable to network operators, since it is in essence a gamble on current congestion state matching historical state, with the potential for significant congestion contribution if the gamble was wrong. Note that startup can often commence before user interaction or conversation to reduce the chance of clipped media. ****EXISTING TEXT**** ****PROPOSED TEXT**** 5.2.2. Startup Ramp Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an important moment in a conversation. Rapid rate adaptation during startup is therefore important. The codec should minimize its startup media rate as much as possible without adversely impacting the user experience, and support a strategy for rapid rate ramp. The CC should allow the highest startup media rate as possible without adversely impacting network conditions, and also support rapid rate ramp until stabilizing on the available bandwidth. Startup can be viewed as a negotiation between the codec and the CC. The specification of the ramp may take a number of forms depending on the interface to the codec; for example, a percentage bit rate increase per RTT (or other time interval), or an increased transmit window (in number of packets and/or octets allowed outstanding) are all potential forms. The codec requests a startup rate and ramp, and the CC responds with the allowable parameters which may be lower/slower. The RMCAT requirements also include the possibility of bandwidth history to further accelerate or even eliminate startup ramp time. While this acceleration or elimination in ramp time is beneficial to the session user experience when bandwidth is sufficient, it can be detrimental if significant congestion results (the user experience of this session and all other sessions traversing the point of congestion may unnecessarily degrade). Therefore, it is recommended that use of potentially stale congestion state for acceleration or elimination in ramp up be limited to topologies or deployments believed to have sufficient bandwidth margin or those in which the potential transient congestion risk is acceptable. Note that startup can often commence before user interaction or conversation to reduce the chance of clipped media. ****PROPOSED TEXT**** The modification deletes the reference to "network operators", as I think the point may be made that many network administrators (be they service providers or other "network operators") or network designers/sizers would also have the same concern. I have reviewed this change with the present authors and they generally approve of it. Other edits are welcome. Regards, Michael A. Ramalho, Ph.D.
- [rmcat] Review of rmcat-cc-codec-interactions Michael Ramalho (mramalho)
- Re: [rmcat] Review of rmcat-cc-codec-interactions Mirja Kühlewind
- Re: [rmcat] Review of rmcat-cc-codec-interactions Mo Zanaty (mzanaty)
- Re: [rmcat] Review of rmcat-cc-codec-interactions Mirja Kühlewind