From nobody Mon Jun 1 02:15:29 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906201A90D2 for ; Mon, 1 Jun 2015 02:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.52 X-Spam-Level: X-Spam-Status: No, score=0.52 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] 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 DNLC_jjhIIpp for ; Mon, 1 Jun 2015 02:15:25 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 023A81A90CF for ; Mon, 1 Jun 2015 02:15:24 -0700 (PDT) Received: by ieclw1 with SMTP id lw1so8928861iec.3 for ; Mon, 01 Jun 2015 02:15:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=9DB3yMtgMWfah3MsChqCQxQZDPOvM9d/d0u0luz01/k=; b=dwandKqoaGYDis9ZR4AZmqm35pYRpSThVZmIGqWiC/cYCpuefQJBPeMqqjyWYRM953 JbN7td0JcVfaG8UwT0g/DllHsSCNp4AXiJfy1oBhm9YMbKugAg9o8o6bx3t1ZXWDoMQs csOBDa82kgxecqcvtAe5tz9AVEM6/c8IFChqc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=9DB3yMtgMWfah3MsChqCQxQZDPOvM9d/d0u0luz01/k=; b=SjL32mcjhJi/ePpAR/HhE8y5U34Bcrqy/biiVMyykqx+CHzJBaYBvBXDH5uALnnOBL x1q7+GYoIM+UhzNkcrrvGUlFmVqg3AKF4ZKYdNkVGrk5XhtVfx2lSaIaosNG0yeUCFyQ Hztsirl+i1YQcP62D29tL/Jtz2GubuKjpliVMn6wNufpAQCgNAeqq1l63Egxjm159Ayz vm+zBTsgFKP4fc02CKvPvlmftdDWCpETcVG0eYN4Vu3AFYeRuySGWWYek+HB6gjtJP0i xmwKX+cz6dQpA+za4YOsXLIYXAvnkVS11uKJFr7Af+YvQZVBe3h3sZkKkmLAcuozEhIY bdmg== X-Gm-Message-State: ALoCoQkW3v2JOuaLKc0hRXxjSkZ/+qj5eZw6bOk+e8W5QXG0aEwKFnhY5EA2FMGvnnmVXzM/yzPlFPRpPea4NqyutMT8SksxfaOJ9Sg/PA5HL6cCxhp7S1Q= X-Received: by 10.50.79.196 with SMTP id l4mr12225183igx.48.1433150123922; Mon, 01 Jun 2015 02:15:23 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <882B8BE8-D02D-4E46-90B0-FE9CB2E88BF9@telecom-bretagne.eu> <655C07320163294895BBADA28372AF5D483AF02D@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D483AF02D@FR712WXCHMBA15.zeu.alcatel-lucent.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL7VJwomcXY3mf3wZzSms+lgcAi+gFhiVv/mzbD6AA= Date: Mon, 1 Jun 2015 11:15:23 +0200 Message-ID: To: "Scharf, Michael (Michael)" , per.hurtig@kau.se, anna.brunstrom@kau.se, apetlund@simula.no, michawe@ifi.uio.no Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: Cc: tcpm@ietf.org, tsvwg Subject: Re: [tcpm] draft-ietf-tcpm-rtorestart-07 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 09:15:27 -0000 Hi, Please accept the following - overdue - comments: General comments on SCTP applicability of the specification: ---------------------------------------------------------------------------= --- The document is inconsistent in its description of the SCTP aspects of the proposed algorithm. Section 1 and general: The document does say, in the end of Section 1, that the focus of the document is on TCP "with validity also for SCTP". However if so, then I think this paragraph should have been the first paragraph in section 1 rather than the last. I think that it is confusing that the Abstract (and the title) speaks about TCP and SCTP, but the introduction text speaks about TCP only. I think that it would be better for the text of section 1 to be augmented t= o speak about TCP _&_ SCTP. With the final paragraph then telling that in the remaining part of the documents, the focus would b= e on TCP (if this is the intend). (We have the SCTP API section in the end. Not sure how this fits with the notion of only providing details for TCP) Alternatively, if the present "TCP only" introduction is kept, I think that it would be relevant to emphasize in the final paragraph of section 1, that what has been described above in section 1, is common to TCP and SCTP (except possibly for the exact word "dupacks" - but I think one could get around that). Still even with the above clarifications, it is unclear to me what the status of this document is vis-a-vis SCTP. The detailed SCTP socket API description is there, but some of the crucial implementation aspects - e.g. section 5.3., is TCP only. But perhaps such inconsistency is ok for experimental ? Section 3: The contents of this section is common to TCP and SCTP except for the term segment which is TCP particular and which would be a packet in SCTP. Section 4: Here there is a reference to "similar update to RFC4960", but at the same time the word segment is used and further the section 5.3. discussion is TCP only. Detailed on Section 7: --------------------------- As far as I can tell this is exactly what we would like to have for SCTP. Thanks, BR, Karen PS: It turns out that some SCTP implementations may send two packets right after RTO thus applying the "allowed to breach CWND with PMTU-1" logic also immediately following RTO-timeout. This has impact of how delay_ack impacts the loss recovery time (refer to discussion in section 5.1). I believe tha= t the intent is to have this eventually be clarified to be incompliant behavior (also of SCTP), but SCTP then of course has the option to ask for immediate SACK in this situation, which then again changes the impact of delay_ack. There also exist SCTP implementations which rigorously follows TCP semantics and which thus do not breach the CWND right after RTO (only after receipt of first ACK after RTO) and which today does not deploy the Immediate SACK extension. For such the delay_ack impact is the RTO loss recovery as for TCP. The latter behavior is the right RFC4960 implementatio= n (at least I would argue that), but possibly not the "right" future SCTP implementation. >-----Original Message----- >From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael >(Michael) >Sent: Monday, May 18, 2015 11:22 AM >To: per.hurtig@kau.se; anna.brunstrom@kau.se; apetlund@simula.no; >michawe@ifi.uio.no >Cc: tcpm@ietf.org >Subject: Re: [tcpm] draft-ietf-tcpm-rtorestart-07 > >Authors, > >These (mostly editorial) comments are the only WGLC comments for draft- >ietf-tcpm-rtorestart-07 that I am aware of. Could you please discuss how t= o >address them? > >Thanks > >Michael > > > >> -----Original Message----- >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Nicolas Kuhn >> Sent: Thursday, May 07, 2015 5:00 PM >> To: tcpm@ietf.org >> Subject: [tcpm] draft-ietf-tcpm-rtorestart-07 >> >> Hi all, >> >> I had a look at this draft-ietf-tcpm-rtorestart-07 draft. >> I have some minor comments on the document. >> >> >########################################################### >## >> >> - "The RTO Restart (RTOR) mechanism described in this document makes >> the >> RTO slightly more aggressive when the number of outstanding segments >> is too small for fast retransmit to work, in an attempt to enable >> faster loss recovery for all segments while being robust to >> reordering." >> >> The RTO is not aggressive ; but the retransmission scheme ruled by RTO >> expirations is. >> I would recommend to rephrase that. >> >> >########################################################### >## >> >> - =E2=80=9C The RTO Restart (RTOR) mechanism described in this documen= t makes >> the >> RTO slightly [=E2=80=A6] highly varying RTTs, e.g. mobile networks." >> >> This whole paragraph comes to early in the document, as the reader has >> no clear idea about what RTOR is actually doing. I propose to add that >> in a dedicated sub- section in Section 5. >> >> >########################################################### >## >> >> - =E2=80=9C 3 RTO Restart Overview=E2=80=9D -> should it not be =E2=80= =9C3- RTO Overview and >> rationale of RTOR =E2=80=9C or something equivalent ? >> It is confusing, as you do not actually present RTOR. >> >> Also, in this section 3: >> The first paragraph finishes with =E2=80=9CHence, in most situations, t= he >> time before a retransmission is triggered is equal to "RTO + RTT=E2=80= =9D.=E2=80=9D >> But the example to illustrate it comes after - I think things should >> moved around to: >> 1- introduce the classic RTO >> 2- explain the rationale of classic RTO >> 3- example to show that RTO+RTT is common >> 4- more parameters could affect that (2 outstanding segments; other >> factors) >> 5- conclusion on =E2=80=9Chence, RTO+RTT is common for application limit= ed >> traffic" >> >> I would propose to introduce a ToC for this section 3: >> >> 3- RTO Overview and rationale of RTOR >> 3-1. Experienced RTO is RTO+RTT >> 3-2. RTO safety margin >> 3-3. Rationale of RTOR: when fast retransmit is not possible >> >> >########################################################### >## >> >> Section 4 : should focus on the description of the algorithm only. >> >> I would keep >> =E2=80=9C >> This approach makes the RTO more >> aggressive than the standardized approach in [RFC6298] but still >> conforms to the requirement in [RFC6298] that segments must not be >> retransmitted earlier than RTO seconds after their original >> transmission. >> " >> >> for the discussion section (at this stage of the reading, the reader >> still does not know exactly what RTOR is actually doing). >> >> >########################################################### >## >> >> Section 4: "it will prevent RTOR >> from being more aggressive and potentially causing RTOs instead of >> fast retransmits.=E2=80=9D >> >> More aggressive than what ? Has the "four" being experimentally >> obtained ? >> I think more discussion is required on this parameter. >> >> Regards, >> >> Nicolas >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Jun 1 06:58:23 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7451ACDF8 for ; Mon, 1 Jun 2015 06:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 hdCGmB8g8Agi for ; Mon, 1 Jun 2015 06:58:19 -0700 (PDT) Received: from fe1.lbl.gov (fe1.lbl.gov [128.3.41.133]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C701ACE0A for ; Mon, 1 Jun 2015 06:57:56 -0700 (PDT) X-Ironport-SBRS: 5.6 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8BAI5jbFXRVdiznGdsb2JhbABcgy81Ck8FBoMYrQWNIG6CAwEJhXMCgSwHTAEBAQEBARIBAQEBAQYNCQkhLoQZIhF0AQc3AiQSAQUBV4gLBQMFo0CDMT4xiz+GVJ0VCpBcghcMLxKBMwWMQYp+hl2BZ45QhTESI4EVhDseMYJHAQEB X-IronPort-AV: E=Sophos;i="5.13,533,1427785200"; d="scan'208";a="88369553" Received: from mail-qc0-f179.google.com ([209.85.216.179]) by fe1.lbl.gov with ESMTP; 01 Jun 2015 06:57:56 -0700 Received: by qcej9 with SMTP id j9so4639217qce.1 for ; Mon, 01 Jun 2015 06:57:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=sMDDQSagQzuokNjUP/dzCElkp+r5AYnSoHZFcVMWEzE=; b=WpB5faHSTuoYAlDFTFuXbBxBprXmUX85Fs8veNQCYqjR1FJnWwCU+cSLbvRwgXISQ/ nBdo8BDsjzIw8g1+9MYBKJbWry3BlGkkHlQyzXYYk5QvA6mK7xnURipDDGLmj4z/YA5Z MvZnlJfGvzXNl3MW1Zenvccy4g1ZVJTgqL8+wP5d7cCDDGMcQ0CO3ymEAhp5JhfgHl7V 4G47r6GI5ru3sdoiVYwOhpBnFC+c5n5Y+cxNdOEqMFkvXuN1PSinwxCBnCsoHa7ljXRm daJrVawAIj7Y0IkCGdHZkbLwy8+uVlT04sFM5Haa1cG8/UZqVKiKbgv2su/NMdcQwhLp VLUg== X-Gm-Message-State: ALoCoQm7N4iPR671XNRoTTMGUaIeJFGBapDmLKME3AUf+4J/tDnYdQM063VOp9nr7a9XH4JZF7r/BxXhyKdDKkuAAdVxOoMNvgxZjJD6vn10vcX7xGzaXth6/oIOJGzn0J+bJberDVQl X-Received: by 10.140.80.170 with SMTP id c39mr23400133qgd.55.1433167075890; Mon, 01 Jun 2015 06:57:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.80.170 with SMTP id c39mr23400124qgd.55.1433167075765; Mon, 01 Jun 2015 06:57:55 -0700 (PDT) Received: by 10.140.108.33 with HTTP; Mon, 1 Jun 2015 06:57:55 -0700 (PDT) Date: Mon, 1 Jun 2015 06:57:55 -0700 Message-ID: From: Brian Tierney To: tcpm@ietf.org Content-Type: multipart/alternative; boundary=001a11c1268c747aff051775365d Archived-At: Subject: [tcpm] testing the linux 'fair queuing' scheduler on 10G paths X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: bltierney@es.net List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 13:58:22 -0000 --001a11c1268c747aff051775365d Content-Type: text/plain; charset=UTF-8 Hi Folks: I've been working with a researcher at FNAL to try out the Linux ' Fair Queuing Scheduler'. Initial test results are here, and are VERY promising: http://fasterdata.es.net/host-tuning/linux/fair-queuing-scheduler/ Has anyone else tested this on high bandwidth, high latency paths? (and thanks to Matt Mathis for making me aware of this setting). -- Brian Tierney, http://www.es.net/tierney Energy Sciences Network (ESnet), Berkeley National Lab http://fasterdata.es.net --001a11c1268c747aff051775365d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Folks:

I've been working with a research= er at FNAL to try out the Linux '=C2=A0Fair Queuing Scheduler'.
=
Initial test results are here, and are VERY promising:
=C2=A0 =C2=A0= http://fasterdata.es.net/host-tuning/linux/fair-queuing-scheduler/<= br>
Has anyone else tested this on high bandwidth, high latency paths?= =C2=A0

(and thanks to Matt Mathis for making me= aware of this setting).

--
Brian Tierney, http://www.es.net/tierney
Energy Sciences Network (ESnet), Berke= ley National Lab
= http://fasterdata.es.net

--001a11c1268c747aff051775365d-- From nobody Mon Jun 1 09:10:36 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6C11B2CF0 for ; Mon, 1 Jun 2015 09:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 2DWWWNWZ38HR for ; Mon, 1 Jun 2015 09:10:29 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5313C1B2C57 for ; Mon, 1 Jun 2015 09:02:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E9ED0D931B; Mon, 1 Jun 2015 18:02:07 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8aAUrRY6fg26; Mon, 1 Jun 2015 18:02:07 +0200 (MEST) Received: from [192.168.178.33] (x4d02fd66.dyn.telefonica.de [77.2.253.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 7F293D930D; Mon, 1 Jun 2015 18:02:07 +0200 (MEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Priority: 3 (Normal) In-Reply-To: Date: Mon, 1 Jun 2015 18:02:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2E305B59-59FB-43B2-AE39-91999C426126@tik.ee.ethz.ch> References: <20150522173338.31853.44182.idtracker@ietfa.amsl.com> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.2098) Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-newcwv-11.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 16:10:35 -0000 Hi Gorry, thanks for applying my comments. Quick feedback on some points that are = unclear below. > pipeACK (section 4.1 and 4.2 and 4.5.1): > 1) Can you maybe add a sentence that explains why FlightSize is not > sufficient. > I understand the difference between the two variables but are there = actually > cases where it makes a big difference if one or the other is used? > - Added to section 1. That=E2=80=99s also good. But what I meant was: Why do you use pipeACK = in your algorithm? I believe in most cases if you would use FlightSize = instead of pipeACK, your algorithm your work the same way. Can you = further explain when this is not the case. > 1) Maybe add one sentence saying "A connection is also in = non-validated > phase if > pipeACK is zero which means the connection is idle". Saying this = explicit > would > help me to understand things better. > - Idle isn=C2=92t quite correct, what it means is no new data was = ACK=C2=92ed - > there could be data sent and pending ACK/ We changed 4.5.2 to clarify > this. >=20 > I just notice that this might actually not be true because in the = section > above > you say that pipeACK is set to undefined if no measurements are = available and > that would mean the connection goes into validated phase... okay I = think > there > is some clarification needed here. > - see above Just to make sure again that this is right. Form understanding the = document currently says, that if there are no measurements for a certain = time, pipeACK will be undefined and if pipeACk is undefined the = connection is in validated phase. That means as soon as a congestion = gets idle and has no measurements anymore it will go into validated = phase without any adjustments=E2=80=A6=20 I believe this sentence is wrong (in 4.3): "Validated phase: pipeACK >=3D(1/2)*cwnd, or pipeACK is undefined.=E2=80=9C= It should be: "Validated phase: pipeACK >=3D(1/2)*cwnd, or the connection just started = and therefore pipeACK is undefined.=E2=80=9C > 5) "ssthresh is adjusted using the standard TCP method." > This is not clear to me. Is ssthresh set to cwnd/2 before the > adjustment or > to cwnd-1 after the adjustment? The first option would restart the > connection in > Slow Start... Please clarify! > - We use the standard method, with no change. The problem is I don=E2=80=99t know what you mean by standard method. = RFC5681 says "ssthresh =3D max (FlightSize / 2, 2*SMSS)=E2=80=9C If that is what you want, the please refer to RFC 5681.=20 However, I think don=E2=80=99t think that this is what you want because = this would mean that the connection usually starts in Slow Start. I guess you actually want to set ssthresh=3Dcwnd-1. > 2) "An application that remains in the non-validated phase for a = period > greater than the NVP is required to adjust its congestion control > state. If the sender exits the non-validated phase after this > period, it MUST update the ssthresh:" >=20 > This is not fully clear to me. Do I have to adapt cwnd and ssthresh = right > after NVP or as soon as I leave the non-validated phase after being = for at > least > NVP time in this phase? If I'm not idle, but only sending with a low = rate, I > should probably do this adjustment with the next ACK, no...? > - Not sure of the difference, e hope the new intro helps with this. I think this was me thinking of the implementation of this: do I need a = timer or just need to remember the time when I entered the non-validated = phase. I guess there is actually no difference in the algorithm. So = that=E2=80=99s fine as it is! >=20 > 3) Further, these adjustments mean that the connection will be in Slow > Start. If > I understand this correctly, this is not a problem as long as the = connection > stays in non-validated as the cwnd will not be further increased. But = as > soon as > it leaves non-validated phase it will increase its cwnd as in Slow = Start. I > would like to have this spelled out explicitly. > - ??? The adjustment in section 4.4.3 will (usually) lead to ssthresh>cwnd at = the end of the non-validated period. That means the connection is in = Slow Start. If this is intended, please add one sentence says: =E2=80=9ETh= ese adjustment will set the connection in Slow Start (as ssthresh > = cwnd).=E2=80=9C Thanks, Mirja From nobody Mon Jun 1 09:18:16 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3731B2B92 for ; Mon, 1 Jun 2015 09:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.778 X-Spam-Level: ** X-Spam-Status: No, score=2.778 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_STOCK2=3.988, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 F8HPJucX4dsx for ; Mon, 1 Jun 2015 09:18:14 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28C791B2BE7 for ; Mon, 1 Jun 2015 09:15:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B54EFD931B; Mon, 1 Jun 2015 18:15:04 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mb711i3sC1tZ; Mon, 1 Jun 2015 18:15:04 +0200 (MEST) Received: from [192.168.178.33] (x4d02fd66.dyn.telefonica.de [77.2.253.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 34A39D9319; Mon, 1 Jun 2015 18:15:04 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Mon, 1 Jun 2015 18:15:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C415879-6BF7-403D-B904-CC2B4D32CA04@mac.com> To: Tom Sanders X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Why is Cubic said to be RTT-fair? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 16:18:16 -0000 Hi Tom, if your connection is 900Mbit/s and you have an RTT of 120ms, it=E2=80=99s= likely that our sent and or received buffer is too small as mention by = Rick. However, the scenario you describe, where you suddenly increase your = delay strongly and therefore the algorithm has to increase its = congestion window, in your case, from 19 packets to 9000 packets, has = nothing to do with the fact that window growth is independent of RTT.=20 What is meant in the Cubic paper is that to flows competing with a = different base RTT on the small link will still be able to share the = link capacity equally. That=E2=80=99s a completely different scenario. Increase the congestion window from 19 to 9000 packets in Congestion = Avoidance if for the most algorithms challenging. Cubic does better than = Reno but is still not optimal. I=E2=80=99ve presented an own algorithm a few IETF meeting ago, where we = introduce a Fast Increase phase to address this problem: https://www.ietf.org/proceedings/91/slides/slides-91-iccrg-5.pdf I personally think one could also apply this Fast Increase phase to = other existing algorithms with only slightly changing them. Mirja > Am 23.05.2015 um 03:16 schrieb Tom Sanders : >=20 > Hi Mirja, >=20 >=20 > the text below only says that if you have two cubic flows with a = different base RTT competing at the same bottleneck they=E2=80=99ll = still converge to share the link equally. This does not mean that if you = change the RTT strongly during one connection that Cubic is able to = catch up fast. >=20 > In fact this is one weakness of Cubic that I have observed. If there = are change in base delay/rtt or strong increases in the available = capacity, Cubic needs a rather long time to catch up. This is because = cubic has a =E2=80=9Atarget value=E2=80=98 to which it increases it = sending rate/window quickly but then if the capacity cap is not = somewhere close to this value (as expected) it will probe very = conservatively around this value and it takes a rather long time until = it gets back into a phase where it increases its congestion window fast. >=20 > Then which congestion control algorithm fares better there? I thought = Cubic was suited for large fat pipes -- bigger bandwidth-delay pipes.=20 > =20 >=20 > So what do you mean by 'I immediately saw that the TCP performance = went down=E2=80=98. How long do you run your test? And over which period = of time this the performance go down? >=20 > I did a simple test. >=20 > I connect two machines on my 1GB LAN.I do a tcp data transfer test and = i get around ~900Mbps. I then added a delay using qdisc on my outgoing = ethernet interface to simulate a longer RTT. So, if my ping earlier was = around 0.255ms, it then became 120ms. I repeat the test and i see that i = can only send about 200Mbps. I had to use multiple TCP flows to fill up = my 1GB link with Cubic. I run this experiment for about 2 minutes, and = Cubic is not able to catch up. I dont have long standing flows, and only = need to send bursts of data, hence did not leave it running for very = long. >=20 > I was under the impression, after having read the original Cubic paper = that Cubic's window growth rate is independent of RTT and hence wasnt = expecting any difference in the throughput. >=20 > Toms. >=20 > Mirja >=20 >=20 > > Am 21.05.2015 um 02:51 schrieb Tom Sanders : > > > > Hi Neal, > > > > This is odd. > > > > In the original Cubic paper = (http://www4.ncsu.edu/~rhee/export/bitcp/cubic-paper.pdf) by Rhee and = Xu, they explicitly state that the Cubic is independent of RTT. > > > > "The main feature of CUBIC is that its window growth function is = defined in real-time so that its growth will be independent of RTT. Our = work was partially inspired by HTCP [5], whose window growth function is = also based on real time. The congestion epoch period of CUBIC is = determined by the packet loss rate alone. As TCP=E2=80=99s throughput is = defined by the packet loss rate as well as RTT, the throughput of CUBIC = is defined by only the packet loss rate. Thus, when the loss rate is = high and/or RTT is short, CUBIC can operate in a TCP mode. Moreover, = since the growth function is independent of RTT, its RTT fairness is = guaranteed as different RTT flows will still grow their windows at the = same rate." > > > > Am i missing something here? > > > > Thanks, Toms > > > > On 20 May 2015 at 23:13, Neal Cardwell wrote: > > On Wed, May 20, 2015 at 1:18 PM, Tom Sanders = wrote: > > > Thanks Rick, this was very helpful. > > > > > > So if there are no setsockopts, etc then CUBIC's performance, = unlike other > > > TCP variants, should not get impacted by RTTs, right? Is that a = fair > > > statement to make? > > > > CUBIC, like most TCP congestion control variants, has significant > > aspects that evolve on the scale of RTTs: for example, in slow = start, > > loss recovery, or when the CUBIC function is very steep, CUBIC's > > behavior is heavily dependent on RTT (send some packets, wait for an > > ACK, send some more packets,...). So CUBIC will not be > > perfectly"RTT-fair. > > > > I think it might be fair to say something like: once a path is > > saturated with CUBIC flows, as long as loss recovery or send/receive > > buffers are not a bottleneck, then competition between CUBIC flows > > should be more RTT-fair than Reno, in the long run, since for large > > parts of the life cycle of the CUBIC flow the evolution of cwnd is > > constrained by wall clock time rather than ACK arrival. > > > > neal > > > > > > > Toms > > > > > > On 20 May 2015 at 19:51, Rick Jones wrote: > > >> > > >> > > >> On May 20, 2015, at 6:20 AM, Tom Sanders = wrote: > > >> > > >> > Hi, > > >> > > > >> > As per my understanding, unlike other TCP variants, CUBIC = claims to be > > >> > RTT fair. This is because the window growth rate is independent = of the RTT, > > >> > and hence the performance is the same as on a low and a high = RTT paths. > > >> > Others are dependent upon RTT since their windows grow as they = receive ACKs > > >> > from their peers, while CUBIC doesnt (window growth is a = function of time). > > >> > This is theory. > > >> > > > >> > In practice, CUBIC (which is the default now on most linux > > >> > distributions) also depends upon RTT. I connected to machines = on a LAN and > > >> > did a FTP transfer. I got a certain bandwidth. Next, i = artificially inserted > > >> > delay using "tc qdisc" in the path. I increased the delay on = the ethernet > > >> > interface connecting my linux machine to the LAN to be around = 100ms. I > > >> > immediately saw that the TCP performance went down. > > >> > > > >> > To bring it up to the same level as before i had to use = multiple TCP > > >> > streams. To me this means that CUBIC performance is dependent = of the RTT. So > > >> > why do we call it RTT-fair? > > >> > > >> I cannot speak to CUBIC specifically, but I would think you would = want to > > >> make sure you were seeing effects of congestion window and not of = the > > >> classic TCP window. For example, if the FTP client/server you = were using > > >> makes an explicit setsockopt() to set the socket buffer sizes and = by > > >> extension the classic TCP window, your bumping of the RTT to = around 100ms > > >> may have taken the bandwidth down as a consequence of the = classic: > > >> > > >> Throughput <=3D WindowSize/RTT > > >> > > >> Similarly, since you mention Linux, if the FTP client/server = didn=E2=80=99t make > > >> explicit setsockopt() calls, the sysctl values for tcp_rmem and = tcp_wmem > > >> may have been such that the auto tuning of the window size = couldn=E2=80=99t allow > > >> the classic TCP window to grow =E2=80=9Cenough.=E2=80=9D > > >> > > >> I suspect that the experiment needs to be setup to have the same = classic > > >> window size in both cases, sized per the above to be sufficient = to achieve > > >> the peak throughput in the high RTT case. Then you will have = eliminated > > >> classic window as a factor. > > >> > > >> Also, depending on the version of the Linux kernel you are using, = there > > >> may be some effects from tcp small queues or perhaps (a stretch?) = even byte > > >> queue limits which may not be playing well with netem. (Just = guessing there > > >> really) > > >> > > >> happy benchmarking, > > >> > > >> rick jones > > > > > > > > > > > > > > > -- > > > Toms. > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > > > > > > > -- > > Toms. > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 >=20 >=20 >=20 > --=20 > Toms. From nobody Tue Jun 2 13:29:22 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0CE1B2FDD for ; Tue, 2 Jun 2015 13:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.511 X-Spam-Level: X-Spam-Status: No, score=0.511 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 5r4ZjPdAhxZg for ; Tue, 2 Jun 2015 13:29:19 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39BB41B2FE0 for ; Tue, 2 Jun 2015 13:29:19 -0700 (PDT) Received: by oihb142 with SMTP id b142so134934095oih.3 for ; Tue, 02 Jun 2015 13:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wJmfeVYTM1rsIRJmRoEEM1qU8dEEHUqf+YMsIWFFSZQ=; b=IvkwucWt2lpLBw4AW/5/w49u0ylTBdNk1kj28Gcak4Up/o/UolesPLY0IhCMBs42Yd spWiWwjmH2rTv/NBRmDlGpXekxBXfgkCGQcSJ6ujtcsKSDLJ2dJEAUGiCLeQb3EkuG/F TPjSGdNhL9oii0Qo8kJWIVmRFEwtfx5MK6MJmCogedup1xqypyZjdJGm2ipx5K1xAPsi 2iSXz7P2F0qEN1U7yiOUaRuynW1yaQdBcaRWOIu5R2k+Wto2TqdkIv7hdm5qX8/lU17i JGodVvt/o0032EOhDMFwXNZNNK6jmGl0witNlJoj9Cvy+K5zDGnNAye0QuA+IggjxMu2 hK8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wJmfeVYTM1rsIRJmRoEEM1qU8dEEHUqf+YMsIWFFSZQ=; b=meZ5VbNMY5Irx9UW1+WVHGCHTyfzX/a2XUyihMmpVg7KlWc+0rkPxL49z9I9TvVjPH 0VSVubQiJ6ypiMEZC+pt+lwVYK/qb5XavHp6gLcnX3ruQua4grL9Hfpl4qkWxtMGf5/R asUEu6hEHuScqjTH+oW1tp3FusmeStE+kCS3jCJBa3wl3GE+BZbtYQCE4lsF5nELRIL9 gSi7mRpzKuxf4cy/Np+lm1aSQgw9oT5NIE8bQ7ua+BKtKo4bk+vjf15mTpNjMgxsY4tV JVoBasZrqk/DjDqQh3djfhtwBsLrzbz8YFdUzWJXLJ2ah15/RKCKOnGMj20k/MD00gs4 DCTA== X-Gm-Message-State: ALoCoQnJl7hQPaMuSSMDYV2kGZWWBzibEYq+WCP9H3FuEYK3mwrLjKszTVabJFfW/72WqeV9p1A4 MIME-Version: 1.0 X-Received: by 10.202.51.66 with SMTP id z63mr22962274oiz.49.1433276958675; Tue, 02 Jun 2015 13:29:18 -0700 (PDT) Received: by 10.182.59.79 with HTTP; Tue, 2 Jun 2015 13:29:18 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Jun 2015 13:29:18 -0700 Message-ID: From: Matt Mathis To: Brian Tierney Content-Type: multipart/alternative; boundary=001a113ce1b4fcc33305178ecbf8 Archived-At: Cc: tcpm Extensions WG Subject: Re: [tcpm] testing the linux 'fair queuing' scheduler on 10G paths X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 20:29:21 -0000 --001a113ce1b4fcc33305178ecbf8 Content-Type: text/plain; charset=UTF-8 Brian has real data, independently validating some of the stuff that Yuchung described at IETF 88. (Brian got 4x performance improvements in some cases!) Yuchung's presentation is here: http://www.ietf.org/proceedings/88/slides/slides-88-tcpm-9.pdf There are some prior results where pacing hurts performance: these generally involve medium scale flows with bursty cross traffic. Given that pacing increases TCP's "sampling coverage" of transient congestion, paced TCP fares poorly in these environments. These contrary results don't apply if: - there is little cross traffic; or - the cross traffic is also paced; or - if the paced traffic is a very large ensemble of relatively small flows. There are other people in this community who might benefit from pursuing these algorithms. They are upstream for a reason. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Mon, Jun 1, 2015 at 6:57 AM, Brian Tierney wrote: > > Hi Folks: > > I've been working with a researcher at FNAL to try out the Linux ' Fair > Queuing Scheduler'. > > Initial test results are here, and are VERY promising: > http://fasterdata.es.net/host-tuning/linux/fair-queuing-scheduler/ > > Has anyone else tested this on high bandwidth, high latency paths? > > (and thanks to Matt Mathis for making me aware of this setting). > > -- > Brian Tierney, http://www.es.net/tierney > Energy Sciences Network (ESnet), Berkeley National Lab > http://fasterdata.es.net > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > --001a113ce1b4fcc33305178ecbf8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Brian has real data, independently validating some of the = stuff that Yuchung described at IETF 88. =C2=A0=C2=A0(Brian got 4x performa= nce improvements in some cases!)

Yuchung's presentat= ion is here:=C2=A0http://www.ietf.org/proceedings/88/slides/slides-88-tcpm-= 9.pdf=C2=A0

There are some prior results where = pacing hurts performance: these generally involve medium scale flows with b= ursty cross traffic. Given that pacing increases TCP's "sampling c= overage" of transient congestion, paced TCP fares poorly in these envi= ronments.

These contrary results don't apply i= f:
- there is little cross traffic; or
- the cross traf= fic is also paced; or
- if the paced traffic is a very large ense= mble of relatively small flows.

There are other pe= ople in this community who might benefit from pursuing these algorithms.=C2= =A0 They are upstream for a reason.

Thanks,--MM--
The best way to predict the future is to create it. =C2=A0- A= lan Kay

Privacy matters!=C2=A0 We know from recent events that peopl= e are using our services to speak in defiance of unjust governments. =C2=A0= We treat privacy and security as matters of life and death, because for so= me users, they are.

On Mon, Jun 1, 2015 at 6:57 AM, Brian Tierne= y <bltierney@es.net> wrote:

Hi Folks:

I've been working with a researcher at FNAL to= try out the Linux '=C2=A0Fair Queuing Scheduler'.

Initial t= est results are here, and are VERY promising:
=C2=A0 =C2=A0http://fasterdata.es.net/host-tuning/linux/fair-queuing-scheduler/=

Has anyone else tested this on high bandwidth, high latency pat= hs?=C2=A0

(and thanks to Matt Mathis for making= me aware of this setting).
<= div>
--
Brian Tierney, http://www.es.net/tierney
Energy Sciences Netw= ork (ESnet), Berkeley National Lab
http://fasterdata.es.net


_______________________________________________
tcpm mailing list
tcpm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tcpm


--001a113ce1b4fcc33305178ecbf8-- From nobody Fri Jun 5 08:17:43 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121CE1B30CD for ; Fri, 5 Jun 2015 08:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_84=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 z5sb5cg-ajun for ; Fri, 5 Jun 2015 08:17:38 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6421A19F2 for ; Fri, 5 Jun 2015 08:17:38 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 50C271B001AB; Fri, 5 Jun 2015 16:17:35 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Fri, 5 Jun 2015 16:16:37 +0100 Message-ID: In-Reply-To: <557029B4.9030001@tik.ee.ethz.ch> References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch> <36C995D9-261C-4AAD-A86D-681F58CACF9A@mit.edu> <557029B4.9030001@tik.ee.ethz.ch> Date: Fri, 5 Jun 2015 16:16:37 +0100 From: gorry@erg.abdn.ac.uk To: =?iso-8859-1?Q?=22Mirja_K=FChlewind=22?= User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: raffaello@erg.abdn.ac.uk, tcpm@ietf.org Subject: [tcpm] Comments on draft-ietf-tcpm-newcwv-11 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 15:17:42 -0000 Mirja, Raffaello and I have looked at these comments and we think they do help, please find below suggested improvements to address these comments. Please do check first that we have covered all things, and we'll then revise and submit with all the changes. Best wishes, Gorry & Raffaello > Mirja: > > ------------------------------------------------------------------- >> >> pipeACK (section 4.1 and 4.2 and 4.5.1): >> 1) Can you maybe add a sentence that explains why FlightSize is not >> sufficient. >> I understand the difference between the two variables but are there >> actually >> cases where it makes a big difference if one or the other is used? >> - Added to section 1. > > > That’s also good. But what I meant was: Why do you use pipeACK in your > algorithm? I believe in most cases if you would use FlightSize instead > of pipeACK, your algorithm your work the same way. Can you further > explain when this is not the case. > > We think that FS can give an under-estimation of capacity during recovery, when recovering the end of a burst, and can over-estimate capacity when the sender has been previously idle. This is because FS only measures segments in flight, whereas pipeACK measures segments actually transferred across the path. To help explain places this can make a difference we suggest to add back the following from the list discussion (A version of this text appeared in the notes, which would be removed for publication, we suggest the above edited version should be included in the RFC.) We think this would be better included in the final document. After final para in 4.2: NEW: NOTE: The use of pipeACK rather than FlightSize can change the behaviour of TCP when a sender does not always have data available to send. One example is when there is a pause in transmission after sending a sequence of many packets, and the sender experiences loss at or near the end of its transmission sequence. In this case, the TCP flow may have used a significant amount of capacity just prior to the loss (which would be reflected in the volume of data acknowledged, recorded in the pipeACK variable), but at the time of loss the number of unacknowledged packets in flight at the end of the sequence may be small (i.e., there is a small FlightSize). After loss recovery, the sender resets the congestion control state. [Fai12] explored the benefits of different responses to congestion for application limited streams. If the response is based only on the Loss FlightSize, the sender would assign a small cwnd and ssthresh based only on the volume of data sent after the loss. When the sender next starts to transmit it can incur may RTTs of delay in slow start before it reacquires its previous rate. When the pipeACK value is also used to calculate the cwnd and ssthresh (Sect XX), the sender can use values that also reflects the recently used capacity before the loss. This prevents a variable-rate application from being unduly penalised. When the sender resumes, it start at one half its previous rate, similar to the behaviour of a bulk TCP flow [Hos15]. This method requires that pipeACK variable to be reset after it is used in this way to ensure an appropriate reaction to on-going congestion. -- [Hos15] PhD Thesis, A Study of Mechanisms to Support Variable-rate Internet Applications over a Multi-service Satellite Platform, School of Engineering, University of Aberdeen. -- > > >> 1) Maybe add one sentence saying "A connection is also in non-validated >> phase if >> pipeACK is zero which means the connection is idle". Saying this explicit >> would >> help me to understand things better. >> - Idle isn’t quite correct, what it means is no new data was ACK’ed - >> there could be data sent and pending ACK/ We changed 4.5.2 to clarify >> this. >> >> I just notice that this might actually not be true because in the section >> above >> you say that pipeACK is set to undefined if no measurements are available >> and >> that would mean the connection goes into validated phase... okay I think >> there >> is some clarification needed here. >> - see above > > > Just to make sure again that this is right. From understanding the > document currently says, that if there are no measurements for a > certain time, pipeACK will be undefined and if pipeACk is undefined > the connection is in validated phase. That means as soon as a > congestion gets idle and has no measurements anymore it will go into > validated phase without any adjustments… > > I believe this sentence is wrong (in 4.3): > > "Validated phase: pipeACK >=(1/2)*cwnd, or pipeACK is undefined.“ > > It should be: > > "Validated phase: pipeACK >=(1/2)*cwnd, or the connection just started > and therefore pipeACK is undefined.“ > > Section 4.3: OLD: Validated phase: pipeACK >=(1/2)*cwnd, or pipeACK is undefined. NEW: Validated phase: pipeACK >=(1/2)*cwnd, or pipeACK is undefined (at the start or directly after loss recovery). --- In fact you're right, the "no measurement" condition only occurs at the start or after a loss detection (this was contradicted in the intro, thanks for noting this): Section 4.2: OLD: When no measurements are available (e.g., a sender that has been idle will have sent no data and received no ACKs), the pipeACK variable is set to the "undefined value". NEW: When no measurements are available (e.g., a sender that has just started transmission or immediately after loss recovery), the pipeACK variable is set to the "undefined value". --- When no measurement are available during a transmission without losses, the idle period are ignored as explained in 4.5.1, which is equivalent to set pipeACK samples to zero. > > The text between brackets in the 5th par of sec 4.2 should be changed to: > > When no measurements are available (i.e. when the connection is > started or after pipeACK > was invalidated following loss detection), the pipeACK variable is > set to the "undefined value". > I think it would also be useful to add a sentence (see below) in 4.5.1 that explicitly calls out what happens in idle in the implementation example. Section 4.5.1, example: OLD: There was also a period of inactivity between samples B and C during which no measurements were taken (because no new data segments were acknowledged). NEW: There was also a period of inactivity between samples B and C during which no measurements were taken (because no new data segments were acknowledged). During this period the pipeACK samples may be regarded as zero, and hence do not contribute to the calculated pipeACK value. > >> 5) "ssthresh is adjusted using the standard TCP method." >> This is not clear to me. Is ssthresh set to cwnd/2 before the >> adjustment or >> to cwnd-1 after the adjustment? The first option would restart the >> connection in >> Slow Start... Please clarify! >> - We use the standard method, with no change. > > > The problem is I don’t know what you mean by standard method. RFC5681 says > > "ssthresh = max (FlightSize / 2, 2*SMSS)“ > > If that is what you want, the please refer to RFC 5681. > > However, I think don’t think that this is what you want because this > would mean that the connection usually starts in Slow Start. > > I guess you actually want to set ssthresh=cwnd-1. > > We actually referred to the FR/FR algorithm in Sec 3.2 of RFC 5681. In step 6 there is a method that assigns ssthresh=cwnd at the end of the recovery. Section 4.4.1: OLD: ssthresh is adjusted using the standard TCP method. NEW: The ssthresh is adjusted using the standard TCP method (Step 6 in Section 3.2 of RFC 5681 assigns the ssthresh a value equal to cwnd at the end of the loss recovery). --- > >> 2) "An application that remains in the non-validated phase for a period >> greater than the NVP is required to adjust its congestion control >> state. If the sender exits the non-validated phase after this >> period, it MUST update the ssthresh:" >> >> This is not fully clear to me. Do I have to adapt cwnd and ssthresh >> right >> after NVP or as soon as I leave the non-validated phase after being for at >> least >> NVP time in this phase? If I'm not idle, but only sending with a low rate, >> I >> should probably do this adjustment with the next ACK, no...? >> - Not sure of the difference, e hope the new intro helps with this. > > > I think this was me thinking of the implementation of this: do I need > a timer or just need to remember the time when I entered the > non-validated phase. I guess there is actually no difference in the > algorithm. So that’s fine as it is! > Yes, there is no difference. Section 4.5.1: --- This section contained a note at its end to illustrate how to implement the method without using OS timers. To make this more clear, the text has been re-written as a separate implementation consideration, as below: REPLACEMENT: The method requires a number of measurements of time. These measurements could be implemented using protocol timers, but do not necessarily require a new timer to be implemented. Avoiding the use of dedicated timers can save operating system resources, especially when there may be large numbers of TCP flows. The NVP could be measured by recording a timestamp when the sender enters the non-validated phase. Each time a sender transmits a new segment, this timestamp can be used to determine if the NVP has expired. If the measured period exceeds the NVP, the sender can then take into account how many units of the NVP have passed and make one reduction (XREF) for each NVP. Similarly the time measurements for collecting pipeACK samples and determining the Sampling Period could be derived by using a timestamp to record when each sample was measured, and to use this to calculate how much time has passed when each new ACK is received. >> >> 3) Further, these adjustments mean that the connection will be in Slow >> Start. If >> I understand this correctly, this is not a problem as long as the >> connection >> stays in non-validated as the cwnd will not be further increased. But as >> soon as >> it leaves non-validated phase it will increase its cwnd as in Slow Start. >> I >> would like to have this spelled out explicitly. >> - ??? > > > The adjustment in section 4.4.3 will (usually) lead to ssthresh>cwnd > at the end of the non-validated period. That means the connection is > in Slow Start. If this is intended, please add one sentence says: > „These adjustment will set the connection in Slow Start (as ssthresh > > cwnd).“ > That's correct. We added that sentence. Note that this also happened in RFC 2861 after one RTO idle period. Section 4.4.3, Note: OLD: Note: This adjustment ensures that the sender responds conservatively... NEW: Note: These cwnd and ssthresh adjustments cause the sender to enter slow-start (since ssthresh > cwnd). This adjustment ensures that the sender responds conservatively... --- > > > Thanks, > Mirja > > > From nobody Sat Jun 6 09:24:59 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FD81A902D for ; Fri, 5 Jun 2015 10:01:49 -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 Qj6iDxdKiSGf for ; Fri, 5 Jun 2015 10:01:48 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9DFB1A9026 for ; Fri, 5 Jun 2015 10:01:47 -0700 (PDT) Received: by wiga1 with SMTP id a1so27189818wig.0 for ; Fri, 05 Jun 2015 10:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8s188EsBz9nxXkaNyML5Gunftk85xclldkJq272L4vI=; b=mZPMMbPiR1iF22ri+Udfh8XQyaGHKv8prt9h8kvEQyftawky/63iqmf0WlmhqcyaZk bsBxOQ207or9bGfQlllpfLZAs/nI7rl7ZranPLwiJsY4hCgWErJdr0W/I7RJZq3EiuNJ C6G6ozZXMpvIF0rIF4Boq+rgnfZhhAMY0xjIFFsRG695oF0Oxt2fOVs3W3P2zGnIwh7I 5krxtHDRgT7vtruhW+KEkXuNO+2u2Mc244IlfhYfJcAFmCQciDH/UFSYzKJj2jWRajAz msciB4QtkxkE0dLlQyV/spss/oX7Q1TB9ToYDn3CgCCANCZib7RaOzEQWqWtwdhHd1d3 faFg== X-Received: by 10.180.73.10 with SMTP id h10mr20229186wiv.3.1433523705638; Fri, 05 Jun 2015 10:01:45 -0700 (PDT) Received: from black.lan (5ec2f7dd.skybroadband.com. [94.194.247.221]) by mx.google.com with ESMTPSA id hn7sm4124422wib.5.2015.06.05.10.01.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jun 2015 10:01:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Piers O'Hanlon In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA32145DE4@ESESSMB205.ericsson.se> Date: Fri, 5 Jun 2015 18:01:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1FFD9A11-ADF2-4BA6-A9D3-D8997E1A13E5@gmail.com> References: <81564C0D7D4D2A4B9A86C8C7404A13DA32145DE4@ESESSMB205.ericsson.se> To: Ingemar Johansson S X-Mailer: Apple Mail (2.1283) Archived-At: X-Mailman-Approved-At: Sat, 06 Jun 2015 09:24:58 -0700 Cc: "tcpm@ietf.org" , "end2end-interest@postel.org" Subject: Re: [tcpm] [e2e] TCP HyStart patch deployment X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 17:01:49 -0000 Hi Ingemar, Looking at linux-4.04 git code: = https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/= net/ipv4/tcp_cubic.c?id=3Drefs/tags/v4.0.4#n403 It seems the HYSTART_DELAY code has been tweaked into a somewhat similar = direction (right shift 3 instead of the original 4) to the patch: HYSTART_DELAY_THRESH(ca->delay_min >> 3)) { Although the ACK train detection does appear unchanged. It would seem that Hystart could have issues at very high rates as it = does rely on a few default parameters that might not be suitable for = such environments. I can also imagine that it may not work so well on = WiFi with block ACKing as Hystart uses a fixed window of 8 packets to = estimate current delay which may end up being one block of packets... Did you try asking this question on any Linux networking lists? Cheers, Piers. On 26 May 2015, at 12:38, Ingemar Johansson S wrote: > Hi >=20 > Does anybody know if the TCP Cubic HyStart patch described in the link = below is being used widely ? > It does not seem to be implemented in the latest Linux code. > http://patchwork.ozlabs.org/patch/85945/ >=20 > Regards > 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 >=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 > "No man has a good enough memory > to be a successful liar" > Abraham = Lincoln > =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 > _______________________________________________ > end2end-interest mailing list > end2end-interest@postel.org > http://mailman.postel.org/mailman/listinfo/end2end-interest > Contact list-owner@postel.org for assistance. From nobody Tue Jun 9 05:46:35 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC6B1A6F2F for ; Tue, 9 Jun 2015 05:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 y_7iukYGUFJy for ; Tue, 9 Jun 2015 05:46:30 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9B91A6FF1 for ; Tue, 9 Jun 2015 05:46:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6B18ED9317; Tue, 9 Jun 2015 14:46:27 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id U7bk1TEsxPuJ; Tue, 9 Jun 2015 14:46:27 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 05BACD9316; Tue, 9 Jun 2015 14:46:27 +0200 (MEST) Message-ID: <5576E01D.2000702@tik.ee.ethz.ch> Date: Tue, 09 Jun 2015 14:46:21 +0200 From: =?windows-1252?Q?Mirja_K=FChlewind?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch> <36C995D9-261C-4AAD-A86D-681F58CACF9A@mit.edu> <557029B4.9030001@tik.ee.ethz.ch> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: raffaello@erg.abdn.ac.uk, tcpm@ietf.org Subject: Re: [tcpm] Comments on draft-ietf-tcpm-newcwv-11 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 12:46:34 -0000 Hi Gorry, thanks for taking care of this. All changes are great and now makes things absolutely clear to me. Please go ahead and submit. Mirja P.S.: The text below says somewhere "(Sect XX)"; that should probably be still replaced; just that you don't overlook it. And maybe also put a name in for the new reference. On 05.06.2015 17:16, gorry@erg.abdn.ac.uk wrote: > > Mirja, > > Raffaello and I have looked at these comments and we think they do help, > please find below suggested improvements to address these comments. > Please do check first that we have covered all things, and we'll then > revise and submit with all the changes. > > Best wishes, > > Gorry & Raffaello > >> Mirja: >> >> ------------------------------------------------------------------- >>> >>> pipeACK (section 4.1 and 4.2 and 4.5.1): >>> 1) Can you maybe add a sentence that explains why FlightSize is not >>> sufficient. >>> I understand the difference between the two variables but are there >>> actually >>> cases where it makes a big difference if one or the other is used? >>> - Added to section 1. >> >> >> That’s also good. But what I meant was: Why do you use pipeACK in your >> algorithm? I believe in most cases if you would use FlightSize instead >> of pipeACK, your algorithm your work the same way. Can you further >> explain when this is not the case. >> >> > We think that FS can give an under-estimation of capacity during recovery, > when recovering the end of a burst, and can over-estimate capacity when > the sender has been previously idle. This is because FS only measures > segments in flight, whereas pipeACK measures segments actually transferred > across the path. > > To help explain places this can make a difference we suggest to add back > the following from the list discussion (A version of this text appeared in > the notes, which would be removed for publication, we suggest the above > edited version should be included in the RFC.) We think this would be > better included in the final document. > > After final para in 4.2: > > NEW: > > NOTE: The use of pipeACK rather than FlightSize can change the behaviour > of TCP when a sender does not always have data available to send. One > example is when there is a pause in transmission after sending a sequence > of many packets, and the sender experiences loss at or near the end of its > transmission sequence. In this case, the TCP flow may have used a > significant amount of capacity just prior to the loss (which would be > reflected in the volume of data acknowledged, recorded in the pipeACK > variable), but at the time of loss the number of unacknowledged packets in > flight at the end of the sequence may be small (i.e., there is a small > FlightSize). After loss recovery, the sender resets the congestion > control state. > > [Fai12] explored the benefits of different responses to congestion for > application limited streams. If the response is based only on the Loss > FlightSize, the sender would assign a small cwnd and ssthresh based only > on the volume of data sent after the loss. When the sender next starts to > transmit it can incur may RTTs of delay in slow start before it reacquires > its previous rate. When the pipeACK value is also used to calculate the > cwnd and ssthresh (Sect XX), the sender can use values that also reflects > the recently used capacity before the loss. This prevents a variable-rate > application from being unduly penalised. When the sender resumes, it start > at one half its previous rate, similar to the behaviour of a bulk TCP flow > [Hos15]. This method requires that pipeACK variable to be reset after it > is used in this way to ensure an appropriate reaction to on-going > congestion. > > -- > > [Hos15] PhD Thesis, A Study of Mechanisms to Support Variable-rate > Internet Applications over a Multi-service Satellite Platform, School of > Engineering, University of Aberdeen. > -- ------------------------------------------ Dipl.-Ing. Mirja Kühlewind Communication Systems Group Institute TIK, ETH Zürich Gloriastrasse 35, 8092 Zürich, Switzerland Room ETZ G93 phone: +41 44 63 26932 email: mirja.kuehlewind@tik.ee.ethz.ch ------------------------------------------ From nobody Thu Jun 11 02:46:17 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71C21ACDB8 for ; Thu, 11 Jun 2015 02:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 jGqwl5JiEIg2 for ; Thu, 11 Jun 2015 02:46:13 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B4A1A8907 for ; Thu, 11 Jun 2015 02:46:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,594,1427785200"; d="scan'208";a="47492048" Received: from hioexcmbx02-prd.hq.netapp.com ([10.122.105.35]) by mx143-out.netapp.com with ESMTP; 11 Jun 2015 02:45:00 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 11 Jun 2015 02:44:59 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([fe80::1846:d2ef:c820:5690]) by hioexcmbx05-prd.hq.netapp.com ([fe80::1846:d2ef:c820:5690%21]) with mapi id 15.00.1076.000; Thu, 11 Jun 2015 02:44:59 -0700 From: "Scheffenegger, Richard" To: "Scharf, Michael (Michael)" , "tcpm@ietf.org" Thread-Topic: Feedback on WG acceptance of draft-bensley-tcpm-dctcp-03 Thread-Index: AdB82dvas/DQQ7w2TuSWSxKiXj5XLgUbrOuQBLiVTgA= Date: Thu, 11 Jun 2015 09:44:59 +0000 Message-ID: <08b609975aa941bbb21599ca11d2e289@hioexcmbx05-prd.hq.netapp.com> References: <655C07320163294895BBADA28372AF5D16C939E2@FR712WXCHMBA15.zeu.alcatel-lucent.com> <655C07320163294895BBADA28372AF5D483AF007@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D483AF007@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Feedback on WG acceptance of draft-bensley-tcpm-dctcp-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 09:46:16 -0000 Hi, I'd like to point out, for those who haven't read this paper closely, that = some operational experience on ECN codepoints during the initial 3WHS is al= so contained. Potentially, these findings need to be acknowledged and cater= ed for with AccECN... As one of the authors of AccECN, I'd like to hear the groups view on how th= at could be accomplished. Best regards, Richard > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael > (Michael) > Sent: Montag, 18. Mai 2015 11:12 > To: tcpm@ietf.org > Subject: Re: [tcpm] Feedback on WG acceptance of draft-bensley-tcpm-dctcp= - > 03 >=20 > Hi all, >=20 > There have not been many responses to this e-mail. The chairs therefore > conclude that there is not enough support for adoption of draft-bensley- > tcpm-dctcp-03 as TCPM WG item as of now. >=20 > Since the TCPM community seems interested in further discussing this > topic, the chairs would offer to allocate time for corresponding > discussions during upcoming TCPM meetings. >=20 > Thanks >=20 > Michael, Pasi, Yoshifumi >=20 >=20 > PS: We recently found one possibly interesting study on operational > experience: https://www.usenix.org/system/files/conference/nsdi15/nsdi15- > paper-judd.pdf >=20 >=20 > > -----Original Message----- > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael > > (Michael) > > Sent: Wednesday, April 22, 2015 10:54 AM > > To: tcpm@ietf.org > > Subject: [tcpm] Feedback on WG acceptance of draft-bensley-tcpm-dctcp- > > 03 > > > > Dear all, > > > > During IETF 89 [1] and on the list there has been a discussion about > > WG adoption of draft-bensley-tcpm-dctcp [2]. The understanding of the > > chairs is that there is no clear consensus up to now. > > > > In order to move forward, the chairs seek for community guidance > > regarding the following options to handle this draft: > > > > a) Adopt in TCPM as Informational > > > > b) Adopt in TCPM as Experimental > > > > c) Do not adopt in TCPM now > > > > Option c) does not prevent publication outside TCPM, such as > > publication by another working group (e.g., TSVWG), publication on > > Independent Stream, etc. > > > > The TCPM chairs believe that adoption of alternative congestion > > control algorithms in TCPM should be backed by a strong consensus. > > Please also review [3] and [4] regarding the difference between > > Experimental and Informational. > > > > Please let us know any feedback on a potential WG acceptance of draft- > > bensley-tcpm-dctcp-03 until May 8. > > > > Thanks! > > > > Michael, Pasi, Yoshifumi > > > > > > [1] http://www.ietf.org/proceedings/89/minutes/minutes-89-tcpm > > > > [2] https://tools.ietf.org/html/draft-bensley-tcpm-dctcp-03 > > > > [3] RFC 2026, Section 4.2.1, 4.2.2 > > > > [4] https://www.ietf.org/iesg/informational-vs-experimental.html > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Jun 11 02:51:48 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7BF1B2E1A; Thu, 11 Jun 2015 02:51:47 -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 nhVda7Uy5woW; Thu, 11 Jun 2015 02:51:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFC51B2E19; Thu, 11 Jun 2015 02:51:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150611095146.8605.8922.idtracker@ietfa.amsl.com> Date: Thu, 11 Jun 2015 02:51:46 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-12.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 09:51:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Updating TCP to support Rate-Limited Traffic Authors : Godred Fairhurst Arjuna Sathiaseelan Raffaello Secchi Filename : draft-ietf-tcpm-newcwv-12.txt Pages : 26 Date : 2015-06-11 Abstract: This document provides a mechanism to address issues that arise when TCP is used to support traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It provides an experimental update to TCP that allows a TCP sender to restart quickly following a rate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP, while also providing an appropriate response if congestion is experienced. It also evaluates the Experimental specification of TCP Congestion Window Validation, CWV, defined in RFC 2861, and concludes that RFC 2861 sought to address important issues, but failed to deliver a widely used solution. This document therefore recommends that the status of RFC 2861 is moved from Experimental to Historic, and that it is replaced by the current specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-newcwv-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 11 03:21:20 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940271B2E63 for ; Thu, 11 Jun 2015 03:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 iHH8XZeSpyaL for ; Thu, 11 Jun 2015 03:21:16 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 724391B2E84 for ; Thu, 11 Jun 2015 03:21:16 -0700 (PDT) Received: from [192.168.0.11] (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id D426C1B001AB; Thu, 11 Jun 2015 11:21:17 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Gorry (erg)" X-Mailer: iPhone Mail (12D508) In-Reply-To: <5576E01D.2000702@tik.ee.ethz.ch> Date: Thu, 11 Jun 2015 11:21:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9FB69628-858D-4577-A8F4-172895015584@erg.abdn.ac.uk> References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch> <36C995D9-261C-4AAD-A86D-681F58CACF9A@mit.edu> <557029B4.9030001@tik.ee.ethz.ch> <5576E01D.2000702@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= Archived-At: Cc: "raffaello@erg.abdn.ac.uk" , "tcpm@ietf.org" Subject: Re: [tcpm] Comments on draft-ietf-tcpm-newcwv-11 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 10:21:18 -0000 Thanks for this.=20 We have submitted Rev 12 that incorporates these changes and minor language i= mprovements. The editors think this is now ready for the IESG to review. Gorry > On 9 Jun 2015, at 13:46, Mirja K=C3=BChlewind wrote: >=20 > Hi Gorry, >=20 > thanks for taking care of this. All changes are great and now makes things= absolutely clear to me. Please go ahead and submit. >=20 > Mirja >=20 > P.S.: The text below says somewhere "(Sect XX)"; that should probably be s= till replaced; just that you don't overlook it. And maybe also put a name in= for the new reference. >=20 >=20 >=20 >> On 05.06.2015 17:16, gorry@erg.abdn.ac.uk wrote: >>=20 >> Mirja, >>=20 >> Raffaello and I have looked at these comments and we think they do help, >> please find below suggested improvements to address these comments. >> Please do check first that we have covered all things, and we'll then >> revise and submit with all the changes. >>=20 >> Best wishes, >>=20 >> Gorry & Raffaello >>=20 >>> Mirja: >>>=20 >>> ------------------------------------------------------------------- >>>>=20 >>>> pipeACK (section 4.1 and 4.2 and 4.5.1): >>>> 1) Can you maybe add a sentence that explains why FlightSize is not >>>> sufficient. >>>> I understand the difference between the two variables but are there >>>> actually >>>> cases where it makes a big difference if one or the other is used? >>>> - Added to section 1. >>>=20 >>>=20 >>> That=E2=80=99s also good. But what I meant was: Why do you use pipeACK i= n your >>> algorithm? I believe in most cases if you would use FlightSize instead >>> of pipeACK, your algorithm your work the same way. Can you further >>> explain when this is not the case. >> We think that FS can give an under-estimation of capacity during recovery= , >> when recovering the end of a burst, and can over-estimate capacity when >> the sender has been previously idle. This is because FS only measures >> segments in flight, whereas pipeACK measures segments actually transferre= d >> across the path. >>=20 >> To help explain places this can make a difference we suggest to add back >> the following from the list discussion (A version of this text appeared i= n >> the notes, which would be removed for publication, we suggest the above >> edited version should be included in the RFC.) We think this would be >> better included in the final document. >>=20 >> After final para in 4.2: >>=20 >> NEW: >>=20 >> NOTE: The use of pipeACK rather than FlightSize can change the behaviour >> of TCP when a sender does not always have data available to send. One >> example is when there is a pause in transmission after sending a sequence= >> of many packets, and the sender experiences loss at or near the end of it= s >> transmission sequence. In this case, the TCP flow may have used a >> significant amount of capacity just prior to the loss (which would be >> reflected in the volume of data acknowledged, recorded in the pipeACK >> variable), but at the time of loss the number of unacknowledged packets i= n >> flight at the end of the sequence may be small (i.e., there is a small >> FlightSize). After loss recovery, the sender resets the congestion >> control state. >>=20 >> [Fai12] explored the benefits of different responses to congestion for >> application limited streams. If the response is based only on the Loss >> FlightSize, the sender would assign a small cwnd and ssthresh based only >> on the volume of data sent after the loss. When the sender next starts to= >> transmit it can incur may RTTs of delay in slow start before it reacquire= s >> its previous rate. When the pipeACK value is also used to calculate the >> cwnd and ssthresh (Sect XX), the sender can use values that also reflects= >> the recently used capacity before the loss. This prevents a variable-rate= >> application from being unduly penalised. When the sender resumes, it star= t >> at one half its previous rate, similar to the behaviour of a bulk TCP flo= w >> [Hos15]. This method requires that pipeACK variable to be reset after it >> is used in this way to ensure an appropriate reaction to on-going >> congestion. >>=20 >> -- >>=20 >> [Hos15] PhD Thesis, A Study of Mechanisms to Support Variable-rate >> Internet Applications over a Multi-service Satellite Platform, School of >> Engineering, University of Aberdeen. >=20 > --=20 > ------------------------------------------ > Dipl.-Ing. Mirja K=C3=BChlewind > Communication Systems Group > Institute TIK, ETH Z=C3=BCrich > Gloriastrasse 35, 8092 Z=C3=BCrich, Switzerland >=20 > Room ETZ G93 > phone: +41 44 63 26932 > email: mirja.kuehlewind@tik.ee.ethz.ch > ------------------------------------------ From nobody Sun Jun 14 07:27:26 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3469F1A86EE for ; Sun, 14 Jun 2015 07:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] 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 cq2ORVdPWAZt for ; Sun, 14 Jun 2015 07:27:24 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.227]) by ietfa.amsl.com (Postfix) with ESMTP id 288351A017A for ; Sun, 14 Jun 2015 07:27:24 -0700 (PDT) Received: from t40700-la020.lan (80.223.92.46) by jenni2.inet.fi (8.5.142.08) (authenticated as saropa-1) id 552B87C904CAE922 for tcpm@ietf.org; Sun, 14 Jun 2015 17:27:23 +0300 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sun, 14 Jun 2015 17:27:21 +0300 To: "tcpm@ietf.org Extensions" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [tcpm] Agenda requests for TCPM at IETF-93 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 14:27:26 -0000 Hi, It is time to start building the TCPM meeting agenda for Prague meeting. = We have requested a 2.5 - hour slot. If you want to present something in = the meeting, please send request to tcpm-chairs with the following = information: * Draft name / presentation title * Requested time * Speaker Please send requests as soon as possible, but latest by Thursday, July = 2nd. Thanks! - Pasi From nobody Wed Jun 17 09:27:04 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296491B2A25 for ; Wed, 17 Jun 2015 09:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 86mjl-Lkojku for ; Wed, 17 Jun 2015 09:27:01 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEC151AD379 for ; Wed, 17 Jun 2015 09:26:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id CA906D930B for ; Wed, 17 Jun 2015 18:26:54 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ow33qL2HjHHS for ; Wed, 17 Jun 2015 18:26:54 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 9C45AD9309 for ; Wed, 17 Jun 2015 18:26:54 +0200 (MEST) Message-ID: <55819FCE.2020507@tik.ee.ethz.ch> Date: Wed, 17 Jun 2015 18:26:54 +0200 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "tcpm@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tcpm] AccECN Linux patch X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 16:27:04 -0000 Hi all, a quick announcement: I've put a first AccECN Linux patch on my webpage as described in draft-kuehlewind-tcpm-accurate-ecn. http://mirja.kuehlewind.net/code.html#accecn This does not implement the full specification of the draft (yet) but the basic handling of the ACE field. Further this Linux patch does not change the Linux DCTCP implementation. AccECN can be used with this patch by setting the existing ECN sysctl (net.ipv4.tcp_ecn) to 4 (this is also not documented in Linux sysctl documentation yet). Mirja From nobody Wed Jun 17 23:59:52 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844F71A0104; Wed, 17 Jun 2015 23:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 31MZW3Low6DK; Wed, 17 Jun 2015 23:59:47 -0700 (PDT) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331AD1B3060; Wed, 17 Jun 2015 23:59:46 -0700 (PDT) X-Spam-Processed: mail.kau.se, Thu, 18 Jun 2015 08:59:37 +0200 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 130.243.29.53 X-MDHelo: nod050.wlanp.kau.se X-MDArrival-Date: Thu, 18 Jun 2015 08:59:37 +0200 X-Authenticated-Sender: per.hurtig@kau.se X-Return-Path: per.hurtig@kau.se X-Envelope-From: per.hurtig@kau.se Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_48A4FE79-D605-4292-95B1-77E6D6DA92BB"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5 From: Per Hurtig In-Reply-To: Date: Thu, 18 Jun 2015 08:59:31 +0200 Message-Id: References: <882B8BE8-D02D-4E46-90B0-FE9CB2E88BF9@telecom-bretagne.eu> <655C07320163294895BBADA28372AF5D483AF02D@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: Karen Elisabeth Egede Nielsen X-Mailer: Apple Mail (2.2098) Archived-At: Cc: tcpm@ietf.org, tsvwg , Michael Welzl , apetlund@simula.no Subject: Re: [tcpm] draft-ietf-tcpm-rtorestart-07 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 06:59:50 -0000 --Apple-Mail=_48A4FE79-D605-4292-95B1-77E6D6DA92BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Karen, We agree that SCTP seems forgotten in the document. We have now = re-writen the introduction to address both TCP and SCTP. We also end the = introduction saying that the rest of the document will focus on TCP, = with an exception for Section 7 (the SCTP API). If we were to describe = RTOR for TCP and SCTP without violating any terminology (for any of the = protocols) we believe that the document would be unnecessarily long and = very hard to read. Cheers, Per > On 01 Jun 2015, at 11:15, Karen Elisabeth Egede Nielsen = wrote: >=20 > Hi, >=20 > Please accept the following - overdue - comments: >=20 > General comments on SCTP applicability of the specification: > = --------------------------------------------------------------------------= ---- >=20 > The document is inconsistent in its description of the SCTP aspects > of the proposed algorithm. >=20 > Section 1 and general: >=20 > The document does say, in the end of Section 1, that the focus of the > document is on TCP "with validity also for SCTP". > However if so, then I think this paragraph should have been the first > paragraph in section 1 rather than the last. > I think that it is confusing that the Abstract (and the title) speaks = about > TCP and SCTP, but the introduction text speaks about TCP only. >=20 > I think that it would be better for the text of section 1 to be = augmented to > speak about TCP _&_ SCTP. With the final paragraph > then telling that in the remaining part of the documents, the focus = would be > on TCP (if this is the intend). >=20 > (We have the SCTP API section in the end. Not sure how this fits with = the > notion of only providing details for TCP) >=20 > Alternatively, if the present "TCP only" introduction is kept, I think = that > it would be relevant to emphasize in the final paragraph of section 1, = that > what has been described above in section 1, is common to TCP and SCTP > (except possibly for the exact word "dupacks" - but I think one could = get > around that). >=20 > Still even with the above clarifications, it is unclear to me what the > status of this document is vis-a-vis SCTP. The detailed SCTP socket = API > description is there, > but some of the crucial implementation aspects - e.g. section 5.3., is = TCP > only. >=20 > But perhaps such inconsistency is ok for experimental ? >=20 > Section 3: >=20 > The contents of this section is common to TCP and SCTP except for the = term > segment which is TCP particular and which would be a packet in SCTP. >=20 > Section 4: >=20 > Here there is a reference to "similar update to RFC4960", but at the = same > time the word segment is used and further the section 5.3. discussion = is > TCP only. >=20 >=20 > Detailed on Section 7: > --------------------------- > As far as I can tell this is exactly what we would like to have for = SCTP. >=20 >=20 > Thanks, >=20 > BR, Karen >=20 > PS: It turns out that some SCTP implementations may send two packets = right > after RTO thus applying the "allowed to breach CWND with PMTU-1" logic = also > immediately following RTO-timeout. This has impact of how delay_ack = impacts > the loss recovery time (refer to discussion in section 5.1). I = believe that > the intent is to have this eventually be clarified to be incompliant > behavior (also of SCTP), but SCTP then of course has the option to ask = for > immediate SACK in this situation, which then again changes the impact = of > delay_ack. There also exist SCTP implementations which rigorously = follows > TCP semantics and which thus do not breach the CWND right after RTO = (only > after receipt of first ACK after RTO) and which today does not deploy = the > Immediate SACK extension. For such the delay_ack impact is the RTO = loss > recovery as for TCP. The latter behavior is the right RFC4960 = implementation > (at least I would argue that), but possibly not the "right" future = SCTP > implementation. >=20 >=20 >> -----Original Message----- >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, = Michael >> (Michael) >> Sent: Monday, May 18, 2015 11:22 AM >> To: per.hurtig@kau.se; anna.brunstrom@kau.se; apetlund@simula.no; >> michawe@ifi.uio.no >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] draft-ietf-tcpm-rtorestart-07 >>=20 >> Authors, >>=20 >> These (mostly editorial) comments are the only WGLC comments for = draft- >> ietf-tcpm-rtorestart-07 that I am aware of. Could you please discuss = how to >> address them? >>=20 >> Thanks >>=20 >> Michael >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Nicolas Kuhn >>> Sent: Thursday, May 07, 2015 5:00 PM >>> To: tcpm@ietf.org >>> Subject: [tcpm] draft-ietf-tcpm-rtorestart-07 >>>=20 >>> Hi all, >>>=20 >>> I had a look at this draft-ietf-tcpm-rtorestart-07 draft. >>> I have some minor comments on the document. >>>=20 >>>=20 >> ########################################################### >> ## >>>=20 >>> - "The RTO Restart (RTOR) mechanism described in this document makes >>> the >>> RTO slightly more aggressive when the number of outstanding = segments >>> is too small for fast retransmit to work, in an attempt to enable >>> faster loss recovery for all segments while being robust to >>> reordering." >>>=20 >>> The RTO is not aggressive ; but the retransmission scheme ruled by = RTO >>> expirations is. >>> I would recommend to rephrase that. >>>=20 >>>=20 >> ########################################################### >> ## >>>=20 >>> - =E2=80=9C The RTO Restart (RTOR) mechanism described in this = document makes >>> the >>> RTO slightly [=E2=80=A6] highly varying RTTs, e.g. mobile = networks." >>>=20 >>> This whole paragraph comes to early in the document, as the reader = has >>> no clear idea about what RTOR is actually doing. I propose to add = that >>> in a dedicated sub- section in Section 5. >>>=20 >>>=20 >> ########################################################### >> ## >>>=20 >>> - =E2=80=9C 3 RTO Restart Overview=E2=80=9D -> should it not be = =E2=80=9C3- RTO Overview and >>> rationale of RTOR =E2=80=9C or something equivalent ? >>> It is confusing, as you do not actually present RTOR. >>>=20 >>> Also, in this section 3: >>> The first paragraph finishes with =E2=80=9CHence, in most = situations, the >>> time before a retransmission is triggered is equal to "RTO + = RTT=E2=80=9D.=E2=80=9D >>> But the example to illustrate it comes after - I think things should >>> moved around to: >>> 1- introduce the classic RTO >>> 2- explain the rationale of classic RTO >>> 3- example to show that RTO+RTT is common >>> 4- more parameters could affect that (2 outstanding segments; other >>> factors) >>> 5- conclusion on =E2=80=9Chence, RTO+RTT is common for application = limited >>> traffic" >>>=20 >>> I would propose to introduce a ToC for this section 3: >>>=20 >>> 3- RTO Overview and rationale of RTOR >>> 3-1. Experienced RTO is RTO+RTT >>> 3-2. RTO safety margin >>> 3-3. Rationale of RTOR: when fast retransmit is not possible >>>=20 >>>=20 >> ########################################################### >> ## >>>=20 >>> Section 4 : should focus on the description of the algorithm only. >>>=20 >>> I would keep >>> =E2=80=9C >>> This approach makes the RTO more >>> aggressive than the standardized approach in [RFC6298] but still >>> conforms to the requirement in [RFC6298] that segments must not be >>> retransmitted earlier than RTO seconds after their original >>> transmission. >>> " >>>=20 >>> for the discussion section (at this stage of the reading, the reader >>> still does not know exactly what RTOR is actually doing). >>>=20 >>>=20 >> ########################################################### >> ## >>>=20 >>> Section 4: "it will prevent RTOR >>> from being more aggressive and potentially causing RTOs instead of >>> fast retransmits.=E2=80=9D >>>=20 >>> More aggressive than what ? Has the "four" being experimentally >>> obtained ? >>> I think more discussion is required on this parameter. >>>=20 >>> Regards, >>>=20 >>> Nicolas >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_48A4FE79-D605-4292-95B1-77E6D6DA92BB 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----- iQEcBAEBCAAGBQJVgmxYAAoJEMzXVkqMT/z2t/cH/AsqfNBXT7Zk3CNfFehAU5bw ni9Mh3gvvhW0U4w2s8IddJ0aqHhSrAbPm6t7AgPrUJUSbcAC/jQ+e5Ts0lglT4tn Tjcl0twW4bSGs82T0xV/DgxE+82b99qGlTg/lj4btqYD92yVULtIzEzPpwPIvM9u YvpCKcj5qaBlXrqDTJm0MRUJi9AJliWguxWHf1z78Boo5y7zWdcFKAT75X8HIIJE ni+zlorOrUA3yKwhgaDNUw5iMqBRb6ImQ2N1JUBkoddMWB00bzvi1oOfNq8t/lxq GpzgeCrimdzi1vsIFtdocpLFlgLnJ/gKhIWrjafTMsOj5oAQbR3PSlbUuGK7inw= =2+bH -----END PGP SIGNATURE----- --Apple-Mail=_48A4FE79-D605-4292-95B1-77E6D6DA92BB-- From nobody Thu Jun 18 00:05:13 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C081A002C; Thu, 18 Jun 2015 00:05:10 -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 nF79jpl7lHUw; Thu, 18 Jun 2015 00:05:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 495791A0023; Thu, 18 Jun 2015 00:05:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150618070508.25994.92595.idtracker@ietfa.amsl.com> Date: Thu, 18 Jun 2015 00:05:08 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-08.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 07:05:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP and SCTP RTO Restart Authors : Per Hurtig Anna Brunstrom Andreas Petlund Michael Welzl Filename : draft-ietf-tcpm-rtorestart-08.txt Pages : 16 Date : 2015-06-18 Abstract: This document describes a modified sender-side algorithm for managing the TCP and SCTP retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer so that the effective RTO becomes more aggressive in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short-lived or application-limited. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rtorestart-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 18 00:13:52 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E2E1A0117; Thu, 18 Jun 2015 00:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 TdQsMtHgWiOu; Thu, 18 Jun 2015 00:13:49 -0700 (PDT) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03EE81A00DD; Thu, 18 Jun 2015 00:13:48 -0700 (PDT) X-Spam-Processed: mail.kau.se, Thu, 18 Jun 2015 09:13:45 +0200 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 130.243.29.53 X-MDHelo: nod050.wlanp.kau.se X-MDArrival-Date: Thu, 18 Jun 2015 09:13:45 +0200 X-Authenticated-Sender: per.hurtig@kau.se X-Return-Path: per.hurtig@kau.se X-Envelope-From: per.hurtig@kau.se Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_59759146-9ED7-4A5A-8509-667685726131"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5 From: Per Hurtig In-Reply-To: <20150618070508.25994.92595.idtracker@ietfa.amsl.com> Date: Thu, 18 Jun 2015 09:13:39 +0200 Message-Id: References: <20150618070508.25994.92595.idtracker@ietfa.amsl.com> To: "tcpm@ietf.org Extensions" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: tcpm-chairs@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-08.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 07:13:51 -0000 --Apple-Mail=_59759146-9ED7-4A5A-8509-667685726131 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, we=E2=80=99ve now addressed all the comments we=E2=80=99ve received = during WGLC, including: * Clarified, at multiple places in the document, that the modification = only causes the effective RTO to be more aggressive, not the actual RTO. * Removed information in the introduction that was too detailed, i.e., material that is hard to understand without knowing details of the algorithm. * Changed the name of Section 3 to more correctly capture the actual contents of the section. * Re-arranged the text in Section 3 to have a more logical structure. * Moved text from the algorithm description (Section 4) to the introduction of the discussion section (Section 5). The text was discussing the possible effects of the algorithm more than describing the actual algorithm. * Clarified why the RECOMMENDED value of rrthresh is four. * Reworked the introduction to be suitable for both TCP and SCTP. Cheers, Per > On 18 Jun 2015, at 09:05, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the TCP Maintenance and Minor Extensions = Working Group of the IETF. >=20 > Title : TCP and SCTP RTO Restart > Authors : Per Hurtig > Anna Brunstrom > Andreas Petlund > Michael Welzl > Filename : draft-ietf-tcpm-rtorestart-08.txt > Pages : 16 > Date : 2015-06-18 >=20 > Abstract: > This document describes a modified sender-side algorithm for = managing > the TCP and SCTP retransmission timers that provides faster loss > recovery when there is a small amount of outstanding data for a > connection. The modification, RTO Restart (RTOR), allows the > transport to restart its retransmission timer so that the effective > RTO becomes more aggressive in situations where fast retransmit > cannot be used. This enables faster loss detection and recovery for > connections that are short-lived or application-limited. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rtorestart-08 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_59759146-9ED7-4A5A-8509-667685726131 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----- iQEcBAEBCAAGBQJVgm+oAAoJEMzXVkqMT/z2Qf0IAKEXaZSK8xMJnFvoO63RaUSV k7naL9hUpKseVoFMp8IMmCP/H1cB3aHwr44Km+z38Q6YZuXA3W+/wOG+FPUz4vgy 8EYhyq9xjWrkj+rQjqUlGu5xQQVOJdWN8BYeCwdhzwjyq0yEcQHKdJU2X7ESOzj7 BHEduHSU1wlWiPd48PWSm/4IizyI0J1Voev/nN3bDzQktllOv9AmLKCGO2o28Zwb 6G99Ho+ioyur/n3QL8FnGu32O6QOQFfUlSyR6vqcpjMpghGxci9+Wp/kQ/t1mCeg WIu15XyFiWu6mlLSzqjmKbai5+dW/f96fdnwOjFXoK2+939BLQil0Gx4fQlx6V4= =BSNG -----END PGP SIGNATURE----- --Apple-Mail=_59759146-9ED7-4A5A-8509-667685726131-- From nobody Thu Jun 18 00:29:06 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DA21A07BC for ; Thu, 18 Jun 2015 00:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] 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 RuJgoXLdFw3l for ; Thu, 18 Jun 2015 00:29:02 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1C61A06E9 for ; Thu, 18 Jun 2015 00:29:01 -0700 (PDT) Received: by igbqq3 with SMTP id qq3so8706810igb.0 for ; Thu, 18 Jun 2015 00:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=i7CQDQ6UVGldvY7wWxspjRNlr5sMMJkDafNGk/AddRU=; b=K/DVSW62ffGiOQyxtp1RWxBfXDE81yc3fgOKatmkcdGEbnaZ8hG2IfrDqYafVEkfrB aWhWaRwnjxZ9FO6XRNruYA5abnP+hLp187ysKYvywnnZD+l8nIbGfJw8+47GFjzn9yBN y1WmGO+BIGhsVGZJugDps1r9jF6LajIl7ZcAU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=i7CQDQ6UVGldvY7wWxspjRNlr5sMMJkDafNGk/AddRU=; b=bl5vxQJQC0Fom6IyS0Ap2ZhQZSoLzvFMpwkyjkkLTO168qA+yRvVS4Gp27G9mnZxME SnlnwDTC1N1JIiPhN6eB3tF9i6xf9Hx31M7WvaXZk9Ip4Wpp3mi6VLaJrVyHmQp77heW pExRal4tC4aE/H9ku6UlVY26dOHJqpm+1sONiXUgsOtvUWVsN36a9dYPwIRttR4Gog9i MbmvW9VdtJ1RX3Br7AonCtVDbQ4FbQV/Ozx/Bc7W7jzJGDKjIVNlu7fYeGIQ4iNb1S+M aYCx/uVZm8Tkoliw5nQX/1PpMsm/L3ngISg/bdn3v3zgv34xEI4rQekDsrrvcXdUry2w mzuQ== X-Gm-Message-State: ALoCoQm3e1Pb/LvgDWuOiZKASzHzrvyCXiXW0wzazBe5pRXKRvVIkNKa6ZQQ+tPrufr4gf0Wi6SwKM3ZYGlpqa6oSH8Jn7LLYT6lOIu1tzKoqw5tAGGpqNc= X-Received: by 10.107.46.226 with SMTP id u95mr12360326iou.68.1434612541375; Thu, 18 Jun 2015 00:29:01 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <882B8BE8-D02D-4E46-90B0-FE9CB2E88BF9@telecom-bretagne.eu> <655C07320163294895BBADA28372AF5D483AF02D@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL7VJwomcXY3mf3wZzSms+lgcAi+gFhiVv/AYKNx7sB3lM3Sps2cpMg Date: Thu, 18 Jun 2015 09:29:00 +0200 Message-ID: <64074bfb5bd45b8b1052f032f07f202e@mail.gmail.com> To: Per Hurtig Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: Cc: tcpm@ietf.org, tsvwg , Michael Welzl , apetlund@simula.no Subject: Re: [tcpm] [tsvwg] draft-ietf-tcpm-rtorestart-07 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 07:29:05 -0000 Hi, Thanks for taking my comments into consideration ! I think the described approach with a common TCP&SCTP introduction sounds good and given that I agree that it is viable to leave the SCTP details out. BR, Karen >-----Original Message----- >From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Per Hurtig >Sent: Thursday, June 18, 2015 9:00 AM >To: Karen Elisabeth Egede Nielsen >Cc: tcpm@ietf.org; Scharf, Michael (Michael); tsvwg; Michael Welzl; >apetlund@simula.no >Subject: Re: [tsvwg] [tcpm] draft-ietf-tcpm-rtorestart-07 > >Hi Karen, > >We agree that SCTP seems forgotten in the document. We have now re- >writen the introduction to address both TCP and SCTP. We also end the >introduction saying that the rest of the document will focus on TCP, with >an >exception for Section 7 (the SCTP API). If we were to describe RTOR for TC= P >and SCTP without violating any terminology (for any of the protocols) we >believe that the document would be unnecessarily long and very hard to >read. > > >Cheers, >Per > >> On 01 Jun 2015, at 11:15, Karen Elisabeth Egede Nielsen > wrote: >> >> Hi, >> >> Please accept the following - overdue - comments: >> >> General comments on SCTP applicability of the specification: >> ---------------------------------------------------------------------- >> -------- >> >> The document is inconsistent in its description of the SCTP aspects of >> the proposed algorithm. >> >> Section 1 and general: >> >> The document does say, in the end of Section 1, that the focus of the >> document is on TCP "with validity also for SCTP". >> However if so, then I think this paragraph should have been the first >> paragraph in section 1 rather than the last. >> I think that it is confusing that the Abstract (and the title) speaks >> about TCP and SCTP, but the introduction text speaks about TCP only. >> >> I think that it would be better for the text of section 1 to be >> augmented to speak about TCP _&_ SCTP. With the final paragraph then >> telling that in the remaining part of the documents, the focus would >> be on TCP (if this is the intend). >> >> (We have the SCTP API section in the end. Not sure how this fits with >> the notion of only providing details for TCP) >> >> Alternatively, if the present "TCP only" introduction is kept, I think >> that it would be relevant to emphasize in the final paragraph of >> section 1, that what has been described above in section 1, is common >> to TCP and SCTP (except possibly for the exact word "dupacks" - but I >> think one could get around that). >> >> Still even with the above clarifications, it is unclear to me what the >> status of this document is vis-a-vis SCTP. The detailed SCTP socket >> API description is there, but some of the crucial implementation >> aspects - e.g. section 5.3., is TCP only. >> >> But perhaps such inconsistency is ok for experimental ? >> >> Section 3: >> >> The contents of this section is common to TCP and SCTP except for the >> term segment which is TCP particular and which would be a packet in SCTP= . >> >> Section 4: >> >> Here there is a reference to "similar update to RFC4960", but at the >> same time the word segment is used and further the section 5.3. >> discussion is TCP only. >> >> >> Detailed on Section 7: >> --------------------------- >> As far as I can tell this is exactly what we would like to have for SCTP= . >> >> >> Thanks, >> >> BR, Karen >> >> PS: It turns out that some SCTP implementations may send two packets >> right after RTO thus applying the "allowed to breach CWND with PMTU-1" >> logic also immediately following RTO-timeout. This has impact of how >> delay_ack impacts the loss recovery time (refer to discussion in >> section 5.1). I believe that the intent is to have this eventually >> be clarified to be incompliant behavior (also of SCTP), but SCTP then >> of course has the option to ask for immediate SACK in this situation, >> which then again changes the impact of delay_ack. There also exist >> SCTP implementations which rigorously follows TCP semantics and which >> thus do not breach the CWND right after RTO (only after receipt of >> first ACK after RTO) and which today does not deploy the Immediate >> SACK extension. For such the delay_ack impact is the RTO loss recovery >> as for TCP. The latter behavior is the right RFC4960 implementation >> (at least I would argue that), but possibly not the "right" future SCTP >implementation. >> >> >>> -----Original Message----- >>> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, >>> Michael >>> (Michael) >>> Sent: Monday, May 18, 2015 11:22 AM >>> To: per.hurtig@kau.se; anna.brunstrom@kau.se; apetlund@simula.no; >>> michawe@ifi.uio.no >>> Cc: tcpm@ietf.org >>> Subject: Re: [tcpm] draft-ietf-tcpm-rtorestart-07 >>> >>> Authors, >>> >>> These (mostly editorial) comments are the only WGLC comments for >>> draft- >>> ietf-tcpm-rtorestart-07 that I am aware of. Could you please discuss >>> how to address them? >>> >>> Thanks >>> >>> Michael >>> >>> >>> >>>> -----Original Message----- >>>> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Nicolas Kuhn >>>> Sent: Thursday, May 07, 2015 5:00 PM >>>> To: tcpm@ietf.org >>>> Subject: [tcpm] draft-ietf-tcpm-rtorestart-07 >>>> >>>> Hi all, >>>> >>>> I had a look at this draft-ietf-tcpm-rtorestart-07 draft. >>>> I have some minor comments on the document. >>>> >>>> >>> >########################################################### >>> ## >>>> >>>> - "The RTO Restart (RTOR) mechanism described in this document makes >>>> the >>>> RTO slightly more aggressive when the number of outstanding segments >>>> is too small for fast retransmit to work, in an attempt to enable >>>> faster loss recovery for all segments while being robust to >>>> reordering." >>>> >>>> The RTO is not aggressive ; but the retransmission scheme ruled by >>>> RTO expirations is. >>>> I would recommend to rephrase that. >>>> >>>> >>> >########################################################### >>> ## >>>> >>>> - =E2=80=9C The RTO Restart (RTOR) mechanism described in this docum= ent >makes >>>> the >>>> RTO slightly [=E2=80=A6] highly varying RTTs, e.g. mobile networks." >>>> >>>> This whole paragraph comes to early in the document, as the reader >>>> has no clear idea about what RTOR is actually doing. I propose to >>>> add that in a dedicated sub- section in Section 5. >>>> >>>> >>> >########################################################### >>> ## >>>> >>>> - =E2=80=9C 3 RTO Restart Overview=E2=80=9D -> should it not be =E2=80= =9C3- RTO Overview and >>>> rationale of RTOR =E2=80=9C or something equivalent ? >>>> It is confusing, as you do not actually present RTOR. >>>> >>>> Also, in this section 3: >>>> The first paragraph finishes with =E2=80=9CHence, in most situations,= the >>>> time before a retransmission is triggered is equal to "RTO + RTT=E2=80= =9D.=E2=80=9D >>>> But the example to illustrate it comes after - I think things should >>>> moved around to: >>>> 1- introduce the classic RTO >>>> 2- explain the rationale of classic RTO >>>> 3- example to show that RTO+RTT is common >>>> 4- more parameters could affect that (2 outstanding segments; other >>>> factors) >>>> 5- conclusion on =E2=80=9Chence, RTO+RTT is common for application lim= ited >>>> traffic" >>>> >>>> I would propose to introduce a ToC for this section 3: >>>> >>>> 3- RTO Overview and rationale of RTOR 3-1. Experienced RTO is >>>> RTO+RTT 3-2. RTO safety margin 3-3. Rationale of RTOR: when fast >>>> retransmit is not possible >>>> >>>> >>> >########################################################### >>> ## >>>> >>>> Section 4 : should focus on the description of the algorithm only. >>>> >>>> I would keep >>>> =E2=80=9C >>>> This approach makes the RTO more >>>> aggressive than the standardized approach in [RFC6298] but still >>>> conforms to the requirement in [RFC6298] that segments must not be >>>> retransmitted earlier than RTO seconds after their original >>>> transmission. >>>> " >>>> >>>> for the discussion section (at this stage of the reading, the reader >>>> still does not know exactly what RTOR is actually doing). >>>> >>>> >>> >########################################################### >>> ## >>>> >>>> Section 4: "it will prevent RTOR >>>> from being more aggressive and potentially causing RTOs instead of >>>> fast retransmits.=E2=80=9D >>>> >>>> More aggressive than what ? Has the "four" being experimentally >>>> obtained ? >>>> I think more discussion is required on this parameter. >>>> >>>> Regards, >>>> >>>> Nicolas >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Jun 18 06:31:48 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0AD1A9009 for ; Thu, 18 Jun 2015 06:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 SV2AJpJX3m0V for ; Thu, 18 Jun 2015 06:31:37 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7669D1A8F4B for ; Thu, 18 Jun 2015 06:31:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id F202AD9309; Thu, 18 Jun 2015 15:31:35 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lDPMwzR1d9nL; Thu, 18 Jun 2015 15:31:35 +0200 (MEST) Received: from [192.168.178.33] (x5f700897.dyn.telefonica.de [95.112.8.151]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 016F7D930B; Thu, 18 Jun 2015 15:31:34 +0200 (MEST) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jun 2015 15:31:33 +0200 Message-Id: <031D67EB-0676-4398-B5DF-E2F73D174E58@tik.ee.ethz.ch> To: "Eggert, Lars" , Dave Thaler , sbens@microsoft.com Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] Review of draft-bensley-tcpm-dctcp-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 13:31:47 -0000 Hi all, as I think draft-bensley-tcpm-dctcp should be an tcpm working group = document and because I=E2=80=99m interested in DCTCP, I=E2=80=99ve = reviewed this document. This draft documents DCTCP as implemented in = Microsoft and is very-well written and easy to understand, therefore I = think if adopted by tcpm is can be processed quickly. I have two comments which I would like to see addressed; and a few more = smaller comments which might help to even further improve the document = and might be addressed or not: 1) I would like to see the point that DCTP is *only* indented to be used = in data center made more strongly and explicit in this document by = adding one more small paragraph in the intro or even one more sentence = in the abstract. There are two reason why I think this is very important = to say more explicitly: a) there is no negotiation that detects if DCTCP = is also implemented by the other end (this is mainly important for the = ECN feedback). And b) if DCTP is used in parallel to =E2=80=9Atraditional=E2= =80=98 (maybe even loss-based) congestion control, it will starve this = competing traffic; I don=E2=80=99t think this point is mentioned = anywhere but probably should, at least very briefly. 2) This document does not describe what the Microsoft implementation = does if loss is detected. I think normally the assumption is that there = should be no (congestion-based) loss anymore in a data center where all = traffic is using DCTCP. However, the draft should still say what to do = if loss occurs. If I remember correctly the Linux implementation has a = configuration parameter to decide if a loss should be ignored or the = window should be halved. Maybe you can again clarify with Daniel = Borkmann who implemented this in Linux; I know he has read the draft and = is probably willing to review again or even provide some text on this if = needed. Other minor comments: 1) I would like to see mentioned in the abstract as well as in the intro = that the gain in lower latency is achieved by using a very low marking = threshold of the AQM. This document is written to mainly describe only = the endpoint changes and seem to suggest that DCTCP could work with any = ECN-enabled AQM. That might be true or not; at least I have not seems = any evaluation results where different AQM schemes are used. I = personally would prefer to describe DCTCP as a whole system that = implements a certain congestion control scheme (and ECN feedback) as = well as assumes a specific parameterization in the bottleneck=E2=80=99s = AQM. I don=E2=80=99t think that=E2=80=99s a problem to describe it that = way, because DCTCP is clear only intended to be used in data centers = where all endpoint and network nodes are under the control of one = entity. Actually it should even be mentioned that the proposed = parameterization can easily be configured with all switches that = implement RED.=20 2) The second point goes in the same direction: section 3.1 says: "However, the actual algorithm for marking congestion is an implementation detail of the switch and will generally not be known to the sender and receiver. Therefore, sender and receiver MUST NOT assume that a particular marking algorithm is implemented by the switching fabric.=E2=80=9C First of all, this informational document should not use normative = language here. And second, if DCTCP is used and tested by Microsoft only = with a certain configuration, I would remove this sentence and write = rather something like: =E2=80=9EEven though the actual algorithm for marking congestion is an implementation detail of the switch and will generally not be known to the sender and receive,=20 DCTCP has been design and evaluated to be used with the configuration = describe above.=E2=80=9C 3) First paragraph in the intro says that the problem with low cost = switches is high loss. I actually though that the problem with the = standard config of low cost switches is high delay because there is too = much buffering=E2=80=A6 can you comment on this? 4) Second paragraph says "worker nodes complete at approximately the = same time=E2=80=9C. I thought that they would even complete at exactly = the same time because they often have a timeout..? Can you comment here = as well? Maybe also refer the DCTCP paper here because it contains a = good analysis of incast. 5) Paragraph on ECN in the intro says "In the presence of mild congestion, it reduces the TCP congestion = window too aggressively=E2=80=A6" =E2=80=9AIt=E2=80=98 refers here to the ECN mechanism of rfc3168. = However, the congestion control reduces the window. Therefore the = sentence should rather be: "In the presence of mild congestion, traditional TCP congestion control = reduces the TCP congestion window too aggressively=E2=80=A6=E2=80=9C 6) Abstract and intro both say =E2=80=9EDCTCP enhances ECN=E2=80=A6=E2=80=9C= ; I really don=E2=80=99t think =E2=80=9Aenhance' can be used here so = generally; if the congestion control only needs one feedback signal per = RTT, there is no enhancement. Maybe say =E2=80=9Achange=E2=80=98 or = =E2=80=9Aimproves the accuracy of the ECN feedback signal by signal not = only the occurrence of congestion but also its extend=E2=80=98=E2=80=A6 = or something like this. 7) As also mentioned above, I think the intro should say that the more = aggressive congestion control of DCTCP should not be used in parallel = with traditional congestion as it will starve this traffic. 8) I=E2=80=99d like to propose to use the list given in section 3 not = only to say which elements are =E2=80=9Ainvolved=E2=80=98 but also very = briefly say what was =E2=80=9Amodified=E2=80=98, e.g. "There are three components that needs to be modified to use DCTCP: o The switch (or other intermediate device on the network) detects congestion and sets the Congestion Experienced (CE) codepoint in the IP header already when a very short queue builds up.=20 o The receiver echoes each occurrence of a the Congestion = Experienced (CE) mark back to the sender using the ECN-Echo (ECE) flag in the TCP = header. o The sender reacts to the congestion indication by reducing the TCP congestion window (cwnd) based on the extend of congestion = experienced in the last RTT.=E2=80=9C I think this given a nice high-level overview and helps the reader to = easier understand the rest. 9) Maybe add to section 3.2 the state machine image as provided in the = paper. I personally would, in an RFC, also describe the algo first and = then give the reasoning but that=E2=80=99s a matter of which style is = preferred=E2=80=A6 10) Section 3.3: Quick question: Why is the fraction of marked packets = called M in the draft while it=E2=80=99s F in the paper? 11) Again Section 3.3: Maybe mention somewhere that the SACK information = are not used to calculate BytesAcked because usually it=E2=80=99s = assumed to have no loss with the use of DCTCP. However, I guess if a = calculation as given in RFC6937 (PRR) for DeliveredData is used, that is = probably okay as well and should not be a problem, right? 12) Further section 3.3 says "when the sender receives an indication of = congestion=E2=80=9C. Can you maybe be a little more specify here and say = =E2=80=9Eif the first ECE is received in a RTT=E2=80=9C or something = like this. Please also note that this behavior will reduce the = congestion window when the marking fraction is low because if will = reduce with the first occurrence of ECE and all other ECE markings will = occur in the following RTT where the window is not further reduced. = Therefore the window will only really be reduced if the congestion stays = for more than on RTT (that delays the reaction to congestion a little). = That=E2=80=99s okay because this allows to not react to short-bursts of = congestion. However, I think this should be mentioned/discussed as it = might not be obvious when reading the draft. 13) Next sentence is=20 "Thus, when no sent byte experienced congestion, DCTCP.Alpha equals zero, and cwnd is left unchanged.=E2=80=9C I think this sentence is nonsensical as the previous sentence says the = congestion window will only be reduces if congestion is signaled=E2=80=A6 14) As already mention, section 5 should also mention deployment = problems if used in parallel to traditional TCP congestion control. 15) Section 6 says: "However, if an ACK packet is dropped, it's possible that a subsequent ACK will indeed acknowledge a mix of CE and non-CE segments.=E2=80=9C Either I don=E2=80=99t understand this sentence or it is not true. To my = understanding an ACK is either ECE set or not and therefore might ack CE = marks or not. However if e.g. only one ACK is ECE marked and this ack = gets lost, the following non-ECE marked ACK will accumulatively ack all = packets as not-CE marked and this information is completely lost. Thanks again for writing this document. I hope it can be published soon! Mirja From nobody Thu Jun 18 06:42:20 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390591A8FD2 for ; Thu, 18 Jun 2015 06:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 bv7pf3zH7l3Z for ; Thu, 18 Jun 2015 06:42:12 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995CE1A8F44 for ; Thu, 18 Jun 2015 06:42:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5207CD930C; Thu, 18 Jun 2015 15:42:11 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ygrX7sTLuBuZ; Thu, 18 Jun 2015 15:42:11 +0200 (MEST) Received: from [192.168.178.33] (x5f700897.dyn.telefonica.de [95.112.8.151]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id AD6FAD9309; Thu, 18 Jun 2015 15:42:10 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <031D67EB-0676-4398-B5DF-E2F73D174E58@tik.ee.ethz.ch> Date: Thu, 18 Jun 2015 15:42:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <031D67EB-0676-4398-B5DF-E2F73D174E58@tik.ee.ethz.ch> To: "Eggert, Lars" , Dave Thaler , sbens@microsoft.com X-Mailer: Apple Mail (2.2098) Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] Review of draft-bensley-tcpm-dctcp-03 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 13:42:19 -0000 One more quick point, an analysis of the problem of the used ECN = feedback scheme of DCTCP is also given in the AccECN requirements draft = (soon RFC7560) which maybe could be referred here. Mirja > Am 18.06.2015 um 15:31 schrieb Mirja K=C3=BChlewind = : >=20 > Hi all, >=20 > as I think draft-bensley-tcpm-dctcp should be an tcpm working group = document and because I=E2=80=99m interested in DCTCP, I=E2=80=99ve = reviewed this document. This draft documents DCTCP as implemented in = Microsoft and is very-well written and easy to understand, therefore I = think if adopted by tcpm is can be processed quickly. >=20 > I have two comments which I would like to see addressed; and a few = more smaller comments which might help to even further improve the = document and might be addressed or not: >=20 > 1) I would like to see the point that DCTP is *only* indented to be = used in data center made more strongly and explicit in this document by = adding one more small paragraph in the intro or even one more sentence = in the abstract. There are two reason why I think this is very important = to say more explicitly: a) there is no negotiation that detects if DCTCP = is also implemented by the other end (this is mainly important for the = ECN feedback). And b) if DCTP is used in parallel to =E2=80=9Atraditional=E2= =80=98 (maybe even loss-based) congestion control, it will starve this = competing traffic; I don=E2=80=99t think this point is mentioned = anywhere but probably should, at least very briefly. >=20 > 2) This document does not describe what the Microsoft implementation = does if loss is detected. I think normally the assumption is that there = should be no (congestion-based) loss anymore in a data center where all = traffic is using DCTCP. However, the draft should still say what to do = if loss occurs. If I remember correctly the Linux implementation has a = configuration parameter to decide if a loss should be ignored or the = window should be halved. Maybe you can again clarify with Daniel = Borkmann who implemented this in Linux; I know he has read the draft and = is probably willing to review again or even provide some text on this if = needed. >=20 > Other minor comments: >=20 > 1) I would like to see mentioned in the abstract as well as in the = intro that the gain in lower latency is achieved by using a very low = marking threshold of the AQM. This document is written to mainly = describe only the endpoint changes and seem to suggest that DCTCP could = work with any ECN-enabled AQM. That might be true or not; at least I = have not seems any evaluation results where different AQM schemes are = used. I personally would prefer to describe DCTCP as a whole system that = implements a certain congestion control scheme (and ECN feedback) as = well as assumes a specific parameterization in the bottleneck=E2=80=99s = AQM. I don=E2=80=99t think that=E2=80=99s a problem to describe it that = way, because DCTCP is clear only intended to be used in data centers = where all endpoint and network nodes are under the control of one = entity. Actually it should even be mentioned that the proposed = parameterization can easily be configured with all switches that = implement RED.=20 >=20 > 2) The second point goes in the same direction: section 3.1 says: > "However, the actual > algorithm for marking congestion is an implementation detail of the > switch and will generally not be known to the sender and receiver. > Therefore, sender and receiver MUST NOT assume that a particular > marking algorithm is implemented by the switching fabric.=E2=80=9C > First of all, this informational document should not use normative = language here. And second, if DCTCP is used and tested by Microsoft only = with a certain configuration, I would remove this sentence and write = rather something like: > =E2=80=9EEven though the actual > algorithm for marking congestion is an implementation detail of the > switch and will generally not be known to the sender and receive,=20 > DCTCP has been design and evaluated to be used with the = configuration describe above.=E2=80=9C >=20 > 3) First paragraph in the intro says that the problem with low cost = switches is high loss. I actually though that the problem with the = standard config of low cost switches is high delay because there is too = much buffering=E2=80=A6 can you comment on this? >=20 > 4) Second paragraph says "worker nodes complete at approximately the = same time=E2=80=9C. I thought that they would even complete at exactly = the same time because they often have a timeout..? Can you comment here = as well? Maybe also refer the DCTCP paper here because it contains a = good analysis of incast. >=20 > 5) Paragraph on ECN in the intro says > "In the presence of mild congestion, it reduces the TCP congestion = window too > aggressively=E2=80=A6" > =E2=80=9AIt=E2=80=98 refers here to the ECN mechanism of rfc3168. = However, the congestion control reduces the window. Therefore the = sentence should rather be: > "In the presence of mild congestion, traditional TCP congestion = control reduces the TCP congestion window too aggressively=E2=80=A6=E2=80=9C= >=20 > 6) Abstract and intro both say =E2=80=9EDCTCP enhances ECN=E2=80=A6=E2=80= =9C; I really don=E2=80=99t think =E2=80=9Aenhance' can be used here so = generally; if the congestion control only needs one feedback signal per = RTT, there is no enhancement. Maybe say =E2=80=9Achange=E2=80=98 or = =E2=80=9Aimproves the accuracy of the ECN feedback signal by signal not = only the occurrence of congestion but also its extend=E2=80=98=E2=80=A6 = or something like this. >=20 > 7) As also mentioned above, I think the intro should say that the more = aggressive congestion control of DCTCP should not be used in parallel = with traditional congestion as it will starve this traffic. >=20 > 8) I=E2=80=99d like to propose to use the list given in section 3 not = only to say which elements are =E2=80=9Ainvolved=E2=80=98 but also very = briefly say what was =E2=80=9Amodified=E2=80=98, e.g. >=20 > "There are three components that needs to be modified to use DCTCP: >=20 > o The switch (or other intermediate device on the network) detects > congestion and sets the Congestion Experienced (CE) codepoint in > the IP header already when a very short queue builds up.=20 >=20 > o The receiver echoes each occurrence of a the Congestion = Experienced (CE) mark > back to the sender using the ECN-Echo (ECE) flag in the TCP = header. >=20 > o The sender reacts to the congestion indication by reducing the = TCP > congestion window (cwnd) based on the extend of congestion = experienced in the last RTT.=E2=80=9C >=20 > I think this given a nice high-level overview and helps the reader to = easier understand the rest. >=20 > 9) Maybe add to section 3.2 the state machine image as provided in = the paper. I personally would, in an RFC, also describe the algo first = and then give the reasoning but that=E2=80=99s a matter of which style = is preferred=E2=80=A6 >=20 > 10) Section 3.3: Quick question: Why is the fraction of marked packets = called M in the draft while it=E2=80=99s F in the paper? >=20 > 11) Again Section 3.3: Maybe mention somewhere that the SACK = information are not used to calculate BytesAcked because usually it=E2=80=99= s assumed to have no loss with the use of DCTCP. However, I guess if a = calculation as given in RFC6937 (PRR) for DeliveredData is used, that is = probably okay as well and should not be a problem, right? >=20 > 12) Further section 3.3 says "when the sender receives an indication = of congestion=E2=80=9C. Can you maybe be a little more specify here and = say =E2=80=9Eif the first ECE is received in a RTT=E2=80=9C or something = like this. Please also note that this behavior will reduce the = congestion window when the marking fraction is low because if will = reduce with the first occurrence of ECE and all other ECE markings will = occur in the following RTT where the window is not further reduced. = Therefore the window will only really be reduced if the congestion stays = for more than on RTT (that delays the reaction to congestion a little). = That=E2=80=99s okay because this allows to not react to short-bursts of = congestion. However, I think this should be mentioned/discussed as it = might not be obvious when reading the draft. >=20 > 13) Next sentence is=20 > "Thus, when no sent byte experienced congestion, DCTCP.Alpha equals > zero, and cwnd is left unchanged.=E2=80=9C > I think this sentence is nonsensical as the previous sentence says the = congestion window will only be reduces if congestion is signaled=E2=80=A6 >=20 > 14) As already mention, section 5 should also mention deployment = problems if used in parallel to traditional TCP congestion control. >=20 > 15) Section 6 says: > "However, if an > ACK packet is dropped, it's possible that a subsequent ACK will > indeed acknowledge a mix of CE and non-CE segments.=E2=80=9C > Either I don=E2=80=99t understand this sentence or it is not true. To = my understanding an ACK is either ECE set or not and therefore might ack = CE marks or not. However if e.g. only one ACK is ECE marked and this ack = gets lost, the following non-ECE marked ACK will accumulatively ack all = packets as not-CE marked and this information is completely lost. >=20 > Thanks again for writing this document. I hope it can be published = soon! >=20 > Mirja >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Jun 18 12:24:23 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B8E1B340B; Thu, 18 Jun 2015 12:24:22 -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 UlL0DkcAx13U; Thu, 18 Jun 2015 12:24:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB98A1B33FD; Thu, 18 Jun 2015 12:24:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150618192420.26836.11116.idtracker@ietfa.amsl.com> Date: Thu, 18 Jun 2015 12:24:20 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-cubic-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 19:24:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : CUBIC for Fast Long-Distance Networks Authors : Injong Rhee Lisong Xu Sangtae Ha Alexander Zimmermann Lars Eggert Richard Scheffenegger Filename : draft-ietf-tcpm-cubic-00.txt Pages : 14 Date : 2015-06-18 Abstract: CUBIC is an extension to the current TCP standards. The protocol differs from the current TCP standards only in the congestion window adjustment function in the sender side. In particular, it uses a cubic function instead of a linear window increase of the current TCP standards to improve scalability and stability under fast and long distance networks. BIC-TCP, a predecessor of CUBIC, has been a default TCP adopted by Linux since year 2005 and has already been deployed globally and in use for several years by the Internet community at large. CUBIC is using a similar window growth function as BIC-TCP and is designed to be less aggressive and fairer to TCP in bandwidth usage than BIC-TCP while maintaining the strengths of BIC- TCP such as stability, window scalability and RTT fairness. Through extensive testing in various Internet scenarios, we believe that CUBIC is safe for deployment and testing in the global Internet. The intent of this document is to provide the protocol specification of CUBIC for a third party implementation and solicit the community feedback through experimentation on the performance of CUBIC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-cubic-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 18 12:26:44 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44B51B33FA for ; Thu, 18 Jun 2015 12:26:42 -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 e_s8los1sYkN for ; Thu, 18 Jun 2015 12:26:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CACF1B3409 for ; Thu, 18 Jun 2015 12:26:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150618192641.26836.44206.idtracker@ietfa.amsl.com> Date: Thu, 18 Jun 2015 12:26:41 -0700 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 19:26:43 -0000 Changed milestone "Submit document on CUBIC congestion control to the IESG for publication as Informational RFC", added draft-ietf-tcpm-cubic to milestone. URL: https://datatracker.ietf.org/wg/tcpm/charter/ From nobody Fri Jun 19 00:12:39 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228081A6FF8 for ; Fri, 19 Jun 2015 00:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 gi9xLSXVFHar for ; Fri, 19 Jun 2015 00:12:35 -0700 (PDT) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 380F81A6FF2 for ; Fri, 19 Jun 2015 00:12:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,643,1427785200"; d="asc'?scan'208";a="51082221" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx141-out.netapp.com with ESMTP; 19 Jun 2015 00:12:19 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 19 Jun 2015 00:12:18 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::559a:ad5b:4641:c02e%21]) with mapi id 15.00.1076.000; Fri, 19 Jun 2015 00:12:18 -0700 From: "Zimmermann, Alexander" To: "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-cubic-00.txt Thread-Index: AQHQqfx2EeFHDrLYNkWSBd6pwKv6Ap2z3+0A Date: Fri, 19 Jun 2015 07:12:18 +0000 Message-ID: References: <20150618192420.26836.11116.idtracker@ietfa.amsl.com> In-Reply-To: <20150618192420.26836.11116.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_001571A9-A673-426E-B482-8066C7768EC9"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-cubic-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 07:12:37 -0000 --Apple-Mail=_001571A9-A673-426E-B482-8066C7768EC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is just a resubmission of draft-zimmermann-tcpm-cubic-01 as WG = item. Received feedback will be addressed in upcoming versions Alex > Am 18.06.2015 um 21:24 schrieb internet-drafts@ietf.org: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the TCP Maintenance and Minor Extensions = Working Group of the IETF. >=20 > Title : CUBIC for Fast Long-Distance Networks > Authors : Injong Rhee > Lisong Xu > Sangtae Ha > Alexander Zimmermann > Lars Eggert > Richard Scheffenegger > Filename : draft-ietf-tcpm-cubic-00.txt > Pages : 14 > Date : 2015-06-18 >=20 > Abstract: > CUBIC is an extension to the current TCP standards. The protocol > differs from the current TCP standards only in the congestion window > adjustment function in the sender side. In particular, it uses a > cubic function instead of a linear window increase of the current = TCP > standards to improve scalability and stability under fast and long > distance networks. BIC-TCP, a predecessor of CUBIC, has been a > default TCP adopted by Linux since year 2005 and has already been > deployed globally and in use for several years by the Internet > community at large. CUBIC is using a similar window growth function > as BIC-TCP and is designed to be less aggressive and fairer to TCP = in > bandwidth usage than BIC-TCP while maintaining the strengths of BIC- > TCP such as stability, window scalability and RTT fairness. Through > extensive testing in various Internet scenarios, we believe that > CUBIC is safe for deployment and testing in the global Internet. = The > intent of this document is to provide the protocol specification of > CUBIC for a third party implementation and solicit the community > feedback through experimentation on the performance of CUBIC. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tcpm-cubic-00 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_001571A9-A673-426E-B482-8066C7768EC9 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 iEYEARECAAYFAlWDwNIACgkQdyiq39b9uS6d1wCeNuMQxqR2oPkqez2+1l8V/bTj HxsAn1/E/pAd+KwYGGKzj9Et2gr3r03U =2QoH -----END PGP SIGNATURE----- --Apple-Mail=_001571A9-A673-426E-B482-8066C7768EC9-- From nobody Mon Jun 22 02:23:24 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658E01B2E91 for ; Mon, 22 Jun 2015 02:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 cwNkGN66HPSQ for ; Mon, 22 Jun 2015 02:23:21 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 269CF1B2E90 for ; Mon, 22 Jun 2015 02:23:20 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-0a-5587d4065083 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 43.AF.04401.604D7855; Mon, 22 Jun 2015 11:23:19 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.120]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0210.002; Mon, 22 Jun 2015 11:23:18 +0200 From: Ingemar Johansson S To: Piers O'Hanlon , Neal Cardwell Thread-Topic: [e2e] TCP HyStart patch deployment Thread-Index: AdCXp+zNDAZ7zydkTra0wALqZYyJLQH+JqqAA0qsYsA= Date: Mon, 22 Jun 2015 09:23:17 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA34B2E666@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA32145DE4@ESESSMB205.ericsson.se> <1FFD9A11-ADF2-4BA6-A9D3-D8997E1A13E5@gmail.com> In-Reply-To: <1FFD9A11-ADF2-4BA6-A9D3-D8997E1A13E5@gmail.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGfG3Vpf9Snuowc0/PBZPjz1it9h9biqL RcedvSwW+2ZMZLQ4cuUYo8W2k/OZLL48vsrmwO6xc9Zddo8Fm0o9liz5yeTRcXwDcwBLFJdN SmpOZllqkb5dAlfGmff2BT3SFV8vvGdqYPwi2sXIwSEhYCKxcUZaFyMnkCkmceHeerYuRi4O IYGjjBI3vr1lhXCWMErcutLOBlLFJmAjsfLQd0YQW0TAT+L9m4NgRcwCPUwSaxcvYQVJCAvo S9y+PYsZoshAYsWPm+wQtpXE+a+b2UE2swioSnz5lQFi8gr4SlxdlgOxq4FR4uPSb2C7OAVs JW4ebGYCsRkFZCXuf7/HAmIzC4hL3HoynwniagGJJXvOM0PYohIvH/9jhbAVJT6+2scIUa8n cWPqFDYIW1ti2cLXYPW8AoISJ2c+YZnAKDYLydhZSFpmIWmZhaRlASPLKkbR4tTipNx0I2O9 1KLM5OLi/Dy9vNSSTYzACDy45bfqDsbLbxwPMQpwMCrx8CrktIcKsSaWFVfmHmKU5mBREued sTkvVEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj3gxm3v5zkc3Z75O8Y8IOXd1QkVW714zr jsSpwHKRVfG7bz6RPnk+5pm89tvUF/r8uXy8hY/12z7nmlyWkL7sP1Vpas/89s0OS2O8n10p X7BIZcbOkps7pzY1HjZteXx7ZdOae6e97RU1puZziX7acdHp34fNP0L1PvZ1Tp3NP6X1+SwW lk4fJZbijERDLeai4kQAYNEj0qECAAA= Archived-At: Cc: "tcpm@ietf.org" , Sangtae Ha , Ingemar Johansson S , Eric Dumazet , "end2end-interest@postel.org" Subject: Re: [tcpm] [e2e] TCP HyStart patch deployment X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 09:23:23 -0000 Hi Sorry for the delay and thanks for the response. The 4.0.4 is the one that = I have implemented. I have not involved any Linux networking list for the m= oment. That is perhaps a good idea once I get to understand this better. Currently I don't have any conclusive results that shows that there is a re= al issue with the current HyStart. Yes I can see a few cases where mainly t= he DELAY algorithm exits a bit early, and while one can argue that it is a = bit too early, there seems anyway to be enough data in the RLC buffers to u= tilize the link well in most of the cases. It is only in a few corner case= s that I have seen issues with a very low link utilization. As I cannot right now find a larger set of cases where HyStart is a general= issue it has not been possible to try out Neal's suggested modifications. I still have some more investigations to do after the vacation, this may sh= ow if there are general issues with HyStart.=20 /Ingemar > -----Original Message----- > From: Piers O'Hanlon [mailto:p.ohanlon@gmail.com] > Sent: den 5 juni 2015 19:02 > To: Ingemar Johansson S > Cc: tcpm@ietf.org; end2end-interest@postel.org > Subject: Re: [e2e] TCP HyStart patch deployment >=20 > Hi Ingemar, >=20 > Looking at linux-4.04 git code: > https://git.kernel.org/cgit/linux/kernel/git/stable/linux- > stable.git/tree/net/ipv4/tcp_cubic.c?id=3Drefs/tags/v4.0.4#n403 >=20 > It seems the HYSTART_DELAY code has been tweaked into a somewhat > similar direction (right shift 3 instead of the original 4) to the patch: > HYSTART_DELAY_THRESH(ca- > >delay_min >> 3)) { >=20 > Although the ACK train detection does appear unchanged. >=20 > It would seem that Hystart could have issues at very high rates as it doe= s rely > on a few default parameters that might not be suitable for such > environments. I can also imagine that it may not work so well on WiFi wit= h > block ACKing as Hystart uses a fixed window of 8 packets to estimate curr= ent > delay which may end up being one block of packets... >=20 > Did you try asking this question on any Linux networking lists? >=20 > Cheers, >=20 > Piers. >=20 > On 26 May 2015, at 12:38, Ingemar Johansson S wrote: >=20 > > Hi > > > > Does anybody know if the TCP Cubic HyStart patch described in the link > below is being used widely ? > > It does not seem to be implemented in the latest Linux code. > > http://patchwork.ozlabs.org/patch/85945/ > > > > Regards > > 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 om> > > www.ericsson.com > > > > "No man has a good enough memory > > to be a successful liar" > > Abraham > Lincoln tml> > > =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 > > > > _______________________________________________ > > end2end-interest mailing list > > end2end-interest@postel.org > > http://mailman.postel.org/mailman/listinfo/end2end-interest > > Contact list-owner@postel.org for assistance. From nobody Mon Jun 22 08:23:55 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E071ACEB2; Mon, 22 Jun 2015 08:23:53 -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 c8YaucwkH2Wj; Mon, 22 Jun 2015 08:23:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B13821ACEB3; Mon, 22 Jun 2015 08:23:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150622152351.2071.17550.idtracker@ietfa.amsl.com> Date: Mon, 22 Jun 2015 08:23:51 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 15:23:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Transmission Control Protocol Specification Author : Wesley M. Eddy Filename : draft-ietf-tcpm-rfc793bis-00.txt Pages : 83 Date : 2015-06-19 Abstract: This document specifies the Internet's Transmission Control Protocol (TCP). TCP is an important transport layer protocol in the Internet stack, and has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793 and several other RFCs (TODO: list all actual RFCs when finished). RFC EDITOR NOTE: If approved for publication as an RFC, this should be marked additionally as "STD: 7" and replace RFC 793 in that role. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-00 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 Mon Jun 22 08:37:07 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFF71ACDC6 for ; Mon, 22 Jun 2015 08:37:04 -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, 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 NKXKOGZXxMDA for ; Mon, 22 Jun 2015 08:36:58 -0700 (PDT) Received: from atl4mhob15.myregisteredsite.com (atl4mhob15.myregisteredsite.com [209.17.115.53]) by ietfa.amsl.com (Postfix) with ESMTP id 086651ACD30 for ; Mon, 22 Jun 2015 08:36:56 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob15.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t5MFasE7005299 for ; Mon, 22 Jun 2015 11:36:54 -0400 Received: (qmail 8602 invoked by uid 0); 22 Jun 2015 15:36:54 -0000 X-TCPREMOTEIP: 24.166.126.82 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.0.6?) (wes@mti-systems.com@24.166.126.82) by 0 with ESMTPA; 22 Jun 2015 15:36:54 -0000 Message-ID: <55882B8D.9060400@mti-systems.com> Date: Mon, 22 Jun 2015 11:36:45 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: tcpm@ietf.org References: <20150622152351.2071.17550.idtracker@ietfa.amsl.com> In-Reply-To: <20150622152351.2071.17550.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 15:37:04 -0000 This was submitted as a working group draft following the adoption call on draft-eddy-rfc793bis. The main changes between this and the prior revision are in the section on segmentation, which Joe Touch gave some helpful feedback on improving. It's my hope that this section is a lot better now, but feedback on that would be highly appreciated. There is also a git repository with the XML source which I'll send a link to shortly, that can be used to help collaborate on specific changes in the future iterations, if people are interested in that. On 6/22/2015 11:23 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 TCP Maintenance and Minor Extensions Working Group of the IETF. > > Title : Transmission Control Protocol Specification > Author : Wesley M. Eddy > Filename : draft-ietf-tcpm-rfc793bis-00.txt > Pages : 83 > Date : 2015-06-19 > > Abstract: > This document specifies the Internet's Transmission Control Protocol > (TCP). TCP is an important transport layer protocol in the Internet > stack, and has continuously evolved over decades of use and growth of > the Internet. Over this time, a number of changes have been made to > TCP as it was specified in RFC 793, though these have only been > documented in a piecemeal fashion. This document collects and brings > those changes together with the protocol specification from RFC 793. > This document obsoletes RFC 793 and several other RFCs (TODO: list > all actual RFCs when finished). > > RFC EDITOR NOTE: If approved for publication as an RFC, this should > be marked additionally as "STD: 7" and replace RFC 793 in that role. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-00 > > > 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/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > -- Wes Eddy MTI Systems From nobody Mon Jun 22 08:44:57 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229921B2FA2 for ; Mon, 22 Jun 2015 08:44:56 -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 RZk8mhfjqaBf for ; Mon, 22 Jun 2015 08:44:55 -0700 (PDT) Received: from atl4mhob11.myregisteredsite.com (atl4mhob11.myregisteredsite.com [209.17.115.49]) by ietfa.amsl.com (Postfix) with ESMTP id 019291B2F78 for ; Mon, 22 Jun 2015 08:44:54 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob11.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t5MFirGB031470 for ; Mon, 22 Jun 2015 11:44:53 -0400 Received: (qmail 1645 invoked by uid 0); 22 Jun 2015 15:44:53 -0000 X-TCPREMOTEIP: 24.166.126.82 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.0.6?) (wes@mti-systems.com@24.166.126.82) by 0 with ESMTPA; 22 Jun 2015 15:44:53 -0000 Message-ID: <55882D6C.6010903@mti-systems.com> Date: Mon, 22 Jun 2015 11:44:44 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "tcpm@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [tcpm] git repository for RFC793bis source X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 15:44:56 -0000 The chairs had a good idea to try using a git repository to aid in collaboration on the RFC793bis document changes, and possibly to assist in change tracking and comparison. For anyone interested, this can be found at: https://bitbucket.org/weddy/rfc793bis Please feel free to use this, however we will be sure to discuss all changes on the mailing list and not make changes through the git collaboration that haven't been vetted on the mailing list. -- Wes Eddy MTI Systems From nobody Mon Jun 22 13:57:16 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFC91A86EF; Mon, 22 Jun 2015 13:57:14 -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 49H6lvaUsmXG; Mon, 22 Jun 2015 13:57:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3159A1A8704; Mon, 22 Jun 2015 13:57:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150622205708.32143.3139.idtracker@ietfa.amsl.com> Date: Mon, 22 Jun 2015 13:57:08 -0700 Archived-At: Cc: tcpm@ietf.org, draft-ietf-tcpm-newcwv@ietf.org, tcpm-chairs@ietf.org Subject: [tcpm] Barry Leiba's No Objection on draft-ietf-tcpm-newcwv-12: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2015 20:57:15 -0000 Barry Leiba has entered the following ballot position for draft-ietf-tcpm-newcwv-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just a few very minor comments -- nothing that needs any discussion. -- Section 1 -- RFC 2616 is an obsolete reference for HTTP. The current reference is RFC 7230 o To incentivise the use of long-lived connections Will you please appease my inner pedant and not say "incentivise" (which, by the way, Chrome doesn't think is a word either)? You can take advantage of the previous bullet's use of "To remove the incentive for" by using this parallel construction: "To provide an incentive for the use of long-lived connections". -- Section 4.2 -- The method RECOMMENDS that the TCP SACK option [RFC2018] is enabled and the method defined in [RFC6675] is used to recover missing segments. Even more ridiculously pedantic than the other: subjunctive mood with "recommends", please. Make both "is" into "be". -- Section 4.4 -- A TCP sender implementing this specification MUST enter the non- validated phase when the pipeACK is less than (1/2)*cwnd. Given that there are "MAY"s and a "SHOULD" involved in how pipeACK is computed, it seems rather odd to have a MUST that relates to its value. You couldn't possibly determine whether an implementation was doing this "right" because there's so much variability in the value of pipeACK anyway. No need to discuss this, but I suggest that you just do this: NEW A TCP sender implementing this specification enters the non- validated phase when the pipeACK is less than (1/2)*cwnd. END From nobody Thu Jun 25 00:14:35 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9256B1B2A91; Thu, 25 Jun 2015 00:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.511 X-Spam-Level: X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 jvHd0us2RX2z; Thu, 25 Jun 2015 00:14:30 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id AC58C1B30AF; Thu, 25 Jun 2015 00:14:30 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 897BD1B00140; Thu, 25 Jun 2015 08:13:52 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Thu, 25 Jun 2015 08:13:19 +0100 Message-ID: <7f951897ff37eaff66410fd196413258.squirrel@erg.abdn.ac.uk> In-Reply-To: <20150625012721.13983.71237.idtracker@ietfa.amsl.com> References: <20150625012721.13983.71237.idtracker@ietfa.amsl.com> Date: Thu, 25 Jun 2015 08:13:19 +0100 From: gorry@erg.abdn.ac.uk To: "Kathleen Moriarty" , kaduk@DOMAIN.HIDDEN User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: tcpm@ietf.org, draft-ietf-tcpm-newcwv@ietf.org, The IESG , tcpm-chairs@ietf.org Subject: Re: [tcpm] Kathleen Moriarty's No Objection on draft-ietf-tcpm-newcwv-12: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 07:14:32 -0000 Kathleen, We'd like to thank the Secdir reviewer for these comments. Sorry for not responding directly - we believe these issues were resolved in rev 12, but we will check carefully against the final revision that we are preparing. Gorry > Kathleen Moriarty has entered the following ballot position for > draft-ietf-tcpm-newcwv-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > It does not appear that the SecDir review got a response, maybe the > editor and shepherd didn't see it? > https://www.ietf.org/mail-archive/web/secdir/current/msg05697.html > > He included a bunch of nits that might be helpful. > > From nobody Thu Jun 25 09:43:56 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1935B1A89BB; Tue, 23 Jun 2015 15:42:02 -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 YwYBIme8nUk5; Tue, 23 Jun 2015 15:42:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 013091A882F; Tue, 23 Jun 2015 15:42:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150623224201.12219.56150.idtracker@ietfa.amsl.com> Date: Tue, 23 Jun 2015 15:42:01 -0700 Archived-At: X-Mailman-Approved-At: Thu, 25 Jun 2015 09:43:55 -0700 Cc: tcpm@ietf.org, draft-ietf-tcpm-newcwv@ietf.org, tcpm-chairs@ietf.org Subject: [tcpm] Ben Campbell's No Objection on draft-ietf-tcpm-newcwv-12: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 22:42:02 -0000 Ben Campbell has entered the following ballot position for draft-ietf-tcpm-newcwv-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It appears that this draft obsoletes, makes historic, and according to section 1.2, updates 2861 :-) I guess it's okay to obsolete and make it historic in one fell swoop, but it might be worth removing "updates" from the first sentence of 1.2. My inner pedant concurs with Barry's. From nobody Thu Jun 25 09:43:58 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161981A1B34; Wed, 24 Jun 2015 18:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 AEJYhF_ro6CA; Wed, 24 Jun 2015 18:27:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E363B1A1A96; Wed, 24 Jun 2015 18:27:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150625012721.13983.71237.idtracker@ietfa.amsl.com> Date: Wed, 24 Jun 2015 18:27:21 -0700 Archived-At: X-Mailman-Approved-At: Thu, 25 Jun 2015 09:43:55 -0700 Cc: tcpm@ietf.org, draft-ietf-tcpm-newcwv@ietf.org, tcpm-chairs@ietf.org Subject: [tcpm] Kathleen Moriarty's No Objection on draft-ietf-tcpm-newcwv-12: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 01:27:23 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-tcpm-newcwv-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It does not appear that the SecDir review got a response, maybe the editor and shepherd didn't see it? https://www.ietf.org/mail-archive/web/secdir/current/msg05697.html He included a bunch of nits that might be helpful. From nobody Thu Jun 25 13:48:03 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042A51AD366; Thu, 25 Jun 2015 13:48:01 -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 h_yTGU0-UFGG; Thu, 25 Jun 2015 13:47:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7061AD36B; Thu, 25 Jun 2015 13:47:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150625204759.31936.29240.idtracker@ietfa.amsl.com> Date: Thu, 25 Jun 2015 13:47:59 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-13.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 20:48:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Updating TCP to support Rate-Limited Traffic Authors : Godred Fairhurst Arjuna Sathiaseelan Raffaello Secchi Filename : draft-ietf-tcpm-newcwv-13.txt Pages : 26 Date : 2015-06-25 Abstract: This document provides a mechanism to address issues that arise when TCP is used for traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It provides an experimental update to TCP that allows a TCP sender to restart quickly following a rate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP, while also providing an appropriate response if congestion is experienced. It also evaluates the Experimental specification of TCP Congestion Window Validation, CWV, defined in RFC 2861, and concludes that RFC 2861 sought to address important issues, but failed to deliver a widely used solution. This document therefore recommends that the status of RFC 2861 is moved from Experimental to Historic, and that it is replaced by the current specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-newcwv-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-13 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 Tue Jun 30 02:54:15 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8551A8706 for ; Tue, 30 Jun 2015 02:54:14 -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 8JuQoqapK2AM for ; Tue, 30 Jun 2015 02:54:12 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 192FF1A8701 for ; Tue, 30 Jun 2015 02:54:12 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z9sF0-0001d6-NI; Tue, 30 Jun 2015 11:54:10 +0200 Received: from [213.174.117.243] (helo=[10.40.118.69]) by mail-mx6.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80.1) (envelope-from ) id 1Z9sEz-0004qt-TN; Tue, 30 Jun 2015 11:54:10 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: Date: Tue, 30 Jun 2015 11:54:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150618192420.26836.11116.idtracker@ietfa.amsl.com> To: "Zimmermann, Alexander" X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 7 sum rcpts/h 12 sum msgs/h 8 total rcpts 30557 max rcpts/h 54 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: B007D19B671C129C791649012273EE23D703BF7A X-UiO-SPAM-Test: remote_host: 213.174.117.243 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 6 total 6 max/h 6 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-cubic-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 09:54:14 -0000 Hi, A detail: the beta factor (for multiplication when there is congestion) is 0.7, = not 0.8, since Linux kernel 2.6.25 from 2008. The draft talks about beta as a (1-beta) multiplication factor - so, = accordingly, to capture the current implementation state, in section = 3.5: *** When a packet loss occurs, CUBIC reduces its window size by a factor of beta. Parameter beta SHOULD be set to 0.2. *** should be: *** When a packet loss occurs, CUBIC reduces its window size by a factor of beta. Parameter beta SHOULD be set to 0.3. *** Side note: personally I find this use of beta confusing - "reduce by = ..." indicates subtraction to me, and I'm not sure if "reduce by a = factor of" is easily parsed by everyone as "multiplied by (1- ...)". = Just like the code, I would therefore rather write: *** When a packet loss occurs, CUBIC reduces its window size by multiplying = it with a factor of beta. The parameter beta SHOULD be set to 0.7. *** ... and change (1-beta) to beta below. But that's just a matter of = style/taste I guess. Cheers, Michael > On 19. jun. 2015, at 09.12, Zimmermann, Alexander = wrote: >=20 > This is just a resubmission of draft-zimmermann-tcpm-cubic-01 as WG = item. > Received feedback will be addressed in upcoming versions >=20 > Alex >=20 >> Am 18.06.2015 um 21:24 schrieb internet-drafts@ietf.org: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the TCP Maintenance and Minor Extensions = Working Group of the IETF. >>=20 >> Title : CUBIC for Fast Long-Distance Networks >> Authors : Injong Rhee >> Lisong Xu >> Sangtae Ha >> Alexander Zimmermann >> Lars Eggert >> Richard Scheffenegger >> Filename : draft-ietf-tcpm-cubic-00.txt >> Pages : 14 >> Date : 2015-06-18 >>=20 >> Abstract: >> CUBIC is an extension to the current TCP standards. The protocol >> differs from the current TCP standards only in the congestion window >> adjustment function in the sender side. In particular, it uses a >> cubic function instead of a linear window increase of the current = TCP >> standards to improve scalability and stability under fast and long >> distance networks. BIC-TCP, a predecessor of CUBIC, has been a >> default TCP adopted by Linux since year 2005 and has already been >> deployed globally and in use for several years by the Internet >> community at large. CUBIC is using a similar window growth function >> as BIC-TCP and is designed to be less aggressive and fairer to TCP = in >> bandwidth usage than BIC-TCP while maintaining the strengths of BIC- >> TCP such as stability, window scalability and RTT fairness. Through >> extensive testing in various Internet scenarios, we believe that >> CUBIC is safe for deployment and testing in the global Internet. = The >> intent of this document is to provide the protocol specification of >> CUBIC for a third party implementation and solicit the community >> feedback through experimentation on the performance of CUBIC. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-tcpm-cubic-00 >>=20 >>=20 >> 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. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Jun 30 06:33:54 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F10D1AD36F for ; Tue, 30 Jun 2015 06:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 pK_T6Kvhhx1W for ; Tue, 30 Jun 2015 06:33:51 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 307781AD0AE for ; Tue, 30 Jun 2015 06:33:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,377,1432623600"; d="scan'208";a="50894743" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx142-out.netapp.com with ESMTP; 30 Jun 2015 06:28:50 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 30 Jun 2015 06:28:50 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::d5df:ab0d:bad3:6282%21]) with mapi id 15.00.1076.000; Tue, 30 Jun 2015 06:28:50 -0700 From: "Scheffenegger, Richard" To: Michael Welzl , "Zimmermann, Alexander" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-cubic-00.txt Thread-Index: AQHQqfx2UjSfSpL6ik6G4sgX42T+2J2z3+0AgBF23AD//8XuQA== Date: Tue, 30 Jun 2015 13:28:49 +0000 Message-ID: <46a5bc17870f4db8b8a949ad4d80dbdc@hioexcmbx05-prd.hq.netapp.com> References: <20150618192420.26836.11116.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-cubic-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 13:33:53 -0000 Hi Michael, the critique around the "inverse" beta is also something that I found. It s= hould be straightforward to fix the text and formulas in order to use a mor= e standard use of the parameter "beta". Making this consistent with other TCP documents is valuable IMHO. Best regards, Richard > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Michael Welzl > Sent: Dienstag, 30. Juni 2015 11:54 > To: Zimmermann, Alexander > Cc: tcpm@ietf.org Extensions > Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-cubic-00.txt >=20 > Hi, >=20 > A detail: >=20 > the beta factor (for multiplication when there is congestion) is 0.7, not > 0.8, since Linux kernel 2.6.25 from 2008. > The draft talks about beta as a (1-beta) multiplication factor - so, > accordingly, to capture the current implementation state, in section 3.5: >=20 > *** > When a packet loss occurs, CUBIC reduces its window size by a factor > of beta. Parameter beta SHOULD be set to 0.2. > *** >=20 > should be: >=20 > *** > When a packet loss occurs, CUBIC reduces its window size by a factor > of beta. Parameter beta SHOULD be set to 0.3. > *** >=20 >=20 > Side note: personally I find this use of beta confusing - "reduce by ..." > indicates subtraction to me, and I'm not sure if "reduce by a factor of" > is easily parsed by everyone as "multiplied by (1- ...)". Just like the > code, I would therefore rather write: >=20 > *** > When a packet loss occurs, CUBIC reduces its window size by multiplying i= t > with a factor > of beta. The parameter beta SHOULD be set to 0.7. > *** >=20 > ... and change (1-beta) to beta below. But that's just a matter of > style/taste I guess. >=20 > Cheers, > Michael >=20 >=20 >=20 > > On 19. jun. 2015, at 09.12, Zimmermann, Alexander > wrote: > > > > This is just a resubmission of draft-zimmermann-tcpm-cubic-01 as WG > item. > > Received feedback will be addressed in upcoming versions > > > > Alex > > > >> Am 18.06.2015 um 21:24 schrieb internet-drafts@ietf.org: > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >> This draft is a work item of the TCP Maintenance and Minor Extensions > Working Group of the IETF. > >> > >> Title : CUBIC for Fast Long-Distance Networks > >> Authors : Injong Rhee > >> Lisong Xu > >> Sangtae Ha > >> Alexander Zimmermann > >> Lars Eggert > >> Richard Scheffenegger > >> Filename : draft-ietf-tcpm-cubic-00.txt > >> Pages : 14 > >> Date : 2015-06-18 > >> > >> Abstract: > >> CUBIC is an extension to the current TCP standards. The protocol > >> differs from the current TCP standards only in the congestion window > >> adjustment function in the sender side. In particular, it uses a > >> cubic function instead of a linear window increase of the current TCP > >> standards to improve scalability and stability under fast and long > >> distance networks. BIC-TCP, a predecessor of CUBIC, has been a > >> default TCP adopted by Linux since year 2005 and has already been > >> deployed globally and in use for several years by the Internet > >> community at large. CUBIC is using a similar window growth function > >> as BIC-TCP and is designed to be less aggressive and fairer to TCP in > >> bandwidth usage than BIC-TCP while maintaining the strengths of BIC- > >> TCP such as stability, window scalability and RTT fairness. Through > >> extensive testing in various Internet scenarios, we believe that > >> CUBIC is safe for deployment and testing in the global Internet. The > >> intent of this document is to provide the protocol specification of > >> CUBIC for a third party implementation and solicit the community > >> feedback through experimentation on the performance of CUBIC. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ > >> > >> There's also a htmlized version available at: > >> https://tools.ietf.org/html/draft-ietf-tcpm-cubic-00 > >> > >> > >> 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/ > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm