From nobody Tue Apr 1 00:39:14 2014 Return-Path: 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 6C1FA1A6FF4 for ; Tue, 1 Apr 2014 00:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 nWR15Y7y7HqH for ; Tue, 1 Apr 2014 00:39:10 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id C6C1B1A0024 for ; Tue, 1 Apr 2014 00:39:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,770,1389772800"; d="asc'?scan'208";a="154639732" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 01 Apr 2014 00:39:06 -0700 Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.9.198]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Tue, 1 Apr 2014 00:39:05 -0700 From: "Eggert, Lars" To: rmcat WG Thread-Topic: please quickly check: draft-ietf-rmcat-cc-requirements-03.txt Thread-Index: AQHPTX115FQx+ScY+0aLu1MNoLk/kg== Date: Tue, 1 Apr 2014 07:39:06 +0000 Message-ID: <775850D7-C924-48BC-982C-2021B704E9DE@netapp.com> References: <20140331205232.19899.10134.idtracker@ietfa.amsl.com> In-Reply-To: <20140331205232.19899.10134.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.28] Content-Type: multipart/signed; boundary="Apple-Mail=_C75B7BAA-7E1A-4C35-B213-30B5BAE96455"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/eHolT25RogVH8cNVv5d5EU7AxVU Subject: [rmcat] please quickly check: draft-ietf-rmcat-cc-requirements-03.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 07:39:12 -0000 --Apple-Mail=_C75B7BAA-7E1A-4C35-B213-30B5BAE96455 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2014-3-31, at 22:52, internet-drafts@ietf.org wrote: > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rmcat-cc-requirements-03 if you had comments on cc-requirements during the WGLC, please quickly = check the document (the diff) on whether your comments have been = addressed. If yes, we'll request publication. Thanks, Lars --Apple-Mail=_C75B7BAA-7E1A-4C35-B213-30B5BAE96455 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBUzptGdZcnpRveo1xAQLC0wQArspDJ2E+WY7yJ9pxHeh669ymRX4k+8MX dq2dFUci7j91gfrTYtzozVb6dSy40yLkVakZ/cQHqMkkhtXsXHg/TqNAH5Q7qkVJ gNSRmZFHdSWj01Dv9I+QVNNr0GI4gGN6bFX+EtSeUnqLvW+ymQYrAxCm2eRoPNs/ 6gLUda+MqZM= =Q4Ho -----END PGP SIGNATURE----- --Apple-Mail=_C75B7BAA-7E1A-4C35-B213-30B5BAE96455-- From nobody Tue Apr 1 01:01:48 2014 Return-Path: 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 4D45F1A0389 for ; Tue, 1 Apr 2014 01:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 jIud4-vWuYMT for ; Tue, 1 Apr 2014 01:01:44 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDD11A012B for ; Tue, 1 Apr 2014 01:01:44 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WUtdb-00087B-Nn; Tue, 01 Apr 2014 10:01:39 +0200 Received: from [77.40.182.242] (helo=[10.50.5.82]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WUtdb-0000EE-8f; Tue, 01 Apr 2014 10:01:39 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Michael Welzl In-Reply-To: <775850D7-C924-48BC-982C-2021B704E9DE@netapp.com> Date: Tue, 1 Apr 2014 10:01:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <02D03CC8-C092-444B-B8F3-81BF7BAAC9FA@ifi.uio.no> References: <20140331205232.19899.10134.idtracker@ietfa.amsl.com> <775850D7-C924-48BC-982C-2021B704E9DE@netapp.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.1874) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 4 sum msgs/h 1 total rcpts 14356 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A0A6EB82EC6C9366FA74B9EF1CBB24A78E12EFCA X-UiO-SPAM-Test: remote_host: 77.40.182.242 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 541 max/h 36 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/UUf6rBvlN_29NL_1N_LCdHAk9dI Cc: rmcat WG Subject: Re: [rmcat] please quickly check: draft-ietf-rmcat-cc-requirements-03.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 08:01:47 -0000 Hi, I confirm that my comments were addressed. Only a few nits: I think that this sentence: "Flows managed by this algorithm and flows competing against at a = bottleneck" misses an "it" (against *it* at a bottleneck...). This sentence seems = broken too: "Note that relative RTTs may affect the rate new flows can ramp up to a = reasonable share." (maybe: "the rate with which..." ?) "It should be self-fair with itself," seems redundant, maybe just say = "fair with itself" or "self-fair, ..." Cheers, Michael On 1. apr. 2014, at 09:39, Eggert, Lars wrote: > Hi, >=20 > On 2014-3-31, at 22:52, internet-drafts@ietf.org wrote: >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-03 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rmcat-cc-requirements-03 >=20 > if you had comments on cc-requirements during the WGLC, please quickly = check the document (the diff) on whether your comments have been = addressed. >=20 > If yes, we'll request publication. >=20 > Thanks, > Lars From nobody Mon Apr 7 07:03:52 2014 Return-Path: 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 B43E41A0773 for ; Mon, 7 Apr 2014 07:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 PYtg1Rum-Pgi for ; Mon, 7 Apr 2014 07:03:47 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2911A0771 for ; Mon, 7 Apr 2014 07:03:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,810,1389772800"; d="asc'?scan'208";a="156138380" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx12-out.netapp.com with ESMTP; 07 Apr 2014 07:03:41 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.246]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Mon, 7 Apr 2014 07:03:41 -0700 From: "Eggert, Lars" To: Michael Welzl Thread-Topic: [rmcat] please quickly check: draft-ietf-rmcat-cc-requirements-03.txt Thread-Index: AQHPTX115FQx+ScY+0aLu1MNoLk/kpr825AAgAnTKAA= Date: Mon, 7 Apr 2014 14:03:40 +0000 Message-ID: <302A5AA3-0A77-4377-954C-A329B28D5C93@netapp.com> References: <20140331205232.19899.10134.idtracker@ietfa.amsl.com> <775850D7-C924-48BC-982C-2021B704E9DE@netapp.com> <02D03CC8-C092-444B-B8F3-81BF7BAAC9FA@ifi.uio.no> In-Reply-To: <02D03CC8-C092-444B-B8F3-81BF7BAAC9FA@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.22] Content-Type: multipart/signed; boundary="Apple-Mail=_FA2DF45B-02E0-4364-9B22-A027F932A63B"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/0k8_5rYrjq-z-SDzoe48AUd0KYc Cc: rmcat WG Subject: Re: [rmcat] please quickly check: draft-ietf-rmcat-cc-requirements-03.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 14:03:51 -0000 --Apple-Mail=_FA2DF45B-02E0-4364-9B22-A027F932A63B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks Michael. Any other feedback? Lars On 2014-4-1, at 10:01, Michael Welzl wrote: > Hi, >=20 > I confirm that my comments were addressed. Only a few nits: >=20 >=20 > I think that this sentence: >=20 > "Flows managed by this algorithm and flows competing against at a = bottleneck" >=20 > misses an "it" (against *it* at a bottleneck...). This sentence seems = broken too: >=20 > "Note that relative RTTs may affect the rate new flows can ramp up to = a reasonable share." >=20 > (maybe: "the rate with which..." ?) >=20 > "It should be self-fair with itself," seems redundant, maybe just say = "fair with itself" or "self-fair, ..." >=20 >=20 > Cheers, > Michael >=20 >=20 > On 1. apr. 2014, at 09:39, Eggert, Lars wrote: >=20 >> Hi, >>=20 >> On 2014-3-31, at 22:52, internet-drafts@ietf.org wrote: >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-03 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rmcat-cc-requirements-03= >>=20 >> if you had comments on cc-requirements during the WGLC, please = quickly check the document (the diff) on whether your comments have been = addressed. >>=20 >> If yes, we'll request publication. >>=20 >> Thanks, >> Lars >=20 --Apple-Mail=_FA2DF45B-02E0-4364-9B22-A027F932A63B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU0KwPNZcnpRveo1xAQI+AgP/cYd4DpuqcV8OBH1bXy71lrrsq3MIIksr 0uBqGh0j7AO2f64s8bDDNMjVAdjC/OZTNitNBu/6Z10kD75iptydMYTBP7o+TAQw t7b1VFFDEZ7wD1eK77Z2sjO5fAgJUr1GKg/Zzg7V+Yxmf5EGvW769aUDTBOtJSHG IVl0vPsqihU= =WTer -----END PGP SIGNATURE----- --Apple-Mail=_FA2DF45B-02E0-4364-9B22-A027F932A63B-- From nobody Fri Apr 18 21:50:05 2014 Return-Path: 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 71B4C1A022F; Fri, 18 Apr 2014 21:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 8rK7X2F7YJjQ; Fri, 18 Apr 2014 21:50:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C50B1A01BF; Fri, 18 Apr 2014 21:50:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140419045002.20578.12613.idtracker@ietfa.amsl.com> Date: Fri, 18 Apr 2014 21:50:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/s4JQ26pXfa2SXbPYyA5EB3zqo68 Cc: rmcat@ietf.org Subject: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-04.txt X-BeenThere: rmcat@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 04:50:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RTP Media Congestion Avoidance Techniques Working Group of the IETF. Title : Congestion Control Requirements For RMCAT Author : Randell Jesup Filename : draft-ietf-rmcat-cc-requirements-04.txt Pages : 9 Date : 2014-04-18 Abstract: Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like Web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g. with the introduction of WebRTC[I-D.ietf-rtcweb-overview]), it is especially important to ensure that this kind of traffic is congestion controlled. This document attempts to describe a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose, and in particular to provide a set of possible requirements for proposals coming out of the RMCAT Working Group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rmcat-cc-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rmcat-cc-requirements-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rmcat-cc-requirements-04 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 Apr 18 21:51:38 2014 Return-Path: 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 2871C1A01E0 for ; Fri, 18 Apr 2014 21:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] 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 I5nw-jzO8xd0 for ; Fri, 18 Apr 2014 21:51:35 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id D204F1A01BF for ; Fri, 18 Apr 2014 21:51:35 -0700 (PDT) Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:1559 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WbNFT-00017w-B3 for rmcat@ietf.org; Fri, 18 Apr 2014 23:51:31 -0500 Message-ID: <535200DD.3050507@jesup.org> Date: Sat, 19 Apr 2014 00:51:41 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rmcat@ietf.org References: <20140419045002.20578.12613.idtracker@ietfa.amsl.com> In-Reply-To: <20140419045002.20578.12613.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/Y6L38VR2MOvCV_UDrjW4YxNDEu8 Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-04.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 04:51:37 -0000 On 4/19/2014 12:50 AM, 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 RTP Media Congestion Avoidance Techniques Working Group of the IETF. > > Title : Congestion Control Requirements For RMCAT > Author : Randell Jesup > Filename : draft-ietf-rmcat-cc-requirements-04.txt > Pages : 9 > Date : 2014-04-18 This incorporates Mirja's feedback from 3/12 that I missed before. -- Randell Jesup -- rjesup a t mozilla d o t com From nobody Fri Apr 18 22:06:05 2014 Return-Path: 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 D58801A01BF for ; Fri, 18 Apr 2014 22:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 nDQWgYMBpOiY for ; Fri, 18 Apr 2014 22:05:59 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBA91A01E0 for ; Fri, 18 Apr 2014 22:05:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,887,1389772800"; d="asc'?scan'208";a="321096761" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx1-out.netapp.com with ESMTP; 18 Apr 2014 22:05:55 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.246]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Fri, 18 Apr 2014 22:05:54 -0700 From: "Eggert, Lars" To: Randell Jesup Thread-Topic: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-04.txt Thread-Index: AQHPW4rVKKv9j49VfEqlkUxn4pkt3ZsY1F+AgAAD+oA= Date: Sat, 19 Apr 2014 05:05:53 +0000 Message-ID: <354A78CA-8DB0-44F4-88E7-B36EB249A5F4@netapp.com> References: <20140419045002.20578.12613.idtracker@ietfa.amsl.com> <535200DD.3050507@jesup.org> In-Reply-To: <535200DD.3050507@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.29] Content-Type: multipart/signed; boundary="Apple-Mail=_CD71CCB2-AF5B-4C03-BC06-722D7A74815D"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/KOXdJaMda0G52f-N2Q3UGzCZaAA Cc: "rmcat@ietf.org" Subject: Re: [rmcat] I-D Action: draft-ietf-rmcat-cc-requirements-04.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 05:06:04 -0000 --Apple-Mail=_CD71CCB2-AF5B-4C03-BC06-722D7A74815D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thank you! We'll forward to our AD for IETF LC now. On 2014-4-18, at 21:51, Randell Jesup wrote: > On 4/19/2014 12:50 AM, 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 RTP Media Congestion Avoidance = Techniques Working Group of the IETF. >>=20 >> Title : Congestion Control Requirements For RMCAT >> Author : Randell Jesup >> Filename : draft-ietf-rmcat-cc-requirements-04.txt >> Pages : 9 >> Date : 2014-04-18 >=20 > This incorporates Mirja's feedback from 3/12 that I missed before. >=20 >=20 > --=20 > Randell Jesup -- rjesup a t mozilla d o t com >=20 --Apple-Mail=_CD71CCB2-AF5B-4C03-BC06-722D7A74815D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU1IEM9ZcnpRveo1xAQI8CwP/dFBX1ba3g7Q/lJfj0CQQ1hMy811zuq0v DQi5R2pjPCFGIvl3SqMdAT+FQW+xAfFSKddwdUmHQjEvZ/6aYda4096/nKjkvU8z hP4uQTdM1fro9NAOkgubPDgXxXGUe5Wi9r0GKi/baTgKXMYZgA/bPNQAwIBSOrUW PgPFXXlVfDA= =zMOE -----END PGP SIGNATURE----- --Apple-Mail=_CD71CCB2-AF5B-4C03-BC06-722D7A74815D-- From nobody Mon Apr 28 01:11:41 2014 Return-Path: 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 E41261A08E7 for ; Mon, 28 Apr 2014 01:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=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 LizBNJDeYdjw for ; Mon, 28 Apr 2014 01:11:31 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id B98D61A0762 for ; Mon, 28 Apr 2014 01:11:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,942,1389772800"; d="asc'?scan'208";a="119684363" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 28 Apr 2014 01:11:31 -0700 Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.246]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Mon, 28 Apr 2014 01:11:30 -0700 From: "Eggert, Lars" To: "rmcat@ietf.org" Thread-Topic: meeting preparation for Toronto Thread-Index: AQHPYrl1ub/sb+zOEki2R4SrjijmpQ== Date: Mon, 28 Apr 2014 08:11:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.105.18] Content-Type: multipart/signed; boundary="Apple-Mail=_D3AAEF97-D477-4C1A-A779-D1A116D8652C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/4mMZYq8Uv9vlIS90np_lNFRfrQw Subject: [rmcat] meeting preparation for Toronto 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 08:11:40 -0000 --Apple-Mail=_D3AAEF97-D477-4C1A-A779-D1A116D8652C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi folks, it's time to request a session for Toronto. There hasn't been much = discussion on the list, which makes me wonder if there is enough work = going on to ask for anything more than a 1h session. I had made the following proposal earlier: On 2014-3-5, at 15:35, Eggert, Lars wrote: > My proposal would be that the proponents of said candidates discuss = among themselves and with Varun to pick a small number of them for = initial evaluation. Varun & co-authors will focus their efforts on = fleshing those out in more detail, and meanwhile, the solution = proponents begin evaluation of the candidates in (at least) those = scenarios. >=20 > In the next session, we'd begin by having Varun walk the group through = the details of those scenarios, and then see evaluation results for the = various candidates. >=20 > Because I want to encourage folks to implement and evaluate each = others work* (instead of just their own proposal), I'd like to "reward" = those teams that can show results for at least one competitor - in = addition to their own candidate - with more session time in Toronto. But from the silence on the mailing list, I conclude that the proponents = of solution candidates are maybe not ready for this? I'd be happy to be = proven wrong. Lars --Apple-Mail=_D3AAEF97-D477-4C1A-A779-D1A116D8652C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBU14NMdZcnpRveo1xAQJCKQP+PhyHvQ8gZ97ufSbh+gmhcZXoBdc99uiS FrlZFGsERIJvsTaPo8RMaoP3rm6L+pElV4sIe+9VtTmBdvvHpjdsHr9XGnic3vSi dUjQDfdnM75fVA6jbhjWJMqCFoIRCN0JrbeQBAI/vpvetsf3mym7RoHAZqukEc0n 8OL1Xc0HUWs= =49oA -----END PGP SIGNATURE----- --Apple-Mail=_D3AAEF97-D477-4C1A-A779-D1A116D8652C-- From nobody Tue Apr 29 00:57:42 2014 Return-Path: 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 429B71A0746 for ; Tue, 29 Apr 2014 00:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 dpJXc4ujqxTg for ; Tue, 29 Apr 2014 00:57:38 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6633F1A0764 for ; Tue, 29 Apr 2014 00:57:37 -0700 (PDT) X-AuditID: c1b4fb30-f790e6d000001067-eb-535f5b6f738a Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 54.BD.04199.F6B5F535; Tue, 29 Apr 2014 09:57:35 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.151]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0174.001; Tue, 29 Apr 2014 09:57:35 +0200 From: Ingemar Johansson S To: "rmcat WG (rmcat@ietf.org)" Thread-Topic: draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT Flow competing with a long TCP Flow Thread-Index: Ac9jf090kpDicEcGShCy4a8kghdQ6g== Date: Tue, 29 Apr 2014 07:57:34 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5BD0F@ESESSMB205.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F5BD0FESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM+JvjW5+dHywwepbVhbvP/NbrL75gc1i xgkOi9cty5gcWDym/N7I6nF22VQmjyVLfjIFMEdx2aSk5mSWpRbp2yVwZVzY/Y21YK1DxYxZ O1kbGDdbdTFyckgImEjsWNLLDGGLSVy4t56ti5GLQ0jgKKPEikmPWCCcJYwScxcfZgepYhOw kVh56DtjFyMHh4iAgcTNXlOQMLPAT0aJHxuZQGxhgWSJGYvOMILYIgIZEh3b90DZehKHG/rY QGwWAVWJ98svsoLYvAK+Egc2bQOzGQVkJe5/v8cCMVNc4taT+UwQxwlILNlzHupQUYmXj/+x QtiKElenL2eCqM+XuHT6HiPETEGJkzOfsExgFJ6FZNQsJGWzkJRBxPUkbkydwgZha0ssW/ia GcLWlZjx7xALsvgCRvZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIGRdXDLb4MdjC+fOx5i FOBgVOLhLf4SGSzEmlhWXJl7iFGag0VJnPfbWfdgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxS DYx5f66pmYReeGekN+vppJoNZf59wTpJK6YH7T+XsPzuz1lnJ4mXSYeHeK75xeMV4fJq1p97 BlPWvD2/9Dlj03SzTMs1Dx5cS4zc0jn9r1OqR7/dh8l90tEHQoId7q7lChC/XnpSpfdJmPHH jU/iP2Xufn+4Qm+no0Fgm4hfRF/+lIeG5ixvG3YosRRnJBpqMRcVJwIANfn7Io0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/CgZ8LhJC_1XAmpMLkRl-PQb5tFY Cc: Erlendur Karlsson , Zaheduzzaman Sarker , "varun@comnet.tkk.fi" , "mramalho@cisco.com" , "xiaoqzhu@cisco.com" Subject: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT Flow competing with a long TCP Flow 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 07:57:40 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F5BD0FESESSMB205erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I am experimenting with the bottleneck test cases and found an issue with = the competing TCP flows test case. This test case specifes a Maximum end to end jitter =3D 30ms. This is imple= mented as a uniform [0-30ms] random delay in my simulator setup. The problem with this is that it creates so much reordering that TCP will t= rigger CWND reduction, and I guess this is not the intention or ? My recommendation is that we should remove the random delay completely in t= his test case (and also in 4.5) as the FTP will introduce plenty of jitter= anyhow. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Senior Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com "Those are my principles, and if you don't like them... well, I have others." Groucho Marx =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F5BD0FESESSMB205erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

I am experimenting  with the bottleneck test ca= ses and found an issue with the competing TCP flows test case.

 

This test case specifes a Maximum end to end jitter = =3D 30ms. This is implemented as a uniform [0-30ms] random delay in my simu= lator setup.

The problem with this is that it creates so much reo= rdering that TCP will trigger CWND reduction, and I guess this is not the i= ntention or ?

 

My recommendation is that we should remove the rando= m delay completely in this test case (and also in 4.5)  as the FTP wil= l introduce plenty of jitter anyhow.

 

/Ingemar

 

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

Ingemar Joh= ansson  M.Sc.

Senior Rese= archer

 =

Ericsson AB=

Wireless Ac= cess Networks

Labratorieg= r=E4nd 11

971 28, Lul= e=E5, Sweden

Phone += 46-1071 43042

SMS/MMS = 3;46-73 078 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 =

“Those are my principles, and if you don't like them...
well, I have others.”  Groucho Marx
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

 

--_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F5BD0FESESSMB205erics_-- From nobody Tue Apr 29 01:01:38 2014 Return-Path: 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 E3BF81A076F for ; Tue, 29 Apr 2014 01:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.151 X-Spam-Level: X-Spam-Status: No, score=-115.151 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.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 a8DbYlKkOHT8 for ; Tue, 29 Apr 2014 01:01:34 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D592C1A0764 for ; Tue, 29 Apr 2014 01:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13312; q=dns/txt; s=iport; t=1398758493; x=1399968093; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gtA4ILMLQJpIa9OadSyQhf/nGsCG4SroNjXuqlEerKk=; b=Ho8Z5qASEATbeJzHgtW6qfpI8ZAkp1Q71Esu2v7Hos7RqA9hhewh2koC BOUVEaZS3/dWp4n5F9x0Kt+F7dVGM7rEDNOil1Zz1IZcQhghq8S1luHkt /IKZTGNkJ4syznXttD3M3xmy5x8UHn9N2+O/vIHTSKahC1ttwllGPuIjV M=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgFAJlbX1OtJA2H/2dsb2JhbABZgkJET1fEdoEdFnSCJQEBAQMBSSQMBQkCAgEIOwsbFyUBAQQOBQ6IKwgNyHsXBI5LBwmDG4EVBIU7i0eBOIZTkmGBcoE/gis X-IronPort-AV: E=Sophos;i="4.97,949,1389744000"; d="asc'?scan'208,217";a="321135038" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP; 29 Apr 2014 08:01:32 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s3T81W8j031503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Apr 2014 08:01:32 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.100]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Tue, 29 Apr 2014 03:01:32 -0500 From: "Fred Baker (fred)" To: Ingemar Johansson S Thread-Topic: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT Flow competing with a long TCP Flow Thread-Index: Ac9jf090kpDicEcGShCy4a8kghdQ6gAK9R2A Date: Tue, 29 Apr 2014 08:01:31 +0000 Message-ID: References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5BD0F@ESESSMB205.ericsson.se> In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5BD0F@ESESSMB205.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.85.48] Content-Type: multipart/signed; boundary="Apple-Mail=_56F9B610-B96D-42B1-913F-B7A3DAF2A622"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/QsvcMQFDd_kHVZY2dMEtVvvH84U Cc: Zaheduzzaman Sarker , "rmcat WG \(rmcat@ietf.org\)" , "varun@comnet.tkk.fi" , "Michael Ramalho \(mramalho\)" , Erlendur Karlsson , "Xiaoqing Zhu \(xiaoqzhu\)" Subject: Re: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT Flow competing with a long TCP Flow 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 08:01:36 -0000 --Apple-Mail=_56F9B610-B96D-42B1-913F-B7A3DAF2A622 Content-Type: multipart/alternative; boundary="Apple-Mail=_986164B1-6647-47F8-965F-86F262989DFC" --Apple-Mail=_986164B1-6647-47F8-965F-86F262989DFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 29, 2014, at 3:57 AM, Ingemar Johansson S = wrote: > Hi > =20 > I am experimenting with the bottleneck test cases and found an issue = with the competing TCP flows test case. > =20 > This test case specifes a Maximum end to end jitter =3D 30ms. This is = implemented as a uniform [0-30ms] random delay in my simulator setup. > The problem with this is that it creates so much reordering that TCP = will trigger CWND reduction, and I guess this is not the intention or ? > =20 > My recommendation is that we should remove the random delay completely = in this test case (and also in 4.5) as the FTP will introduce plenty of = jitter anyhow. =20 That=92s the problem with simulations; you really have to think about = how to make them similar to whatever they are simulating. Network gear = rarely uses non-FIFO queues; even when we have parallel queues for = various classes of traffic, the sub-queues are FIFO. If your simulated queuing system isn=92t FIFO, its results don=92t tell = us much about what rmcat will do in real networks. > /Ingemar > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > Ingemar Johansson M.Sc. > Senior Researcher > =20 > Ericsson AB > Wireless Access Networks > Labratoriegr=E4nd 11 > 971 28, Lule=E5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > =20 > =93Those are my principles, and if you don't like them...=20 > well, I have others.=94 Groucho Marx > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D ----------------------------------- "We are learning to do a great many clever things...The next great task will be to learn not to do them." - G. K. Chesterton (1874-1936) --Apple-Mail=_986164B1-6647-47F8-965F-86F262989DFC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Apr 29, 2014, at 3:57 AM, Ingemar = Johansson S <ingemar.s.johansson@erics= son.com> wrote:

Hi
 
I am = experimenting  with the bottleneck test cases and found an issue = with the competing TCP flows test case.
 
This = test case specifes a Maximum end to end jitter =3D 30ms. This is = implemented as a uniform [0-30ms] random delay in my simulator = setup.
The problem with = this is that it creates so much reordering that TCP will trigger CWND = reduction, and I guess this is not the intention or = ?
 
My recommendation is that we should remove the = random delay completely in this test case (and also in 4.5)  as the = FTP will introduce plenty of jitter = anyhow.
 
That=92s the problem with simulations; you really have = to think about how to make them similar to whatever they are simulating. = Network gear rarely uses non-FIFO queues; even when we have parallel = queues for various classes of traffic, the sub-queues are = FIFO.

If your simulated queuing system isn=92t = FIFO, its results don=92t tell us much about what rmcat will do in real = networks.

/Ingemar
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Ingemar Johansson  = M.Sc.
Senior = Researcher
 
Ericsson = AB
Wireless = Access Networks
Labratoriegr=E4nd 11
971 28, Lule=E5, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
 
=93Those are = my principles, and if you don't like them... 
well, I have = others.=94  Groucho = Marx
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=

"We are learning to do a great many = clever things...The next great task
will be to learn not to do = them."

- G. K. Chesterton = (1874-1936)




= --Apple-Mail=_986164B1-6647-47F8-965F-86F262989DFC-- --Apple-Mail=_56F9B610-B96D-42B1-913F-B7A3DAF2A622 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTX1xbbjEdbHIsm0MRAl52AJ0Qro+2YTYdbX10n+S2IiWysEMHlwCgqIpS WVw4Y60I2NVgYK0qDCFl84k= =rkwW -----END PGP SIGNATURE----- --Apple-Mail=_56F9B610-B96D-42B1-913F-B7A3DAF2A622-- From nobody Tue Apr 29 01:08:46 2014 Return-Path: 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 5B66E1A0773 for ; Tue, 29 Apr 2014 01:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] 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 gdYcX54QvW0b for ; Tue, 29 Apr 2014 01:08:41 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAA21A076F for ; Tue, 29 Apr 2014 01:08:41 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id lx4so7753775iec.37 for ; Tue, 29 Apr 2014 01:08:40 -0700 (PDT) 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:content-type:content-transfer-encoding; bh=x6KmPf4HlioKth6HPt4trp6CmVMcRisrc9AdnKg19Lc=; b=fbIJpEsOYsy+SlEf5a7IUicwK9/7+oIoSR73OycjBpZzkOsy/XxAonquUGydLyummr NQbuOztEkP7yc1gfJMLNsZ7c0hBw5l2EigU1g/sObzKasDXorO0q40/TlS3qlg1LmDeP oAwcBNpb7eHb3irHbsybiWHsAwWHOB5eYfYfhO3ikaEWlL6kxriUcTRwZpG74VksKqhI fxNaPa72vPPlNVImK1y/EV8/FRPLYbdMHJ7hFSG6Hfhn656tf+5HsVmBh6wyPrP7uttP SF1CKa7JY6qKKsGPc/Nl18DhufWnKMLHv6/vYZkDiyEOSdwgEcVRE7r7gnAVO0IJHTii 8qHg== X-Received: by 10.50.110.106 with SMTP id hz10mr6034443igb.6.1398758920380; Tue, 29 Apr 2014 01:08:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.225.98 with HTTP; Tue, 29 Apr 2014 01:08:20 -0700 (PDT) In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5BD0F@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5BD0F@ESESSMB205.ericsson.se> From: Varun Singh Date: Tue, 29 Apr 2014 11:08:20 +0300 Message-ID: To: Ingemar Johansson S Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/IQbr50xYIuWxJDGbVPSXAMuzJsA Cc: "rmcat WG \(rmcat@ietf.org\)" , Erlendur Karlsson , "mramalho@cisco.com" , Zaheduzzaman Sarker , "xiaoqzhu@cisco.com" Subject: Re: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT Flow competing with a long TCP Flow 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 08:08:43 -0000 Hi Ingemar, Thank you for implementing the test cases and providing feedback. more inli= ne. On Tue, Apr 29, 2014 at 10:57 AM, Ingemar Johansson S wrote: > Hi > > > > I am experimenting with the bottleneck test cases and found an issue wit= h > the competing TCP flows test case. > > This test case specifes a Maximum end to end jitter =3D 30ms. This is > implemented as a uniform [0-30ms] random delay in my simulator setup. > The intention was to keep some network characteristics common across scenar= ios. However, not all > The problem with this is that it creates so much reordering that TCP will > trigger CWND reduction, and I guess this is not the intention or ? > > My recommendation is that we should remove the random delay completely in > this test case (and also in 4.5) as the FTP will introduce plenty of jit= ter > anyhow. > Yes, I am in favor of removing the additional jitter from the TCP scenarios= . > > > /Ingemar > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > Ingemar Johansson M.Sc. > > Senior Researcher > > > > Ericsson AB > > Wireless Access Networks > > Labratoriegr=C3=A4nd 11 > > 971 28, Lule=C3=A5, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > > > =E2=80=9CThose are my principles, and if you don't like them... > well, I have others.=E2=80=9D Groucho Marx > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > --=20 http://www.netlab.tkk.fi/~varun/ From nobody Tue Apr 29 02:00:17 2014 Return-Path: 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 B89D41A08B6 for ; Tue, 29 Apr 2014 02:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 goq2UsVIqiwz for ; Tue, 29 Apr 2014 02:00:13 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3CC1A072A for ; Tue, 29 Apr 2014 02:00:12 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-a4-535f6a1a28ad Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 46.2E.04714.A1A6F535; Tue, 29 Apr 2014 11:00:10 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.151]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0174.001; Tue, 29 Apr 2014 10:59:27 +0200 From: Ingemar Johansson S To: "Fred Baker (fred)" Thread-Topic: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT Flow competing with a long TCP Flow Thread-Index: Ac9jf090kpDicEcGShCy4a8kghdQ6gAK9R2AAAia8FA= Date: Tue, 29 Apr 2014 08:59:27 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5BDA6@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5BD0F@ESESSMB205.ericsson.se> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F5BDA6ESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM+Jvja5UVnywwa7Tlhbv151hs3j/md9i 9c0PbBYzTnBYvG5ZxuTA6jHl90ZWj7PLpjJ5LFnykymAOYrLJiU1J7MstUjfLoErY+8F2YIn DYwVR683MTYwrinuYuTkkBAwkZh9ay8jhC0mceHeerYuRi4OIYGjjBKrnzRDOUsYJdbuesYK UsUmYCOx8tB3sA4RAQ2JDV+OsoIUMQtsYZLov3SMuYuRg0NYIF9i8p1yiJoCibYFU6DqrSRe T3/PAmKzCKhKbD6xgh3E5hXwlZh8bgsrxLIGRomHzcfBijgFbCW2zdgKVsQoICtx//s9sDiz gLjErSfzmSDOFpBYsuc8M4QtKvHy8T9WCFtR4ur05UwQ9fkSG942skEsE5Q4OfMJywRG0VlI Rs1CUjYLSRlEXE/ixtQpbBC2tsSyha+ZIWxdiRn/DrEgiy9gZF/FKFqcWlycm25krJdalJlc XJyfp5eXWrKJERiXB7f81t3BuPq14yFGAQ5GJR7e4i+RwUKsiWXFlbmHGKU5WJTEedvuegcL CaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYCxIPxNcoV8XXezzkne6Hv+lZvtMQ692rcfT2Isc Q5fargg+bHx0Dr95fd6Tdy+dj0z5/NVSyCjIU26hIm+V3fznejyiGseb/89fsDlzryJvx7Wc z8zcN5vj7f5X+p7uj3sfds84LW3Psukr45OMT/c3XfBf261x0HJXbJXfqafnzk5jND8kpcRS nJFoqMVcVJwIAE7Kbh6sAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/aMc3edI_g98TjzHZyZCMk3c5pdg Cc: Zaheduzzaman Sarker , "rmcat WG \(rmcat@ietf.org\)" , "varun@comnet.tkk.fi" , "Michael Ramalho \(mramalho\)" , Erlendur Karlsson , "Xiaoqing Zhu \(xiaoqzhu\)" Subject: Re: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT Flow competing with a long TCP Flow 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 09:00:16 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F5BDA6ESESSMB205erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Fred You are right, it should actually be a FIFO queue involved in the random de= lay, I asked about this internally and the impression then was that we shou= ld allow for reordering to happen, did not think about the TCP problem then= though.... In any case if a random delay is still used for test case 4.4 and 4.5 then = it could be good to clarify this. /Ingemar From: Fred Baker (fred) [mailto:fred@cisco.com] Sent: den 29 april 2014 10:02 To: Ingemar Johansson S Cc: rmcat WG (rmcat@ietf.org); Erlendur Karlsson; Zaheduzzaman Sarker; varu= n@comnet.tkk.fi; Michael Ramalho (mramalho); Xiaoqing Zhu (xiaoqzhu) Subject: Re: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT F= low competing with a long TCP Flow On Apr 29, 2014, at 3:57 AM, Ingemar Johansson S > wrote: Hi I am experimenting with the bottleneck test cases and found an issue with = the competing TCP flows test case. This test case specifes a Maximum end to end jitter =3D 30ms. This is imple= mented as a uniform [0-30ms] random delay in my simulator setup. The problem with this is that it creates so much reordering that TCP will t= rigger CWND reduction, and I guess this is not the intention or ? My recommendation is that we should remove the random delay completely in t= his test case (and also in 4.5) as the FTP will introduce plenty of jitter= anyhow. That's the problem with simulations; you really have to think about how to = make them similar to whatever they are simulating. Network gear rarely uses= non-FIFO queues; even when we have parallel queues for various classes of = traffic, the sub-queues are FIFO. If your simulated queuing system isn't FIFO, its results don't tell us much= about what rmcat will do in real networks. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Senior Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com "Those are my principles, and if you don't like them... well, I have others." Groucho Marx =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D ----------------------------------- "We are learning to do a great many clever things...The next great task will be to learn not to do them." - G. K. Chesterton (1874-1936) --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F5BDA6ESESSMB205erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Fred=

You are right, it should = actually be a FIFO queue involved in the random delay, I asked about this i= nternally and the impression then was that we should allow for reordering to happen, did not think about the TCP problem then though.= ...

In any case if a random d= elay is still used for test case 4.4 and 4.5 then it could be good to clari= fy this.

 <= /p>

/Ingemar

 <= /p>

From: Fred Bak= er (fred) [mailto:fred@cisco.com]
Sent: den 29 april 2014 10:02
To: Ingemar Johansson S
Cc: rmcat WG (rmcat@ietf.org); Erlendur Karlsson; Zaheduzzaman Sarke= r; varun@comnet.tkk.fi; Michael Ramalho (mramalho); Xiaoqing Zhu (xiaoqzhu)=
Subject: Re: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 = RMCAT Flow competing with a long TCP Flow

 

 

On Apr 29, 2014, at 3:57 AM, Ingemar Johansson S <= ;ingemar.s.johansson@er= icsson.com> wrote:



Hi

 

I am experimenting  with the bottl= eneck test cases and found an issue with the competing TCP flows test case.=

 

This test case specifes a Maximum end t= o end jitter =3D 30ms. This is implemented as a uniform [0-30ms] random del= ay in my simulator setup.

The problem with this is that it create= s so much reordering that TCP will trigger CWND reduction, and I guess this= is not the intention or ?

 

My recommendation is that we should rem= ove the random delay completely in this test case (and also in 4.5)  a= s the FTP will introduce plenty of jitter anyhow.

 

That’s the problem with simulatio= ns; you really have to think about how to make them similar to whatever the= y are simulating. Network gear rarely uses non-FIFO queues; even when we have parallel queues for various classes of traffic, the sub-queue= s are FIFO.



If your simulated queuing system isn= 217;t FIFO, its results don’t tell us much about what rmcat will do i= n real networks.



/Ingemar

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Ingemar Johansson  M.Sc.

Senior Researcher

 

Ericsson AB

Wireless Access Networks

Labratoriegr=E4nd 11<= o:p>

971 28, Lule=E5, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

 

“Those are my principles, and if yo= u don't like them... 
well, I have others.” &nbs= p;Groucho Marx<= /span>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 

------------------------------= -----
"We are learning to do a great many c= lever things...The next great task
will be to learn not to do them."

- G. K. Chesterton (1874-1936)

 



 

--_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F5BDA6ESESSMB205erics_-- From nobody Wed Apr 30 04:50:33 2014 Return-Path: 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 B82561A6EF0 for ; Wed, 30 Apr 2014 04:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 jQzYugS7U03d for ; Wed, 30 Apr 2014 04:50:21 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 624A01A07C7 for ; Wed, 30 Apr 2014 04:50:20 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-8d-5360e37aac3f Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 99.54.04714.A73E0635; Wed, 30 Apr 2014 13:50:18 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.20]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Wed, 30 Apr 2014 13:50:17 +0200 From: Zaheduzzaman Sarker To: Ingemar Johansson S , "Fred Baker (fred)" Thread-Topic: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT Flow competing with a long TCP Flow Thread-Index: Ac9jf090kpDicEcGShCy4a8kghdQ6gAK9R2AAAia8FAAJv0GcA== Date: Wed, 30 Apr 2014 11:50:17 +0000 Message-ID: References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5BD0F@ESESSMB205.ericsson.se> <81564C0D7D4D2A4B9A86C8C7404A13DA31F5BDA6@ESESSMB205.ericsson.se> In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5BDA6@ESESSMB205.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_E0F7A68B07B53F4FBD12DABD61CBA90E126F127FESESSMB307erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM+JvjW7V44Rgg/7l0hbv151hs3j/md9i 9c0PbBYzTnBYvG5ZxuTA6jHl90ZWj7PLpjJ5LFnykymAOYrLJiU1J7MstUjfLoErY167VMGD uYwVn/9PYGtgPNjL2MXIySEhYCLxeXIrE4QtJnHh3no2EFtI4CijxOm7CV2MXED2YkaJa2fe AhVxcLAJ2Eg8XuwHUiMikCQxsXsBC0gNs8AvRonG6Y/YQWqEBfIlJt8ph6gpkGhbMIURwnaS 6Nj/mhXEZhFQlbg3ZQdYnFfAV+LslKMsEHuPMErM2VcDYnMK+EmsnXcWrJ4R6Lbvp9aA3cks IC5x68l8qJsFJJbsOc8MYYtKvHz8jxXCVpJYsf0SI0R9vsSs3tUsELsEJU7OfMIygVF0FpJR s5CUzUJSBhHXk7gxdQobhK0tsWzha2YIW1dixr9DLMjiCxjZVzGKFqcWF+emGxnrpRZlJhcX 5+fp5aWWbGIExuTBLb91dzCufu14iFGAg1GJh7f4S2SwEGtiWXFl7iFGaQ4WJXHetrvewUIC 6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYFdcGel/m2uy17ZJ9wlxtqYuRKYvFliod2iw+r1rv 2rcvxs2XpDfHG0/Uc4rKjlzbLbnQaMMsDlvNB6dEn337EMHBtMHBYbulT+wBAcHjp4+4zF/W vCS388idB8lT97OeNi0TLF7xjbOwoFDD3kQ96uz9M5MWRAU+EtKRe+v8metbvdU/dd5yJZbi jERDLeai4kQAABzdDKoCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/XLIhSQIoHYzG-OXL1pmKQEJLAQ8 Cc: "rmcat WG \(rmcat@ietf.org\)" , Erlendur Karlsson , "varun@comnet.tkk.fi" , "Michael Ramalho \(mramalho\)" , "Xiaoqing Zhu \(xiaoqzhu\)" Subject: Re: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT Flow competing with a long TCP Flow 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 11:50:25 -0000 --_000_E0F7A68B07B53F4FBD12DABD61CBA90E126F127FESESSMB307erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Fred and Ingemar, Are you saying re-ordering is not a phenomena that we can observe in the cu= rrent Internet? And we should not have test cases to handle re-ordering of = packets in RMCAT? BR Zahed From: Ingemar Johansson S Sent: den 29 april 2014 10:59 To: Fred Baker (fred) Cc: rmcat WG (rmcat@ietf.org); Erlendur Karlsson; Zaheduzzaman Sarker; varu= n@comnet.tkk.fi; Michael Ramalho (mramalho); Xiaoqing Zhu (xiaoqzhu) Subject: RE: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT F= low competing with a long TCP Flow Hi Fred You are right, it should actually be a FIFO queue involved in the random de= lay, I asked about this internally and the impression then was that we shou= ld allow for reordering to happen, did not think about the TCP problem then= though.... In any case if a random delay is still used for test case 4.4 and 4.5 then = it could be good to clarify this. /Ingemar From: Fred Baker (fred) [mailto:fred@cisco.com] Sent: den 29 april 2014 10:02 To: Ingemar Johansson S Cc: rmcat WG (rmcat@ietf.org); Erlendur Karlsson; Za= heduzzaman Sarker; varun@comnet.tkk.fi; Michael= Ramalho (mramalho); Xiaoqing Zhu (xiaoqzhu) Subject: Re: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT F= low competing with a long TCP Flow On Apr 29, 2014, at 3:57 AM, Ingemar Johansson S > wrote: Hi I am experimenting with the bottleneck test cases and found an issue with = the competing TCP flows test case. This test case specifes a Maximum end to end jitter =3D 30ms. This is imple= mented as a uniform [0-30ms] random delay in my simulator setup. The problem with this is that it creates so much reordering that TCP will t= rigger CWND reduction, and I guess this is not the intention or ? My recommendation is that we should remove the random delay completely in t= his test case (and also in 4.5) as the FTP will introduce plenty of jitter= anyhow. That's the problem with simulations; you really have to think about how to = make them similar to whatever they are simulating. Network gear rarely uses= non-FIFO queues; even when we have parallel queues for various classes of = traffic, the sub-queues are FIFO. If your simulated queuing system isn't FIFO, its results don't tell us much= about what rmcat will do in real networks. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Senior Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com "Those are my principles, and if you don't like them... well, I have others." Groucho Marx =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D ----------------------------------- "We are learning to do a great many clever things...The next great task will be to learn not to do them." - G. K. Chesterton (1874-1936) --_000_E0F7A68B07B53F4FBD12DABD61CBA90E126F127FESESSMB307erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Fred and Ingemar,=

 <= /p>

Are you saying re-orderin= g is not a phenomena that we can observe in the current Internet? And we sh= ould not have test cases to handle re-ordering of packets in RMCAT?

BR

 <= /p>

Zahed

 <= /p>

From: Ingemar = Johansson S
Sent: den 29 april 2014 10:59
To: Fred Baker (fred)
Cc: rmcat WG (rmcat@ietf.org); Erlendur Karlsson; Zaheduzzaman Sarke= r; varun@comnet.tkk.fi; Michael Ramalho (mramalho); Xiaoqing Zhu (xiaoqzhu)=
Subject: RE: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 = RMCAT Flow competing with a long TCP Flow

 

Hi Fred=

You are right, it should = actually be a FIFO queue involved in the random delay, I asked about this i= nternally and the impression then was that we should allow for reordering to happen, did not think about the TCP problem then though.= ...

In any case if a random d= elay is still used for test case 4.4 and 4.5 then it could be good to clari= fy this.

 <= /p>

/Ingemar

 <= /p>

From: Fred Bak= er (fred) [mailto:fred@cisco.com]
Sent: den 29 april 2014 10:02
To: Ingemar Johansson S
Cc: rmcat WG (rmcat@ietf.org);= Erlendur Karlsson; Zaheduzzaman Sarker; varun@comnet.tkk.fi; Michael Ram= alho (mramalho); Xiaoqing Zhu (xiaoqzhu)
Subject: Re: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 = RMCAT Flow competing with a long TCP Flow

 

 

On Apr 29, 2014, at 3:57 AM, Ingemar Johansson S <= ;ingemar.s.johansson@er= icsson.com> wrote:

 

Hi

 

I am experimenting  with the bottl= eneck test cases and found an issue with the competing TCP flows test case.=

 

This test case specifes a Maximum end t= o end jitter =3D 30ms. This is implemented as a uniform [0-30ms] random del= ay in my simulator setup.

The problem with this is that it create= s so much reordering that TCP will trigger CWND reduction, and I guess this= is not the intention or ?

 

My recommendation is that we should rem= ove the random delay completely in this test case (and also in 4.5)  a= s the FTP will introduce plenty of jitter anyhow.

 

That’s the problem with simulatio= ns; you really have to think about how to make them similar to whatever the= y are simulating. Network gear rarely uses non-FIFO queues; even when we have parallel queues for various classes of traffic, the sub-queue= s are FIFO.

&nb= sp;

If your simulated queuing system isn= 217;t FIFO, its results don’t tell us much about what rmcat will do i= n real networks.

&nb= sp;

/Ingemar

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Ingemar Johansson  M.Sc.

Senior Researcher

 

Ericsson AB

Wireless Access Networks

Labratoriegr=E4nd 11<= o:p>

971 28, Lule=E5, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

 

“Those are my principles, and if yo= u don't like them... 
well, I have others.” &nbs= p;Groucho Marx<= /span>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 

------------------------------= -----
"We are learning to do a great many c= lever things...The next great task
will be to learn not to do them."

- G. K. Chesterton (1874-1936)

 

 

 

--_000_E0F7A68B07B53F4FBD12DABD61CBA90E126F127FESESSMB307erics_-- From nobody Wed Apr 30 05:46:59 2014 Return-Path: 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 BA3591A6F6F for ; Wed, 30 Apr 2014 05:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 kpeFkL26DKJU for ; Wed, 30 Apr 2014 05:46:37 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id B69B01A6F68 for ; Wed, 30 Apr 2014 05:46:36 -0700 (PDT) X-AuditID: c1b4fb3a-f79106d0000013ca-7c-5360f0aa5098 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 79.4D.05066.AA0F0635; Wed, 30 Apr 2014 14:46:34 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.151]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Wed, 30 Apr 2014 14:46:33 +0200 From: Ingemar Johansson S To: Zaheduzzaman Sarker , "Fred Baker (fred)" Thread-Topic: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT Flow competing with a long TCP Flow Thread-Index: Ac9jf090kpDicEcGShCy4a8kghdQ6gAK9R2AAAia8FAAJv0GcAAB/uSg Date: Wed, 30 Apr 2014 12:46:33 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5C849@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5BD0F@ESESSMB205.ericsson.se> <81564C0D7D4D2A4B9A86C8C7404A13DA31F5BDA6@ESESSMB205.ericsson.se> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F5C849ESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM+Jvje6qDwnBBot/ylm8X3eGzeL9Z36L 1Tc/sFnMOMFh8bplGZMDq8eU3xtZPc4um8rksWTJT6YA5igum5TUnMyy1CJ9uwSujN0LZjAV tG1jrPg2/zBjA+P/RYxdjJwcEgImEpM/TGaHsMUkLtxbz9bFyMUhJHCUUeLFz9NMEM4SRomp V2+zgVSxCdhIrDz0HaxbRCBJ4u/tdywgRcwCvxglGqc/AhrFwSEskC8x+U45RE2BRNuCKVD1 bhJd51czg9gsAqoSy59MBpvJK+ArMb1pHtTmDiaJXcvvMILM4RTwk9ixQBakhlFAVuL+93ss IDazgLjErSfzmSCuFpBYsuc8M4QtKvHy8T9WCFtJ4seGS1D1+RK3n71kgtglKHFy5hOWCYyi s5CMmoWkbBaSMoi4nsSNqVPYIGxtiWULXzND2LoSM/4dYkEWX8DIvopRtDi1uDg33chIL7Uo M7m4OD9PLy+1ZBMjMDIPbvlttYPx4HPHQ4wCHIxKPLzFXyKDhVgTy4orcw8xSnOwKInzTlrk HiwkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB0XK15+4fcQIfvknUB78+P92bMdL/h4HAm82f Xqnes9X4+aB82naZBN66jXq+d++a9Jtk1vXZrOrfVSFmdtzFP+ixg57tlnt/7fmC67YYRwhM v6JbJDY3kWnWjaijLT4v670XrVrz/krmibWsczyjPjy9qlOpr+43Sf1gXNmsplV7Tv/x3THp pxJLcUaioRZzUXEiAAhZQYKtAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/AL5qCbul_ZuQ8a-kP4FbA7fpuec Cc: "rmcat WG \(rmcat@ietf.org\)" , Erlendur Karlsson , "varun@comnet.tkk.fi" , "Michael Ramalho \(mramalho\)" , "Xiaoqing Zhu \(xiaoqzhu\)" Subject: Re: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT Flow competing with a long TCP Flow 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 12:46:54 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F5C849ESESSMB205erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Packet reordering can happen in 3G network due to load balancing, I've see = examples of this in wireshark logs. Most often it only generate one duplica= te ACK in TCP which is normally nothing that triggers fast retransmit and C= WND reduction. The kind of reordering in testcases 4.4 and 4.5 which causes the kind of de= graded FTP throughput that I see in the simulations should be very uncommon= though. /Ingemar From: Zaheduzzaman Sarker Sent: den 30 april 2014 13:50 To: Ingemar Johansson S; Fred Baker (fred) Cc: rmcat WG (rmcat@ietf.org); Erlendur Karlsson; varun@comnet.tkk.fi; Mich= ael Ramalho (mramalho); Xiaoqing Zhu (xiaoqzhu) Subject: RE: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT F= low competing with a long TCP Flow Hi Fred and Ingemar, Are you saying re-ordering is not a phenomena that we can observe in the cu= rrent Internet? And we should not have test cases to handle re-ordering of = packets in RMCAT? BR Zahed From: Ingemar Johansson S Sent: den 29 april 2014 10:59 To: Fred Baker (fred) Cc: rmcat WG (rmcat@ietf.org); Erlendur Karlsson; Za= heduzzaman Sarker; varun@comnet.tkk.fi; Michael= Ramalho (mramalho); Xiaoqing Zhu (xiaoqzhu) Subject: RE: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT F= low competing with a long TCP Flow Hi Fred You are right, it should actually be a FIFO queue involved in the random de= lay, I asked about this internally and the impression then was that we shou= ld allow for reordering to happen, did not think about the TCP problem then= though.... In any case if a random delay is still used for test case 4.4 and 4.5 then = it could be good to clarify this. /Ingemar From: Fred Baker (fred) [mailto:fred@cisco.com] Sent: den 29 april 2014 10:02 To: Ingemar Johansson S Cc: rmcat WG (rmcat@ietf.org); Erlendur Karlsson; Za= heduzzaman Sarker; varun@comnet.tkk.fi; Michael= Ramalho (mramalho); Xiaoqing Zhu (xiaoqzhu) Subject: Re: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT F= low competing with a long TCP Flow On Apr 29, 2014, at 3:57 AM, Ingemar Johansson S > wrote: Hi I am experimenting with the bottleneck test cases and found an issue with = the competing TCP flows test case. This test case specifes a Maximum end to end jitter =3D 30ms. This is imple= mented as a uniform [0-30ms] random delay in my simulator setup. The problem with this is that it creates so much reordering that TCP will t= rigger CWND reduction, and I guess this is not the intention or ? My recommendation is that we should remove the random delay completely in t= his test case (and also in 4.5) as the FTP will introduce plenty of jitter= anyhow. That's the problem with simulations; you really have to think about how to = make them similar to whatever they are simulating. Network gear rarely uses= non-FIFO queues; even when we have parallel queues for various classes of = traffic, the sub-queues are FIFO. If your simulated queuing system isn't FIFO, its results don't tell us much= about what rmcat will do in real networks. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Senior Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com "Those are my principles, and if you don't like them... well, I have others." Groucho Marx =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D ----------------------------------- "We are learning to do a great many clever things...The next great task will be to learn not to do them." - G. K. Chesterton (1874-1936) --_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F5C849ESESSMB205erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 <= /p>

Packet reordering can hap= pen in 3G network due to load balancing, I’ve see examples of this in= wireshark logs. Most often it only generate one duplicate ACK in TCP which is normally nothing that triggers fast retransmit and CWND re= duction.

The kind of reordering in= testcases 4.4 and 4.5 which causes the kind of degraded FTP throughput tha= t I see in the simulations should be very uncommon though.

 <= /p>

/Ingemar

 <= /p>

From: Zaheduzz= aman Sarker
Sent: den 30 april 2014 13:50
To: Ingemar Johansson S; Fred Baker (fred)
Cc: rmcat WG (rmcat@ietf.org); Erlendur Karlsson; varun@comnet.tkk.f= i; Michael Ramalho (mramalho); Xiaoqing Zhu (xiaoqzhu)
Subject: RE: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 = RMCAT Flow competing with a long TCP Flow

 

Hi Fred and Ingemar,=

 <= /p>

Are you saying re-orderin= g is not a phenomena that we can observe in the current Internet? And we sh= ould not have test cases to handle re-ordering of packets in RMCAT?

BR

 <= /p>

Zahed

 <= /p>

From: Ingemar = Johansson S
Sent: den 29 april 2014 10:59
To: Fred Baker (fred)
Cc: rmcat WG (rmcat@ietf.org);= Erlendur Karlsson; Zaheduzzaman Sarker; varun@comnet.tkk.fi; Michael Ram= alho (mramalho); Xiaoqing Zhu (xiaoqzhu)
Subject: RE: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 = RMCAT Flow competing with a long TCP Flow

 

Hi Fred=

You are right, it should = actually be a FIFO queue involved in the random delay, I asked about this i= nternally and the impression then was that we should allow for reordering to happen, did not think about the TCP problem then though.= ...

In any case if a random d= elay is still used for test case 4.4 and 4.5 then it could be good to clari= fy this.

 <= /p>

/Ingemar

 <= /p>

From: Fred Bak= er (fred) [mailto:fred@cisco.com]
Sent: den 29 april 2014 10:02
To: Ingemar Johansson S
Cc: rmcat WG (rmcat@ietf.org);= Erlendur Karlsson; Zaheduzzaman Sarker; varun@comnet.tkk.fi; Michael Ram= alho (mramalho); Xiaoqing Zhu (xiaoqzhu)
Subject: Re: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 = RMCAT Flow competing with a long TCP Flow

 

 

On Apr 29, 2014, at 3:57 AM, Ingemar Johansson S <= ;ingemar.s.johansson@er= icsson.com> wrote:

 

Hi

 

I am experimenting  with the bottl= eneck test cases and found an issue with the competing TCP flows test case.=

 

This test case specifes a Maximum end t= o end jitter =3D 30ms. This is implemented as a uniform [0-30ms] random del= ay in my simulator setup.

The problem with this is that it create= s so much reordering that TCP will trigger CWND reduction, and I guess this= is not the intention or ?

 

My recommendation is that we should rem= ove the random delay completely in this test case (and also in 4.5)  a= s the FTP will introduce plenty of jitter anyhow.

 

That’s the problem with simulatio= ns; you really have to think about how to make them similar to whatever the= y are simulating. Network gear rarely uses non-FIFO queues; even when we have parallel queues for various classes of traffic, the sub-queue= s are FIFO.

&nb= sp;

If your simulated queuing system isn= 217;t FIFO, its results don’t tell us much about what rmcat will do i= n real networks.

&nb= sp;

/Ingemar

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Ingemar Johansson  M.Sc.

Senior Researcher

 

Ericsson AB

Wireless Access Networks

Labratoriegr=E4nd 11<= o:p>

971 28, Lule=E5, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

 

“Those are my principles, and if yo= u don't like them... 
well, I have others.” &nbs= p;Groucho Marx<= /span>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

 

------------------------------= -----
"We are learning to do a great many c= lever things...The next great task
will be to learn not to do them."

- G. K. Chesterton (1874-1936)

 

 

 

--_000_81564C0D7D4D2A4B9A86C8C7404A13DA31F5C849ESESSMB205erics_-- From nobody Wed Apr 30 10:02:39 2014 Return-Path: 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 738201A091E for ; Wed, 30 Apr 2014 10:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.152 X-Spam-Level: X-Spam-Status: No, score=-110.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 uEqWFBBHDzyQ for ; Wed, 30 Apr 2014 10:02:36 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id D6E0D1A0910 for ; Wed, 30 Apr 2014 10:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3848; q=dns/txt; s=iport; t=1398877354; x=1400086954; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gViHIuWkwUwtbupuvdCphVLbzY3GqNY9FPKF/t2sd2c=; b=l5iIHZcIbPNPwjbrFlkN8LBivp3uUbB7cH0GLVFktQ62H5rr7Px6xlBQ TRbO4Jo4pPJSj5L7QOI0hyZJNzICOrj3+FYZaceXzKQowJwR0T22HI8p9 /ibskxdkuILGJYnWc7HJN7MZu0xpui6Mcs1yIew/l8wCTpLwlY4yWjVDY A=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAKIrYVOtJA2E/2dsb2JhbABZgwaBJsRGgSAWdIIlAQEBAwF5BQsCAQg7CzIlAQEEDgUOiCsIyRUXjlEHgySBFQSRGYE4hlaSa4FygT+CKw X-IronPort-AV: E=Sophos;i="4.97,959,1389744000"; d="asc'?scan'208";a="40028107" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP; 30 Apr 2014 17:02:32 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s3UH2Wwc000990 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Apr 2014 17:02:32 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.100]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 12:02:31 -0500 From: "Fred Baker (fred)" To: Zaheduzzaman Sarker Thread-Topic: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT Flow competing with a long TCP Flow Thread-Index: Ac9jf090kpDicEcGShCy4a8kghdQ6gAK9R2AAAia8FAAJv0GcAAVl0KA Date: Wed, 30 Apr 2014 17:02:30 +0000 Message-ID: <7BFDDE81-4472-4F13-94D6-B62B6B802C33@cisco.com> References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5BD0F@ESESSMB205.ericsson.se> <81564C0D7D4D2A4B9A86C8C7404A13DA31F5BDA6@ESESSMB205.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.118] Content-Type: multipart/signed; boundary="Apple-Mail=_B3464433-C0D2-4CDC-8500-4FFCF9974F88"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/UZPvFKeLjqa73hLpTnO5E5IzSfM Cc: Ingemar Johansson S , "rmcat WG \(rmcat@ietf.org\)" , "varun@comnet.tkk.fi" , "Michael Ramalho \(mramalho\)" , Erlendur Karlsson , "Xiaoqing Zhu \(xiaoqzhu\)" Subject: Re: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT Flow competing with a long TCP Flow 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 17:02:37 -0000 --Apple-Mail=_B3464433-C0D2-4CDC-8500-4FFCF9974F88 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 30, 2014, at 4:50 AM, Zaheduzzaman Sarker = wrote: > Are you saying re-ordering is not a phenomena that we can observe in = the current Internet? And we should not have test cases to handle = re-ordering of packets in RMCAT? Packet reordering, loss, and duplication happen. Where and to what = degree is a question of the structure of networks that packets pass = through and what happens in those networks. The last time I know of = someone doing an actual measurement and reporting the results was rather = a while ago, but it said that at that time about 5% of arriving traffic = was reordered. For systemic reasons, I would imagine this is reduced, = and very dependent on what networks and types of networks are crossed. Going out on a limb a bit (this is what I suspect, not what I know), I = would imagine that today there are three major sources of traffic = reordering. One is loss; in radio networks (which include 3g/etc but = also include 802.11, 802.15, and 802.16), loss and retransmission are = pretty common. It would be interesting to have someone write a paper = measuring and analyzing the resultant =93best effort=94 behaviors in = those networks. Another is load balancing in the network; while it is = common for ECMP routing to send a subset of flows one way and another = subset on another, some networks schedule packets on the most available = bandwidth or go round robin. That is a recipe for reordering. The other = has to do with adaptive bitrate video and services that deliver it by = literally duplicating data. In these services, there is a path from the = CDN to the consumer that consists of two disjoint paths. The TCP = originator is configured with a link layer multicast address for its = first hop router, and there are in fact two such routers, one on each of = the parallel paths. The packets don=92t arrive at the endpoint, but they = do arrive at a point just before it, and the first of each pair of = packets to arrive is forwarded to the endpoint. You can imagine that the = collection point sees frequent duplication and some degree of = reordering. The single biggest source of reordering, I will postulate, is none of = those; it is the result of loss due to TCP=92s AIMD behavior. When a = packet is dropped in flight due to queue depth or delay, the rest of the = packets in that RTT arrive before it, and then its retransmission = arrives. Voila! Packet reordering. Should TCP handle packet reordering? Yes, of course. Making packet = arrival sequence completely random will certainly test that behavior; we = could discuss the beneficial effects of running TCP over CSNET in the = 1980=92s and the resulting hardening of TCP=92s algorithms. That doesn=92t= make that level of reordering a valid simulation of the Internet. A = more valid simulation will have one or both of two characteristics - = that a packet is dropped, the remaining packets in that RTT pass it, and = then it arrives, or that packets frequently arrive disordered but to a = degree that doesn=92t trigger TCP=92s Fast retransmit algorithm. --Apple-Mail=_B3464433-C0D2-4CDC-8500-4FFCF9974F88 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTYSylbjEdbHIsm0MRAveZAJ9QH27yVXDCyYko9Am2YcnfYlUeiACg87A1 G24MEFQU3Z3tSMYn3UqA+dw= =9nLq -----END PGP SIGNATURE----- --Apple-Mail=_B3464433-C0D2-4CDC-8500-4FFCF9974F88-- From nobody Wed Apr 30 18:56:10 2014 Return-Path: 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 09E141A09BA for ; Wed, 30 Apr 2014 18:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543] autolearn=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 L70haVhNprKk for ; Wed, 30 Apr 2014 18:55:53 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 939911A09B2 for ; Wed, 30 Apr 2014 18:55:53 -0700 (PDT) Received: from [66.46.38.18] (port=59329 helo=[172.16.61.38]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WfgDw-00031i-4x; Thu, 01 May 2014 02:55:48 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Colin Perkins In-Reply-To: Date: Wed, 30 Apr 2014 13:51:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7AC92FFB-76BE-494E-86E4-368BB0B6223C@csperkins.org> References: <81564C0D7D4D2A4B9A86C8C7404A13DA31F5BD0F@ESESSMB205.ericsson.se> <81564C0D7D4D2A4B9A86C8C7404A13DA31F5BDA6@ESESSMB205.ericsson.se> To: Zaheduzzaman Sarker X-Mailer: Apple Mail (2.1874) X-BlackCat-Spam-Score: -13 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rmcat/kzVA8FSwVT3PPbKi1DUWwjvTZHg Cc: Ingemar Johansson S , "rmcat WG \(rmcat@ietf.org\)" , "varun@comnet.tkk.fi" , "Fred Baker \(fred\)" , "Xiaoqing Zhu \(xiaoqzhu\)" , Erlendur Karlsson , "Michael Ramalho \(mramalho\)" Subject: Re: [rmcat] draft-sarker-rmcat-eval-test-00, test case 4.4 RMCAT Flow competing with a long TCP Flow 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 01:55:56 -0000 On 30 Apr 2014, at 07:50, Zaheduzzaman Sarker = wrote: > Are you saying re-ordering is not a phenomena that we can observe in = the current Internet? And we should not have test cases to handle = re-ordering of packets in RMCAT? One of my students collected some UDP streaming measurements from our = university to hosts on residential networks, covering all the main UK = ISPs, a couple of years ago. With everything using wired connections and = UDP we saw a couple of hundred packets delivered out of order, from ~250 = million packets sent. I can dig into the details of the re-ordering = patterns if there=92s interest. We didn=92t analyse them too closely at = the time because packet loss and delay spikes were much more common. Colin --=20 Colin Perkins http://csperkins.org/