From nobody Wed Apr 1 11:53: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 A037B1A87ED for ; Wed, 1 Apr 2015 11:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.215 X-Spam-Level: ** X-Spam-Status: No, score=2.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, 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 B8XVyFmJtlXX for ; Wed, 1 Apr 2015 11:53:00 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89481A86FA for ; Wed, 1 Apr 2015 11:52:59 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 58A93278124 for ; Thu, 2 Apr 2015 03:52:57 +0900 (JST) Received: by widdi4 with SMTP id di4so55205196wid.0 for ; Wed, 01 Apr 2015 11:52:54 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.13.145 with SMTP id h17mr17894520wic.38.1427914374710; Wed, 01 Apr 2015 11:52:54 -0700 (PDT) Received: by 10.194.41.167 with HTTP; Wed, 1 Apr 2015 11:52:54 -0700 (PDT) In-Reply-To: <551B8501.1040508@si6networks.com> References: <20150326185546.29511.2115.idtracker@ietfa.amsl.com> <5514581D.4020909@si6networks.com> <915de06f7beb41c78b1a0b324ab14287@hioexcmbx05-prd.hq.netapp.com> <551B8501.1040508@si6networks.com> Date: Wed, 1 Apr 2015 11:52:54 -0700 Message-ID: From: Yoshifumi Nishida To: Fernando Gont Content-Type: multipart/alternative; boundary=001a11c2413e130a6b0512ae3937 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" , David Borman , "tcpm@ietf.org" Subject: Re: [tcpm] TCP SEQ validation (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-02.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: Wed, 01 Apr 2015 18:53:03 -0000 --001a11c2413e130a6b0512ae3937 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Fernando, Please allow us some time to think about how to proceed this. In the meantime, we welcome further feedback on the draft. Regards, -- Yoshi On Tue, Mar 31, 2015 at 10:41 PM, Fernando Gont wrote: > Folks, > > Would it make sense to do a wg call for adoption of this document? > > Thanks! > > Best regards, > Fernando > > > > > On 03/28/2015 02:59 AM, David Borman wrote: > > Accepting the ACK in a packet one to the left of the window is what was > implemented years (decades?) ago. It=E2=80=99s what I put into BSD/OS, t= he comment > at that time was: > > /* > > * If segment is just one to the left of the > window, > > * check three special cases: > > * 1. Don't toss RST in response to 4.2-style > keepalive. > > * 2. If the only thing to drop is a FIN, we ca= n > drop > > * it, but check the ACK or we will get into > FIN > > * wars if our FINs crossed (both CLOSING). > > * 3. If we have sent a window probe, it may or > may not > > * have been accepted. If window probes > crossed, > > * we must accept ACK on segments one to the > left > > * of the window, or we can get ACK wars aft= er > > * exchanging probes. (After sending a prob= e, > > * ACK-only packets are sent with the > pre-probe > > * sequence number.) > > * In any of these cases, send ACK to > resynchronize, > > * but keep on processing for RST or ACK. > > */ > > So mainly, the =E2=80=9Caccept the ACK if it is one to the left of the = window=E2=80=9D > was the original implementation. > > > > The only question is if there are any TCPs out there that actually do a > window probe of more than 1 byte; in that case you=E2=80=99d want to acce= pt an ACK > if it is within the maximum window probe size to the left of the window. > But only the implementations that generate a window probe of more than on= e > byte would need to worry about that, in case they had crossing probes wit= h > another TCP that also generated probes more than one byte in length. If > you have a one-byte probe crossing with a multi-byte probe, the one-byte > probe check is sufficient to break the ACK war. > > > > So maybe a comment needs to be inserted that if an implementation can > generate a multi-byte probe, then they have to also implement accepting > ACKs in packets within the maximum window probe size that they might > generate. That guarantees that whichever side sends the larger probe, > it=E2=80=99ll accept the ACK from the smaller probe, and the ACK war will= be broken. > > > > -David Borman > > > >> On Mar 27, 2015, at 12:54 PM, Yoshifumi Nishida > wrote: > >> > >> Hi Richard, > >> > >> On Fri, Mar 27, 2015 at 4:41 AM, Scheffenegger, Richard > wrote: > >> I would think PS is the proper way =E2=80=93 there is no experimenting= with a > buggy spec, and Fernando pointed out, that most stacks had fixed that > particular bug in 793 for quite some while, right? > >> > >> > >> Yes. I believe no one would argue the bug in 793 pointed out in the > draft. Also, I believe the solution presented in the draft is "make sense= ". > >> What I am wondering is this make sense solution can be the "once for > all" solution and we can happily update 793. > >> I guess some implementations have been using a bit different approach > than this, which gives me some concerns to update 793. > >> It will be very useful info if some implementations use this approach > or have a plan to use this approach. > >> > >> Thanks, > >> -- > >> Yoshi > >> > >> > >> > >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yoshifumi > Nishida > >> Sent: Donnerstag, 26. M=C3=A4rz 2015 18:23 > >> To: Fernando Gont > >> Cc: tcpm@ietf.org > >> Subject: Re: [tcpm] TCP SEQ validation (Fwd: New Version Notification > for draft-gont-tcpm-tcp-seq-validation-02.txt) > >> > >> > >> > >> Hi, > >> > >> I would like to check people who are willing to support it also agree > that this draft is published as a PS and it updates 793, or prefer other > ways. > >> > >> -- > >> > >> Yoshi > >> > >> > >> > >> On Thu, Mar 26, 2015 at 12:03 PM, Fernando Gont > wrote: > >> > >> Folks, > >> > >> Thanks to some folks' push over time, and the fact that both co-author= s > >> happened to find themselves at IETF 92, we've reposted our latests > >> version of this I-D (since the previous one had expired), in the hopes > >> of making progress. > >> > >> Any comments on this rev will be appreciated. Additionally, I'll > >> repost/fwd Karen's latest comments on this I-D, which will be the basi= s > >> for the changes in the next rev. > >> > >> Thanks! > >> > >> Best regards, > >> Fernando > >> > >> > >> > >> > >> -------- Forwarded Message -------- > >> Subject: New Version Notification for > >> draft-gont-tcpm-tcp-seq-validation-02.txt > >> Date: Thu, 26 Mar 2015 11:55:46 -0700 > >> From: internet-drafts@ietf.org > >> To: Fernando Gont , David Borman > >> , Fernando Gont , > David > >> Borman > >> > >> > >> A new version of I-D, draft-gont-tcpm-tcp-seq-validation-02.txt > >> has been successfully submitted by Fernando Gont and posted to the > >> IETF repository. > >> > >> Name: draft-gont-tcpm-tcp-seq-validation > >> Revision: 02 > >> Title: On the Validation of TCP Sequence Numbers > >> Document date: 2015-03-26 > >> Group: Individual Submission > >> Pages: 16 > >> URL: > >> > http://www.ietf.org/internet-drafts/draft-gont-tcpm-tcp-seq-validation-02= .txt > >> Status: > >> https://datatracker.ietf.org/doc/draft-gont-tcpm-tcp-seq-validation/ > >> Htmlized: > >> http://tools.ietf.org/html/draft-gont-tcpm-tcp-seq-validation-02 > >> Diff: > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-gont-tcpm-tcp-seq-validation-= 02 > >> > >> Abstract: > >> When TCP receives packets that lie outside of the receive window, t= he > >> corresponding packets are dropped and either an ACK, RST or no > >> response is generated due to the out-of-window packet, with no > >> further processing of the packet. Most of the time, this works jus= t > >> fine and TCP remains stable, especially when a TCP connection has > >> unidirectional data flow. However, there are three scenarios in > >> which packets that are outside of the receive window should still > >> have their ACK field processed, or else a packet war will take plac= e. > >> The aforementioned issues have affected a number of popular TCP > >> implementations, typically leading to connection failures, system > >> crashes, or other undesirable behaviors. This document describes t= he > >> three scenarios in which the aforementioned issues might arise, and > >> formally updates RFC 793 such that these potential problems are > >> mitigated. > >> > >> > >> > >> > >> > >> 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. > >> > >> The IETF Secretariat > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > --001a11c2413e130a6b0512ae3937 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Fernando,

Please allow us some time = to think about how to proceed this.
In= the meantime, we welcome further feedback on the draft.

Regards,
--
Yoshi

On Tue, Mar 31, 2015 at 10:= 41 PM, Fernando Gont <fgont@si6networks.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Folks,

Would it make sense to do a wg call for adoption of this document?

Thanks!

Best regards,
Fernando




On 03/28/2015 02:59 AM, David Borman wrote:
> Accepting the ACK in a packet one to the left of the window is what wa= s implemented years (decades?) ago.=C2=A0 It=E2=80=99s what I put into BSD/= OS, the comment at that time was:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0/*
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 * If segment is just one to the left of the window, >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 * check three special cases:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 * 1. Don't toss RST in response to 4.2-style keepa= live.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 * 2. If the only thing to drop is a FIN, we can drop >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 *=C2=A0 =C2=A0 it, but check the ACK or we will get in= to FIN
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 *=C2=A0 =C2=A0 wars if our FINs crossed (both CLOSING)= .
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 * 3. If we have sent a window probe, it may or may not=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 *=C2=A0 =C2=A0 have been accepted.=C2=A0 If window pro= bes crossed,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 *=C2=A0 =C2=A0 we must accept ACK on segments one to t= he left
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 *=C2=A0 =C2=A0 of the window, or we can get ACK wars a= fter
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 *=C2=A0 =C2=A0 exchanging probes.=C2=A0 (After sending= a probe,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 *=C2=A0 =C2=A0 ACK-only packets are sent with the pre-= probe
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 *=C2=A0 =C2=A0 sequence number.)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 * In any of these cases, send ACK to resynchronize, >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 * but keep on processing for RST or ACK.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 */
> So mainly, the =E2=80=9Caccept the ACK if it is one to the left of the= window=E2=80=9D was the original implementation.
>
> The only question is if there are any TCPs out there that actually do = a window probe of more than 1 byte; in that case you=E2=80=99d want to acce= pt an ACK if it is within the maximum window probe size to the left of the = window.=C2=A0 But only the implementations that generate a window probe of = more than one byte would need to worry about that, in case they had crossin= g probes with another TCP that also generated probes more than one byte in = length.=C2=A0 If you have a one-byte probe crossing with a multi-byte probe= , the one-byte probe check is sufficient to break the ACK war.
>
> So maybe a comment needs to be inserted that if an implementation can = generate a multi-byte probe, then they have to also implement accepting ACK= s in packets within the maximum window probe size that they might generate.= =C2=A0 That guarantees that whichever side sends the larger probe, it=E2=80= =99ll accept the ACK from the smaller probe, and the ACK war will be broken= .
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0-David Borman
>
>> On Mar 27, 2015, at 12:54 PM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
>>
>> Hi Richard,
>>
>> On Fri, Mar 27, 2015 at 4:41 AM, Scheffenegger, Richard <rs@netapp.com> wrote:
>> I would think PS is the proper way =E2=80=93 there is no experimen= ting with a buggy spec, and Fernando pointed out, that most stacks had fixe= d that particular bug in 793 for quite some while, right?
>>
>>
>> Yes.=C2=A0 I believe no one would argue the bug in 793 pointed out= in the draft. Also, I believe the solution presented in the draft is "= ;make sense".
>> What I am wondering is this make sense solution can be the "o= nce for all" solution and we can happily update 793.
>> I guess some implementations have been using a bit different appro= ach than this, which gives me some concerns to update 793.
>> It will be very useful info if some implementations use this appro= ach or have a plan to use this approach.
>>
>> Thanks,
>> --
>> Yoshi
>>
>>
>>
>> From: tcpm [mailto:tcpm-b= ounces@ietf.org] On Behalf Of Yoshifumi Nishida
>> Sent: Donnerstag, 26. M=C3=A4rz 2015 18:23
>> To: Fernando Gont
>> Cc: tcpm@ietf.org
>> Subject: Re: [tcpm] TCP SEQ validation (Fwd: New Version Notificat= ion for draft-gont-tcpm-tcp-seq-validation-02.txt)
>>
>>
>>
>> Hi,
>>
>> I would like to check people who are willing to support it also ag= ree that this draft is published as a PS and it updates 793, or prefer othe= r ways.
>>
>> --
>>
>> Yoshi
>>
>>
>>
>> On Thu, Mar 26, 2015 at 12:03 PM, Fernando Gont <fgont@si6networks.com> wrote:
>>
>> Folks,
>>
>> Thanks to some folks' push over time, and the fact that both c= o-authors
>> happened to find themselves at IETF 92, we've reposted our lat= ests
>> version of this I-D (since the previous one had expired), in the h= opes
>> of making progress.
>>
>> Any comments on this rev will be appreciated. Additionally, I'= ll
>> repost/fwd Karen's latest comments on this I-D, which will be = the basis
>> for the changes in the next rev.
>>
>> Thanks!
>>
>> Best regards,
>> Fernando
>>
>>
>>
>>
>> -------- Forwarded Message --------
>> Subject: New Version Notification for
>> draft-gont-tcpm-tcp-seq-validation-02.txt
>> Date: Thu, 26 Mar 2015 11:55:46 -0700
>> From: internet-drafts@= ietf.org
>> To: Fernando Gont <fgo= nt@si6networks.com>, David Borman
>> <david.borman@quant= um.com>, Fernando Gont <= fgont@si6networks.com>, David
>> Borman <david.borma= n@quantum.com>
>>
>>
>> A new version of I-D, draft-gont-tcpm-tcp-seq-validation-02.txt >> has been successfully submitted by Fernando Gont and posted to the=
>> IETF repository.
>>
>> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-gont-tcpm-tcp-= seq-validation
>> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
>> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On the Validation of TCP = Sequence Numbers
>> Document date:=C2=A0 2015-03-26
>> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
>> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 16
>> URL:
>> http://www.ietf.org/internet-draf= ts/draft-gont-tcpm-tcp-seq-validation-02.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-gon= t-tcpm-tcp-seq-validation/
>> Htmlized:
>> http://tools.ietf.org/html/draft-gont-tcpm-tcp= -seq-validation-02
>> Diff:
>> http://www.ietf.org/rfcdiff?url2=3Ddra= ft-gont-tcpm-tcp-seq-validation-02
>>
>> Abstract:
>>=C2=A0 =C2=A0 When TCP receives packets that lie outside of the rec= eive window, the
>>=C2=A0 =C2=A0 corresponding packets are dropped and either an ACK, = RST or no
>>=C2=A0 =C2=A0 response is generated due to the out-of-window packet= , with no
>>=C2=A0 =C2=A0 further processing of the packet.=C2=A0 Most of the t= ime, this works just
>>=C2=A0 =C2=A0 fine and TCP remains stable, especially when a TCP co= nnection has
>>=C2=A0 =C2=A0 unidirectional data flow.=C2=A0 However, there are th= ree scenarios in
>>=C2=A0 =C2=A0 which packets that are outside of the receive window = should still
>>=C2=A0 =C2=A0 have their ACK field processed, or else a packet war = will take place.
>>=C2=A0 =C2=A0 The aforementioned issues have affected a number of p= opular TCP
>>=C2=A0 =C2=A0 implementations, typically leading to connection fail= ures, system
>>=C2=A0 =C2=A0 crashes, or other undesirable behaviors.=C2=A0 This d= ocument describes the
>>=C2=A0 =C2=A0 three scenarios in which the aforementioned issues mi= ght arise, and
>>=C2=A0 =C2=A0 formally updates RFC 793 such that these potential pr= oblems are
>>=C2=A0 =C2=A0 mitigated.
>>
>>
>>
>>
>>
>> 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.
>>
>> The IETF Secretariat
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>


--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<= br> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





--001a11c2413e130a6b0512ae3937-- From nobody Tue Apr 7 02:40: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 15D431B33B7 for ; Tue, 7 Apr 2015 02:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 2zDleQKyRAMa for ; Tue, 7 Apr 2015 02:40:40 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 233F61B33B6 for ; Tue, 7 Apr 2015 02:40:37 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 6440F30F9AA8F; Tue, 7 Apr 2015 09:40:33 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t379eYqn029174 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Apr 2015 11:40:34 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 7 Apr 2015 11:40:34 +0200 From: "Scharf, Michael (Michael)" To: David Borman , Fernando Gont Thread-Topic: [tcpm] TCP SEQ validation (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-02.txt) Thread-Index: AQHQZ/k4tZoLe7K/7UGq7ieLag5lWp0vVwGAgADOFgCAAGhogIAAh4gAgBAm3LA= Date: Tue, 7 Apr 2015 09:40:33 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C81E73@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20150326185546.29511.2115.idtracker@ietfa.amsl.com> <5514581D.4020909@si6networks.com> <915de06f7beb41c78b1a0b324ab14287@hioexcmbx05-prd.hq.netapp.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] TCP SEQ validation (Fwd: New Version Notification for draft-gont-tcpm-tcp-seq-validation-02.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, 07 Apr 2015 09:40:43 -0000 RGF2aWQsIEZlcm5hbmRvLA0KDQpUaGFua3MgYSBsb3QgZm9yIHRoaXMgdXNlZnVsIGluZm9ybWF0 aW9uLiBTaW1pbGFyIGxpa2UgWW9zaGlmdW1pLCBJIHJlYWxseSB0aGluayBpdCBpcyByZWxldmFu dCB3aGF0IGltcGxlbWVudGF0aW9ucyBhY3R1YWxseSBkby4NCg0KSXMgbXkgdW5kZXJzdGFuZGlu ZyBjb3JyZWN0IHRoYXQgdGhpcyBwYXRjaCBoYXMgYmVlbiB1c2VkIGluIEJTRCBmb3IgYSB3aGls ZSwgYnV0IGl0IGhhcyBiZWVuIHJlcGxhY2VkIGJ5IG90aGVyIChtb3JlIGNvbXBsZXgpIHNlcXVl bmNlIG51bWJlciBjaGVja3MgaW4gbW9yZSByZWNlbnQgQlNEIHZlcnNpb25zPw0KDQpJbiBteSBw b2ludCBvZiB2aWV3LCB0aGUgc3RhdGVtZW50ICJUaGUgYWZvcmVtZW50aW9uZWQgaXNzdWVzIGhh dmUgYWZmZWN0ZWQgYSBudW1iZXIgb2YgcG9wdWxhciBUQ1AgaW1wbGVtZW50YXRpb25zIiBpcyBh IGJpdCB2YWd1ZSBhbmQgSU1ITyBhIG1vcmUgZXhwbGljaXQgYW5hbHlzaXMgaXMgbmVlZGVkIGZv ciBhbiB1cGRhdGUgb2YgUkZDIDc5My4NCg0KRm9yIHdoYXQgaXQgaXMgd29ydGgsIEkgcXVpY2ts eSBzY2FubmVkIHRocm91Z2ggdGhlIGtlcm5lbCBzb3VyY2VzIG9mIExpbnV4IGFuZCBGcmVlQlNE LiBJdCBzZWVtcyB0byBtZSB0aGF0IG5hdGl2ZWx5IGltcGxlbWVudGluZyB0aGUgc2VxdWVuY2Ug bnVtYmVyIGNoZWNrcyBhcyBkb2N1bWVudGVkIGluIFJGQyA3OTMgaXMgbm90IHJlYWxseSBjb21t b24gdG9kYXksIGFsc28gYmVjYXVzZSBvZiBvcHRpb25hbCBlbmhhbmNlbWVudHMgc3VjaCBhcyBS RkMgNTk2MSAod2hpY2ggZG9lcyBub3QgdXBkYXRlIFJGQyA3OTMsIEJUVykuDQoNCkZvciBpbnN0 YW5jZSwgYWNjb3JkaW5nIHRvIG15IHNob3J0IHJlc2VhcmNoLCBpbiBMaW51eCAzLjE5IHRoZSBu b24tU1lOIGNoZWNrIHNlZW1zIHRvIGJlIChlLmcuLCBodHRwOi8vbHhyLmZyZWUtZWxlY3Ryb25z LmNvbS9zb3VyY2UvbmV0L2lwdjQvdGNwX2lucHV0LmMpOg0KDQotLS1zbmlwLS0tDQovKiBDaGVj ayBzZWdtZW50IHNlcXVlbmNlIG51bWJlciBmb3IgdmFsaWRpdHkuDQogKg0KICogU2VnbWVudCBj b250cm9scyBhcmUgY29uc2lkZXJlZCB2YWxpZCwgaWYgdGhlIHNlZ21lbnQNCiAqIGZpdHMgdG8g dGhlIHdpbmRvdyBhZnRlciB0cnVuY2F0aW9uIHRvIHRoZSB3aW5kb3cuIEFjY2VwdGFiaWxpdHkN CiAqIG9mIGRhdGEgKGFuZCBTWU4sIEZJTiwgb2YgY291cnNlKSBpcyBjaGVja2VkIHNlcGFyYXRl bHkuDQogKiBTZWUgdGNwX2RhdGFfcXVldWUoKSwgZm9yIGV4YW1wbGUuDQogKg0KICogQWxzbywg Y29udHJvbHMgKFJTVCBpcyBtYWluIG9uZSkgYXJlIGFjY2VwdGVkIHVzaW5nIFJDVi5XVVAgaW5z dGVhZA0KICogb2YgUkNWLk5YVC4gUGVlciBzdGlsbCBkaWQgbm90IGFkdmFuY2UgaGlzIFNORC5V TkEgd2hlbiB3ZQ0KICogZGVsYXllZCBBQ0ssIHNvIHRoYXQgaGlzU05ELlVOQTw9b3VyUkNWLldV UC4NCiAqIChib3Jyb3dlZCBmcm9tIGZyZWVic2QpDQogKi8NCg0Kc3RhdGljIGlubGluZSBib29s IHRjcF9zZXF1ZW5jZShjb25zdCBzdHJ1Y3QgdGNwX3NvY2sgKnRwLCB1MzIgc2VxLCB1MzIgZW5k X3NlcSkNCnsNCiAgcmV0dXJuICFiZWZvcmUoZW5kX3NlcSwgdHAtPnJjdl93dXApICYmDQogICAg ICAgICAhYWZ0ZXIoc2VxLCB0cC0+cmN2X254dCArIHRjcF9yZWNlaXZlX3dpbmRvdyh0cCkpOw0K fQ0KLS0tc25pcC0tLQ0KDQpBdCBmaXJzdCBzaWdodCwgaW4gRnJlZUJTRCB0aGUgU1lOIGNoYXNl IGlzIGNoZWNrZWQgYnkgdGhpcyBjb2RlIChodHRwczovL2dpdGh1Yi5jb20vZnJlZWJzZC9mcmVl YnNkL2Jsb2IvbWFzdGVyL3N5cy9uZXRpbmV0L3RjcF9pbnB1dC5jKSwgd2hpY2ggY29uc2lkZXJz IHRoZSAxLWJ5dGUgb2Zmc2V0Og0KDQotLS1zbmlwLS0tDQp0b2Ryb3AgPSB0cC0+cmN2X254dCAt IHRoLT50aF9zZXE7DQppZiAodG9kcm9wID4gMCkgew0KICBpZiAodGhmbGFncyAmIFRIX1NZTikg ew0KICAgIHRoZmxhZ3MgJj0gflRIX1NZTjsNCiAgICB0aC0+dGhfc2VxKys7DQogICAgaWYgKHRo LT50aF91cnAgPiAxKQ0KICAgICAgdGgtPnRoX3VycC0tOw0KICAgIGVsc2UNCiAgICAgIHRoZmxh Z3MgJj0gflRIX1VSRzsNCiAgICB0b2Ryb3AtLTsNCiAgfQ0KLS0tc25pcC0tLQ0KDQpJJ3ZlIG5v dCBjb21wcmVoZW5zaXZlbHkgYW5hbHl6ZWQgb3RoZXIgY2FzZXMgYW5kIFRDUCBpbXBsZW1lbnRh dGlvbnMuDQoNCkluIG9yZGVyIHRvIG1vdmUgZm9yd2FyZCwgbXkgdGhpbmtpbmcgaXMgYXMgZm9s bG93czoNCg0KKiBGaXJzdCwgdGhlIGRvY3VtZW50IGhhcyB0byBtb3JlIGNsZWFybHkgc3RhdGUg d2hldGhlciB0aGUgcHJvcG9zZWQgZml4IGlzIG9ubHkgb25lIG91dCBvZiBzZXZlcmFsIHBvc3Np YmlsaXRpZXMsIG9yIHdoZXRoZXIgaXQgaXMgdGhlIG9ubHkgc29sdXRpb24uIE15IGN1cnJlbnQg YXNzdW1wdGlvbiBpcyB0aGF0IGl0IGlzIHRoZSBtb3N0IHN0cmFpZ2h0Zm9yd2FyZCBzb2x1dGlv biB0aGF0IG9ubHkgcmVsaWVzIG9uIHRoZSBzdGF0ZSB2YXJpYWJsZXMgZGVmaW5lZCBpbiBSRkMg NzkzLCBidXQgSSBtaWdodCBiZSB3cm9uZy4NCiANCiogU2Vjb25kLCBTZWN0aW9uIDQuMiBvZiBk cmFmdC1nb250LXRjcG0tdGNwLXNlcS12YWxpZGF0aW9uLTAyIG9ubHkgbWVudGlvbnMgTGludXgs IHdoaWNoIHNlZW1zIGEgYml0IG5hcnJvdy1mb2N1c2VkIHRvIG1lIChhbHNvLCB0aGUgTGludXgg a2VybmVsIGNoYW5nZXMsIGkuZS4sIGFueSBzdGF0ZW1lbnQgb25seSBhcHBsaWVzIHRvIGEgZ2l2 ZW4gdmVyc2lvbikuIEknZCByZWFsbHkgcHJlZmVyIGEgc2VjdGlvbiAob3IgYW4gYXBwZW5kaXgp IHRoYXQgbW9yZSBjb21wcmVoZW5zaXZlbHkgZGlzY3Vzc2VzIGhvdyB0aGUgaXNzdWVzIHByZXNl bnRlZCBpbiBkcmFmdC1nb250LXRjcG0tdGNwLXNlcS12YWxpZGF0aW9uLTAyIGFyZSBzb2x2ZWQg YnkgbW9kZXJuIFRDUCBzdGFja3MuIEZvciBpbnN0YW5jZSwgYSBzZWN0aW9uIGNvdWxkIGV4cGxp Y2l0bHkgYWNrbm93bGVkZ2UgdGhhdCBhbnkgc2VxdWVuY2UgbnVtYmVyIGNoZWNrIHdvdWxkIHdv cmsgYXMgbG9uZyBhcyB0aGUgc2NlbmFyaW9zIGV4cGxhaW5lZCBpbiB0aGlzIGRvY3VtZW50IGFy ZSBjb3JyZWN0bHkgaGFuZGxlZC4gDQogDQoqIFRoaXJkLCBJIHdvbmRlciBpZiB0aGUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpcyByZWFsbHkgY29tcGxldGUuIEEgbG90IGhhcyBo YXBwZW5lZCBzaW5jZSBwdWJsaWNhdGlvbiBvZiBSRkMgNzkzLiBGb3IgaW5zdGFuY2UsIHdvdWxk IGl0IG1ha2Ugc2Vuc2UgdG8gcmVmZXIgdG8gUkZDIDU5NjEgKGV2ZW4gaWYgaXQgYWRkcmVzc2Vz IGEgc2xpZ2h0bHkgZGlmZmVyZW50IHByb2JsZW0pPw0KDQpBcyBpbmRpdmlkdWFsIGNvbnRyaWJ1 dG9yIHRvIFRDUE0sIEknZCBwcmVmZXIgdG8gZGlzY3VzcyBXRyBhZG9wdGlvbiBmb3IgYSB1cGRh dGVkIGRvY3VtZW50IHRoYXQgYmV0dGVyIGFkZHJlc3NlcyBzdWNoIHF1ZXN0aW9ucyAtIHdlIGFy ZSBub3QgcmVhbGx5IGluIGEgaHVycnksIGFzIGZhciBhcyBJIGNhbiB0ZWxsLg0KDQpBbnkgdGhv dWdodHM/DQoNCk1pY2hhZWwNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IHRjcG0gW21haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZp ZCBCb3JtYW4NCj4gU2VudDogU2F0dXJkYXksIE1hcmNoIDI4LCAyMDE1IDM6MDAgQU0NCj4gVG86 IFlvc2hpZnVtaSBOaXNoaWRhDQo+IENjOiB0Y3BtQGlldGYub3JnOyBGZXJuYW5kbyBHb250DQo+ IFN1YmplY3Q6IFJlOiBbdGNwbV0gVENQIFNFUSB2YWxpZGF0aW9uIChGd2Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbg0KPiBmb3IgZHJhZnQtZ29udC10Y3BtLXRjcC1zZXEtdmFsaWRhdGlvbi0w Mi50eHQpDQo+IA0KPiBBY2NlcHRpbmcgdGhlIEFDSyBpbiBhIHBhY2tldCBvbmUgdG8gdGhlIGxl ZnQgb2YgdGhlIHdpbmRvdyBpcyB3aGF0IHdhcw0KPiBpbXBsZW1lbnRlZCB5ZWFycyAoZGVjYWRl cz8pIGFnby4gIEl04oCZcyB3aGF0IEkgcHV0IGludG8gQlNEL09TLCB0aGUNCj4gY29tbWVudCBh dCB0aGF0IHRpbWUgd2FzOg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAvKg0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgKiBJZiBzZWdtZW50IGlzIGp1c3Qgb25lIHRvIHRoZSBsZWZ0IG9m IHRoZQ0KPiB3aW5kb3csDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAqIGNoZWNrIHRocmVl IHNwZWNpYWwgY2FzZXM6DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAqIDEuIERvbid0IHRv c3MgUlNUIGluIHJlc3BvbnNlIHRvIDQuMi1zdHlsZQ0KPiBrZWVwYWxpdmUuDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAqIDIuIElmIHRoZSBvbmx5IHRoaW5nIHRvIGRyb3AgaXMgYSBGSU4s IHdlDQo+IGNhbiBkcm9wDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAqICAgIGl0LCBidXQg Y2hlY2sgdGhlIEFDSyBvciB3ZSB3aWxsIGdldCBpbnRvDQo+IEZJTg0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgKiAgICB3YXJzIGlmIG91ciBGSU5zIGNyb3NzZWQgKGJvdGggQ0xPU0lORyku DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAqIDMuIElmIHdlIGhhdmUgc2VudCBhIHdpbmRv dyBwcm9iZSwgaXQgbWF5IG9yDQo+IG1heSBub3QNCj4gICAgICAgICAgICAgICAgICAgICAgICAg ICogICAgaGF2ZSBiZWVuIGFjY2VwdGVkLiAgSWYgd2luZG93IHByb2Jlcw0KPiBjcm9zc2VkLA0K PiAgICAgICAgICAgICAgICAgICAgICAgICAgKiAgICB3ZSBtdXN0IGFjY2VwdCBBQ0sgb24gc2Vn bWVudHMgb25lIHRvIHRoZQ0KPiBsZWZ0DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAqICAg IG9mIHRoZSB3aW5kb3csIG9yIHdlIGNhbiBnZXQgQUNLIHdhcnMNCj4gYWZ0ZXINCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICogICAgZXhjaGFuZ2luZyBwcm9iZXMuICAoQWZ0ZXIgc2VuZGlu ZyBhDQo+IHByb2JlLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgKiAgICBBQ0stb25seSBw YWNrZXRzIGFyZSBzZW50IHdpdGggdGhlIHByZS0NCj4gcHJvYmUNCj4gICAgICAgICAgICAgICAg ICAgICAgICAgICogICAgc2VxdWVuY2UgbnVtYmVyLikNCj4gICAgICAgICAgICAgICAgICAgICAg ICAgICogSW4gYW55IG9mIHRoZXNlIGNhc2VzLCBzZW5kIEFDSyB0bw0KPiByZXN5bmNocm9uaXpl LA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgKiBidXQga2VlcCBvbiBwcm9jZXNzaW5nIGZv ciBSU1Qgb3IgQUNLLg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgKi8NCj4gU28gbWFpbmx5 LCB0aGUg4oCcYWNjZXB0IHRoZSBBQ0sgaWYgaXQgaXMgb25lIHRvIHRoZSBsZWZ0IG9mIHRoZSB3 aW5kb3figJ0NCj4gd2FzIHRoZSBvcmlnaW5hbCBpbXBsZW1lbnRhdGlvbi4NCj4gDQo+IFRoZSBv bmx5IHF1ZXN0aW9uIGlzIGlmIHRoZXJlIGFyZSBhbnkgVENQcyBvdXQgdGhlcmUgdGhhdCBhY3R1 YWxseSBkbyBhDQo+IHdpbmRvdyBwcm9iZSBvZiBtb3JlIHRoYW4gMSBieXRlOyBpbiB0aGF0IGNh c2UgeW914oCZZCB3YW50IHRvIGFjY2VwdCBhbg0KPiBBQ0sgaWYgaXQgaXMgd2l0aGluIHRoZSBt YXhpbXVtIHdpbmRvdyBwcm9iZSBzaXplIHRvIHRoZSBsZWZ0IG9mIHRoZQ0KPiB3aW5kb3cuICBC dXQgb25seSB0aGUgaW1wbGVtZW50YXRpb25zIHRoYXQgZ2VuZXJhdGUgYSB3aW5kb3cgcHJvYmUg b2YNCj4gbW9yZSB0aGFuIG9uZSBieXRlIHdvdWxkIG5lZWQgdG8gd29ycnkgYWJvdXQgdGhhdCwg aW4gY2FzZSB0aGV5IGhhZA0KPiBjcm9zc2luZyBwcm9iZXMgd2l0aCBhbm90aGVyIFRDUCB0aGF0 IGFsc28gZ2VuZXJhdGVkIHByb2JlcyBtb3JlIHRoYW4NCj4gb25lIGJ5dGUgaW4gbGVuZ3RoLiAg SWYgeW91IGhhdmUgYSBvbmUtYnl0ZSBwcm9iZSBjcm9zc2luZyB3aXRoIGENCj4gbXVsdGktYnl0 ZSBwcm9iZSwgdGhlIG9uZS1ieXRlIHByb2JlIGNoZWNrIGlzIHN1ZmZpY2llbnQgdG8gYnJlYWsg dGhlDQo+IEFDSyB3YXIuDQo+IA0KPiBTbyBtYXliZSBhIGNvbW1lbnQgbmVlZHMgdG8gYmUgaW5z ZXJ0ZWQgdGhhdCBpZiBhbiBpbXBsZW1lbnRhdGlvbiBjYW4NCj4gZ2VuZXJhdGUgYSBtdWx0aS1i eXRlIHByb2JlLCB0aGVuIHRoZXkgaGF2ZSB0byBhbHNvIGltcGxlbWVudCBhY2NlcHRpbmcNCj4g QUNLcyBpbiBwYWNrZXRzIHdpdGhpbiB0aGUgbWF4aW11bSB3aW5kb3cgcHJvYmUgc2l6ZSB0aGF0 IHRoZXkgbWlnaHQNCj4gZ2VuZXJhdGUuICBUaGF0IGd1YXJhbnRlZXMgdGhhdCB3aGljaGV2ZXIg c2lkZSBzZW5kcyB0aGUgbGFyZ2VyIHByb2JlLA0KPiBpdOKAmWxsIGFjY2VwdCB0aGUgQUNLIGZy b20gdGhlIHNtYWxsZXIgcHJvYmUsIGFuZCB0aGUgQUNLIHdhciB3aWxsIGJlDQo+IGJyb2tlbi4N Cj4gDQo+IAkJCS1EYXZpZCBCb3JtYW4NCj4gDQo+ID4gT24gTWFyIDI3LCAyMDE1LCBhdCAxMjo1 NCBQTSwgWW9zaGlmdW1pIE5pc2hpZGENCj4gPG5pc2hpZGFAc2ZjLndpZGUuYWQuanA+IHdyb3Rl Og0KPiA+DQo+ID4gSGkgUmljaGFyZCwNCj4gPg0KPiA+IE9uIEZyaSwgTWFyIDI3LCAyMDE1IGF0 IDQ6NDEgQU0sIFNjaGVmZmVuZWdnZXIsIFJpY2hhcmQNCj4gPHJzQG5ldGFwcC5jb20+IHdyb3Rl Og0KPiA+IEkgd291bGQgdGhpbmsgUFMgaXMgdGhlIHByb3BlciB3YXkg4oCTIHRoZXJlIGlzIG5v IGV4cGVyaW1lbnRpbmcgd2l0aCBhDQo+IGJ1Z2d5IHNwZWMsIGFuZCBGZXJuYW5kbyBwb2ludGVk IG91dCwgdGhhdCBtb3N0IHN0YWNrcyBoYWQgZml4ZWQgdGhhdA0KPiBwYXJ0aWN1bGFyIGJ1ZyBp biA3OTMgZm9yIHF1aXRlIHNvbWUgd2hpbGUsIHJpZ2h0Pw0KPiA+DQo+ID4NCj4gPiBZZXMuICBJ IGJlbGlldmUgbm8gb25lIHdvdWxkIGFyZ3VlIHRoZSBidWcgaW4gNzkzIHBvaW50ZWQgb3V0IGlu IHRoZQ0KPiBkcmFmdC4gQWxzbywgSSBiZWxpZXZlIHRoZSBzb2x1dGlvbiBwcmVzZW50ZWQgaW4g dGhlIGRyYWZ0IGlzICJtYWtlDQo+IHNlbnNlIi4NCj4gPiBXaGF0IEkgYW0gd29uZGVyaW5nIGlz IHRoaXMgbWFrZSBzZW5zZSBzb2x1dGlvbiBjYW4gYmUgdGhlICJvbmNlIGZvcg0KPiBhbGwiIHNv bHV0aW9uIGFuZCB3ZSBjYW4gaGFwcGlseSB1cGRhdGUgNzkzLg0KPiA+IEkgZ3Vlc3Mgc29tZSBp bXBsZW1lbnRhdGlvbnMgaGF2ZSBiZWVuIHVzaW5nIGEgYml0IGRpZmZlcmVudCBhcHByb2FjaA0K PiB0aGFuIHRoaXMsIHdoaWNoIGdpdmVzIG1lIHNvbWUgY29uY2VybnMgdG8gdXBkYXRlIDc5My4N Cj4gPiBJdCB3aWxsIGJlIHZlcnkgdXNlZnVsIGluZm8gaWYgc29tZSBpbXBsZW1lbnRhdGlvbnMg dXNlIHRoaXMgYXBwcm9hY2gNCj4gb3IgaGF2ZSBhIHBsYW4gdG8gdXNlIHRoaXMgYXBwcm9hY2gu DQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gLS0NCj4gPiBZb3NoaQ0KPiA+DQo+ID4NCj4gPg0KPiA+ IEZyb206IHRjcG0gW21haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBZ b3NoaWZ1bWkNCj4gTmlzaGlkYQ0KPiA+IFNlbnQ6IERvbm5lcnN0YWcsIDI2LiBNw6RyeiAyMDE1 IDE4OjIzDQo+ID4gVG86IEZlcm5hbmRvIEdvbnQNCj4gPiBDYzogdGNwbUBpZXRmLm9yZw0KPiA+ IFN1YmplY3Q6IFJlOiBbdGNwbV0gVENQIFNFUSB2YWxpZGF0aW9uIChGd2Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbg0KPiBmb3IgZHJhZnQtZ29udC10Y3BtLXRjcC1zZXEtdmFsaWRhdGlvbi0w Mi50eHQpDQo+ID4NCj4gPg0KPiA+DQo+ID4gSGksDQo+ID4NCj4gPiBJIHdvdWxkIGxpa2UgdG8g Y2hlY2sgcGVvcGxlIHdobyBhcmUgd2lsbGluZyB0byBzdXBwb3J0IGl0IGFsc28gYWdyZWUNCj4g dGhhdCB0aGlzIGRyYWZ0IGlzIHB1Ymxpc2hlZCBhcyBhIFBTIGFuZCBpdCB1cGRhdGVzIDc5Mywg b3IgcHJlZmVyDQo+IG90aGVyIHdheXMuDQo+ID4NCj4gPiAtLQ0KPiA+DQo+ID4gWW9zaGkNCj4g Pg0KPiA+DQo+ID4NCj4gPiBPbiBUaHUsIE1hciAyNiwgMjAxNSBhdCAxMjowMyBQTSwgRmVybmFu ZG8gR29udA0KPiA8ZmdvbnRAc2k2bmV0d29ya3MuY29tPiB3cm90ZToNCj4gPg0KPiA+IEZvbGtz LA0KPiA+DQo+ID4gVGhhbmtzIHRvIHNvbWUgZm9sa3MnIHB1c2ggb3ZlciB0aW1lLCBhbmQgdGhl IGZhY3QgdGhhdCBib3RoIGNvLQ0KPiBhdXRob3JzDQo+ID4gaGFwcGVuZWQgdG8gZmluZCB0aGVt c2VsdmVzIGF0IElFVEYgOTIsIHdlJ3ZlIHJlcG9zdGVkIG91ciBsYXRlc3RzDQo+ID4gdmVyc2lv biBvZiB0aGlzIEktRCAoc2luY2UgdGhlIHByZXZpb3VzIG9uZSBoYWQgZXhwaXJlZCksIGluIHRo ZQ0KPiBob3Blcw0KPiA+IG9mIG1ha2luZyBwcm9ncmVzcy4NCj4gPg0KPiA+IEFueSBjb21tZW50 cyBvbiB0aGlzIHJldiB3aWxsIGJlIGFwcHJlY2lhdGVkLiBBZGRpdGlvbmFsbHksIEknbGwNCj4g PiByZXBvc3QvZndkIEthcmVuJ3MgbGF0ZXN0IGNvbW1lbnRzIG9uIHRoaXMgSS1ELCB3aGljaCB3 aWxsIGJlIHRoZQ0KPiBiYXNpcw0KPiA+IGZvciB0aGUgY2hhbmdlcyBpbiB0aGUgbmV4dCByZXYu DQo+ID4NCj4gPiBUaGFua3MhDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gRmVybmFuZG8N Cj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IC0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0t LS0tDQo+ID4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiA+IGRyYWZ0 LWdvbnQtdGNwbS10Y3Atc2VxLXZhbGlkYXRpb24tMDIudHh0DQo+ID4gRGF0ZTogVGh1LCAyNiBN YXIgMjAxNSAxMTo1NTo0NiAtMDcwMA0KPiA+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zw0KPiA+IFRvOiBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+LCBEYXZpZCBC b3JtYW4NCj4gPiA8ZGF2aWQuYm9ybWFuQHF1YW50dW0uY29tPiwgRmVybmFuZG8gR29udCA8Zmdv bnRAc2k2bmV0d29ya3MuY29tPiwNCj4gRGF2aWQNCj4gPiBCb3JtYW4gPGRhdmlkLmJvcm1hbkBx dWFudHVtLmNvbT4NCj4gPg0KPiA+DQo+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWdv bnQtdGNwbS10Y3Atc2VxLXZhbGlkYXRpb24tMDIudHh0DQo+ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBGZXJuYW5kbyBHb250IGFuZCBwb3N0ZWQgdG8gdGhlDQo+ID4gSUVU RiByZXBvc2l0b3J5Lg0KPiA+DQo+ID4gTmFtZTogICAgICAgICAgIGRyYWZ0LWdvbnQtdGNwbS10 Y3Atc2VxLXZhbGlkYXRpb24NCj4gPiBSZXZpc2lvbjogICAgICAgMDINCj4gPiBUaXRsZTogICAg ICAgICAgT24gdGhlIFZhbGlkYXRpb24gb2YgVENQIFNlcXVlbmNlIE51bWJlcnMNCj4gPiBEb2N1 bWVudCBkYXRlOiAgMjAxNS0wMy0yNg0KPiA+IEdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCj4gPiBQYWdlczogICAgICAgICAgMTYNCj4gPiBVUkw6DQo+ID4gaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZ29udC10Y3BtLXRjcC1zZXEtDQo+IHZh bGlkYXRpb24tMDIudHh0DQo+ID4gU3RhdHVzOg0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWdvbnQtdGNwbS10Y3Atc2VxLXZhbGlkYXRpb24vDQo+ID4gSHRtbGl6 ZWQ6DQo+ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ29udC10Y3BtLXRjcC1z ZXEtdmFsaWRhdGlvbi0wMg0KPiA+IERpZmY6DQo+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtZ29udC10Y3BtLXRjcC1zZXEtdmFsaWRhdGlvbi0NCj4gMDINCj4gPg0K PiA+IEFic3RyYWN0Og0KPiA+ICAgIFdoZW4gVENQIHJlY2VpdmVzIHBhY2tldHMgdGhhdCBsaWUg b3V0c2lkZSBvZiB0aGUgcmVjZWl2ZSB3aW5kb3csDQo+IHRoZQ0KPiA+ICAgIGNvcnJlc3BvbmRp bmcgcGFja2V0cyBhcmUgZHJvcHBlZCBhbmQgZWl0aGVyIGFuIEFDSywgUlNUIG9yIG5vDQo+ID4g ICAgcmVzcG9uc2UgaXMgZ2VuZXJhdGVkIGR1ZSB0byB0aGUgb3V0LW9mLXdpbmRvdyBwYWNrZXQs IHdpdGggbm8NCj4gPiAgICBmdXJ0aGVyIHByb2Nlc3Npbmcgb2YgdGhlIHBhY2tldC4gIE1vc3Qg b2YgdGhlIHRpbWUsIHRoaXMgd29ya3MNCj4ganVzdA0KPiA+ICAgIGZpbmUgYW5kIFRDUCByZW1h aW5zIHN0YWJsZSwgZXNwZWNpYWxseSB3aGVuIGEgVENQIGNvbm5lY3Rpb24gaGFzDQo+ID4gICAg dW5pZGlyZWN0aW9uYWwgZGF0YSBmbG93LiAgSG93ZXZlciwgdGhlcmUgYXJlIHRocmVlIHNjZW5h cmlvcyBpbg0KPiA+ICAgIHdoaWNoIHBhY2tldHMgdGhhdCBhcmUgb3V0c2lkZSBvZiB0aGUgcmVj ZWl2ZSB3aW5kb3cgc2hvdWxkIHN0aWxsDQo+ID4gICAgaGF2ZSB0aGVpciBBQ0sgZmllbGQgcHJv Y2Vzc2VkLCBvciBlbHNlIGEgcGFja2V0IHdhciB3aWxsIHRha2UNCj4gcGxhY2UuDQo+ID4gICAg VGhlIGFmb3JlbWVudGlvbmVkIGlzc3VlcyBoYXZlIGFmZmVjdGVkIGEgbnVtYmVyIG9mIHBvcHVs YXIgVENQDQo+ID4gICAgaW1wbGVtZW50YXRpb25zLCB0eXBpY2FsbHkgbGVhZGluZyB0byBjb25u ZWN0aW9uIGZhaWx1cmVzLCBzeXN0ZW0NCj4gPiAgICBjcmFzaGVzLCBvciBvdGhlciB1bmRlc2ly YWJsZSBiZWhhdmlvcnMuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcw0KPiB0aGUNCj4gPiAgICB0 aHJlZSBzY2VuYXJpb3MgaW4gd2hpY2ggdGhlIGFmb3JlbWVudGlvbmVkIGlzc3VlcyBtaWdodCBh cmlzZSwNCj4gYW5kDQo+ID4gICAgZm9ybWFsbHkgdXBkYXRlcyBSRkMgNzkzIHN1Y2ggdGhhdCB0 aGVzZSBwb3RlbnRpYWwgcHJvYmxlbXMgYXJlDQo+ID4gICAgbWl0aWdhdGVkLg0KPiA+DQo+ID4N Cj4gPg0KPiA+DQo+ID4NCj4gPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiBzdWJtaXNzaW9uDQo+ID4gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy4NCj4gPg0KPiA+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHRj cG0gbWFpbGluZyBsaXN0DQo+ID4gdGNwbUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiB0Y3BtIG1haWxp bmcgbGlzdA0KPiA+IHRjcG1AaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3RjcG0NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IHRjcG0gbWFpbGluZyBsaXN0DQo+IHRjcG1AaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQo= From nobody Wed Apr 8 06:57: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 3E3681A8A42; Wed, 8 Apr 2015 06:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 vKgecU64uJvL; Wed, 8 Apr 2015 06:57:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E922B1A87CB; Wed, 8 Apr 2015 06:57:52 -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: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150408135752.3890.64572.idtracker@ietfa.amsl.com> Date: Wed, 08 Apr 2015 06:57:52 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-06.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: Wed, 08 Apr 2015 13:57:54 -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-06.txt Pages : 16 Date : 2015-04-08 Abstract: This document describes a modified 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 more aggressively 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: http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rtorestart-06 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 Apr 9 08:17: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 4C6561A8755 for ; Thu, 9 Apr 2015 08:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fyChhKwSZQnO for ; Thu, 9 Apr 2015 08:17:19 -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 422831A8739 for ; Thu, 9 Apr 2015 08:17:19 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:21f:5bff:fe38:7354]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 869631B0051F; Thu, 9 Apr 2015 16:17:34 +0100 (BST) Message-ID: <552697FD.2070807@erg.abdn.ac.uk> Date: Thu, 09 Apr 2015 16:17:17 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "tcpm@ietf.org" CC: tcpm@ietf.org References: <20150408135752.3890.64572.idtracker@ietfa.amsl.com> In-Reply-To: <20150408135752.3890.64572.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tcpm] Comments draft-ietf-tcpm-rtorestart-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 15:17:21 -0000 A few quick comments on this latest revision: * I believe this is a sender-side only change, but the abstract doesn't explicitly say this, i.e. "This document specifies a sender-only modification to TCP and SCTP " * The introduction does not explain why the WG has requested this to be experimental (is it the maturity or options of the algorithm; deployment experience; etc), e.g. "The specification in this draft is classified as "Experimental" pending experience with deployed implementations of the methods." * Section 4 specifies the experimental algorithm, it may be useful to add a sentence at the start of this section that explicitly says this "This section specifies the modifications required", to contrast with the informative material in section 3,5,6. * I have reviewed section 7, and this seems to me to address the SCTP-related comments received at the Dallas IETF meeting. * To avoid doubt by security reviewers, You could possibly also note this in the security considerations section: i.e. "This document specifies an experimental sender-only modification to TCP and SCTP." Gorry From nobody Thu Apr 9 09:13:27 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 9EA271A885B for ; Thu, 9 Apr 2015 09:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 THAISsr3Uj_E for ; Thu, 9 Apr 2015 09:13:24 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 351381A8869 for ; Thu, 9 Apr 2015 09:13:24 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id C71735CC1C39; Thu, 9 Apr 2015 16:13:19 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t39GCp5N007138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Apr 2015 18:13:21 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 9 Apr 2015 18:12:59 +0200 From: "Scharf, Michael (Michael)" To: "gorry@erg.abdn.ac.uk" Thread-Topic: [tcpm] Comments draft-ietf-tcpm-rtorestart-06.txt Thread-Index: AQHQcthi18OtKPJvV0GQAv07ZswCDZ1E18dQ Date: Thu, 9 Apr 2015 16:12:59 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C84CD8@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20150408135752.3890.64572.idtracker@ietfa.amsl.com> <552697FD.2070807@erg.abdn.ac.uk> In-Reply-To: <552697FD.2070807@erg.abdn.ac.uk> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Comments draft-ietf-tcpm-rtorestart-06.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, 09 Apr 2015 16:13:25 -0000 > A few quick comments on this latest revision: >=20 > * I believe this is a sender-side only change, but the abstract doesn't > explicitly say this, i.e. "This document specifies a sender-only > modification to TCP and SCTP " Good point - this could help with reviews =20 > * The introduction does not explain why the WG has requested this to be > experimental (is it the maturity or options of the algorithm; > deployment > experience; etc), e.g. "The specification in this draft is classified > as > "Experimental" pending experience with deployed implementations of the > methods." This is a valid concern, but I wonder if there is a more future-proof wordi= ng. For similar TCPM documents we explicitly noted what further experimentation= would be useful. In case of draft-ietf-tcpm-rtorestart, some of these expe= riments directly follow from some of the content in Section 5. IMHO, the areas in which further experimentation is needed could be stated = more explicitly, e.g., in the introduction with a reference to Section 5. T= his would also explain the status while being valid even if deployment expe= rience increases in future. Michael > * Section 4 specifies the experimental algorithm, it may be useful to > add a sentence at the start of this section that explicitly says this > "This section specifies the modifications required", to contrast with > the informative material in section 3,5,6. >=20 > * I have reviewed section 7, and this seems to me to address the > SCTP-related comments received at the Dallas IETF meeting. >=20 > * To avoid doubt by security reviewers, You could possibly also note > this in the security considerations section: i.e. "This document > specifies an experimental sender-only modification to TCP and SCTP." >=20 > Gorry From nobody Fri Apr 10 09:40: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 670091AC44D; Fri, 10 Apr 2015 09:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cfPJ6OQMhqB; Fri, 10 Apr 2015 09:40:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E021ACE19; Fri, 10 Apr 2015 09:40:51 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.13.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150410164051.5289.66250.idtracker@ietfa.amsl.com> Date: Fri, 10 Apr 2015 09:40:51 -0700 Archived-At: Cc: tcpm WG Subject: [tcpm] WG Action: Rechartered TCP Maintenance and Minor Extensions (tcpm) 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: Fri, 10 Apr 2015 16:40:53 -0000 The TCP Maintenance and Minor Extensions (tcpm) working group in the Transport Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------------ Current Status: Active WG Chairs: Michael Scharf Yoshifumi Nishida Pasi Sarolahti Assigned Area Director: Martin Stiemerling Mailing list Address: tcpm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tcpm Archive: http://www.ietf.org/mail-archive/web/tcpm/ Charter: TCP is currently the Internet's predominant transport protocol. TCPM is the working group within the IETF that handles small TCP changes, i.e., minor extensions to TCP algorithms and protocol mechanisms. The TCPM WG serves several purposes: * The WG mostly focuses on maintenance issues (e.g., bug fixes) and modest changes to the protocol, algorithms, and interfaces that maintain TCP's utility. * The WG is a venue for moving current TCP specifications along the standards track (as community energy is available for such efforts). * The focus of the working group is TCP. In cases where small changes are directly applicable to other transports (e.g., SCTP or DCCP), the mappings to other transports may be specified alongside that for TCP, but other significant additions and changes to other transports are not in scope. TCPM also provides a venue for standardization of incremental enhancements of TCP's standard congestion control. In addition, TCPM may document alternative TCP congestion control algorithms that are known to be widely deployed, and that are considered safe for large-scale deployment in the Internet. Changes of algorithms may require additional review by the IRTF Congestion Control Research Group (ICCRG). Fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) will be handled by other working groups or will require rechartering. TCP's congestion control algorithms are the model followed by alternate transports (e.g., SCTP or DCCP), which are standardized in other working groups, such as the Transport Area WG (tsvwg). In the past, the IETF has worked on several documents about algorithms that are specified for multiple protocols (e.g., TCP and SCTP) in the same document. Which WG shepherds such documents will be determined on a case-by-case basis. In any case, the TCPM WG will remain in close contact with other relevant WGs working on these protocols to ensure openness and stringent review from all angles. New TCPM milestones that fall within the scope specified within the charter can be added after consensus on acceptance in the working group and approval by the responsible Area Director. Milestones: Aug 2013 - Submit document on restarting the RTO timer to the IESG for publication as an Experimental RFC Nov 2013 - Submit document on TCP support for rate-limited traffic for publication (status decided as earlier milestone) Nov 2013 - Submit document on an analysis of more detailed ECN feedback in TCP to the IESG for publication as an Informational RFC Mar 2014 - Submit revision of TCP roadmap (RFC 4614) to the IESG for publication as an Informational RFC Mar 2015 - Submit document obsoleting undeployed TCP extensions to the IESG for publication as an Informational RFC Aug 2015 - Submit document on a TCP Extended Data Offset Option to the IESG as a Proposed Standard RFC From nobody Mon Apr 13 03:22:28 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 834E61B3123 for ; Mon, 13 Apr 2015 03:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_46=0.6, 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 NTmAO67dSwLM for ; Mon, 13 Apr 2015 03:22:25 -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 38E461B3122 for ; Mon, 13 Apr 2015 03:22:25 -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 D9EAE1B00139 for ; Mon, 13 Apr 2015 11:22:38 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Mon, 13 Apr 2015 11:21:45 +0100 Message-ID: <4996bc5a8214190d17e32ce06923688a.squirrel@erg.abdn.ac.uk> Date: Mon, 13 Apr 2015 11:21:45 +0100 From: gorry@erg.abdn.ac.uk To: tcpm@ietf.org 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: Subject: [tcpm] Response to WGLC comments on draft-ietf-tcpm-newcwv-09 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, 13 Apr 2015 10:22:26 -0000 The authors received some comments on rev -09 during WGLC, and propose uploading a new rev to address these issues. Copies of the proposed changes are listed in the email below. Best wishes, Gorry, Raffaello and Arjuna. ---- Section 1.1 Implementation of new CWV * A new section was added to introduce the places where there are implementation flexibility: The method specified in this document is a sender-side only change to the the TCP congestion control behaviour of TCP. The method creates a new protocol state, and requires a sender to determine when the cwnd is validated or non-validated to control the entry and exit from this state XREF=state-rule. It defines how a TCP sender manages the growth of the cwnd using the set of rules defined in XREF=new-cwv-section. Implementation of this specification requires an implementor to define a method to provide a measure for the volume of recently acknowledged data (pipeACK). The details of this measurement are implementation-specific. An example is provided in XREF=examples-pipeACK, but other methods are permitted. A sender also needs to provide a method to determine when it becomes cwnd-limited. Implementation of this may require consideration of other TCP methods (see XREF=examples-cwnd-limited). A sender is also recommended to provide a method that controls the maximum burst size XREF=pacing. However, implementors are allowed flexibility in how this method is implemented and the choice of an appropriate method is expected to depend on the way in which the sender stack implements other TCP methods (such as TCP Segment Offload, TSO). ---- Section 4.4 * Clarified that the MUST is to satisfy the goal to avoid a TCP sender growing a large "non-validated" cwnd, when it has not recently sent using the current size of cwnd: “The sender is REQUIRED to detect the cwnd-limited condition using a method that conforms to the rules in this section. Example solutions can be found in Section 4.5. * Fixed format of bullet 2 in 4.4. Section 4.5.2: * Replacement text (improved wording): A sender needs to implement a method that detects the cwnd-limited condition (see ). This detects a condition where a sender in the non-validated phase receives an ACK, but the size of cwnd prevents sending more new data. In simple terms, this condition is true only when the FlightSize of a TCP sender is equal to or larger than the current cwnd. However, an implementation also needs to consider constraints on the way in which the cwnd variable can be used, for instance implementations need to support other TCP methods such as the Nagle Algorithm and TCP Segment Offload (TSO) that also use cwnd to control transmission. These other methods can result in a sender becoming cwnd-limited when the cwnd is nearly, rather than completely, equal to the FlightSize. From nobody Mon Apr 13 05:49: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 509E81B2F67 for ; Mon, 13 Apr 2015 05:49:43 -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 BPNMun8_uycV for ; Mon, 13 Apr 2015 05:49:41 -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 4B3111B2F5B for ; Mon, 13 Apr 2015 05:49:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,569,1422950400"; d="asc'?scan'208";a="35250768" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx143-out.netapp.com with ESMTP; 13 Apr 2015 05:49:09 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 13 Apr 2015 05:49:08 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::f07f:691d:89d:53b7%21]) with mapi id 15.00.0995.031; Mon, 13 Apr 2015 05:49:08 -0700 From: "Eggert, Lars" To: "tcpm@ietf.org" Thread-Topic: New Version Notification - draft-bensley-tcpm-dctcp-03.txt Thread-Index: AQHQdeQ1w7tWRgvZ5EymJhJuZQLgPg== Date: Mon, 13 Apr 2015 12:49:08 +0000 Message-ID: <1ECF2E4D-6673-4157-B3CD-528083014A21@netapp.com> References: <20150413122010.31643.45508.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_1594FF8E-FAA5-4082-81F2-914FD2A6AFF7"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "draft-bensley-tcpm-dctcp@tools.ietf.org" Subject: [tcpm] Fwd: New Version Notification - draft-bensley-tcpm-dctcp-03.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, 13 Apr 2015 12:49:43 -0000 --Apple-Mail=_1594FF8E-FAA5-4082-81F2-914FD2A6AFF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, this -03 revision addresses all the outstanding issues that the authors = are aware of. It would be good to come to consensus on whether TCPM would like to = publish this as Informational, or whether we should take it somewhere = else. Lars Begin forwarded message: >=20 > From: > Subject: New Version Notification - draft-bensley-tcpm-dctcp-03.txt > Date: April 13, 2015 at 14:20:10 GMT+2 > To: , , , = , >=20 >=20 > A new version (-03) has been submitted for draft-bensley-tcpm-dctcp: > http://www.ietf.org/internet-drafts/draft-bensley-tcpm-dctcp-03.txt >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-bensley-tcpm-dctcp/ >=20 > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=3Ddraft-bensley-tcpm-dctcp-03 >=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 > IETF Secretariat. >=20 --Apple-Mail=_1594FF8E-FAA5-4082-81F2-914FD2A6AFF7 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----- iEYEARECAAYFAlUru0IACgkQIWcjmsUTWRoalACeI1P89UlMp+v2F5U+GDQWoLvp wVAAoKeSNbJ57BzQflbGY5hAwOq3PE0/ =P9Je -----END PGP SIGNATURE----- --Apple-Mail=_1594FF8E-FAA5-4082-81F2-914FD2A6AFF7-- From nobody Tue Apr 14 14:38:01 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 686FC1A1B57; Tue, 14 Apr 2015 14:37:58 -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 OrVvmu7U2unO; Tue, 14 Apr 2015 14:37:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D991A1ABB; Tue, 14 Apr 2015 14:37:56 -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.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150414213756.29194.53949.idtracker@ietfa.amsl.com> Date: Tue, 14 Apr 2015 14:37:56 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-10.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: Tue, 14 Apr 2015 21:37:58 -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-10.txt Pages : 24 Date : 2015-04-14 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: http://tools.ietf.org/html/draft-ietf-tcpm-newcwv-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-10 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 Wed Apr 15 00:14:27 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 82B891B3215 for ; Wed, 15 Apr 2015 00:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DD1zkP5pioof for ; Wed, 15 Apr 2015 00:14:24 -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 AD8951B3214 for ; Wed, 15 Apr 2015 00:14:24 -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 DB1431B001DA for ; Wed, 15 Apr 2015 08:14:36 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Wed, 15 Apr 2015 08:13:43 +0100 Message-ID: Date: Wed, 15 Apr 2015 08:13:43 +0100 From: gorry@erg.abdn.ac.uk To: tcpm@ietf.org 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: Subject: [tcpm] draft-ietf-tcpm-newcwv-10 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, 15 Apr 2015 07:14:26 -0000 Following the WGLC, we have uploaded a new version of the draft, which we hope addresses the issues raised: https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ Best wishes, Gorry, Raffaello and Arjuna From nobody Wed Apr 15 00:26:14 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 B5D5B1B323A for ; Wed, 15 Apr 2015 00:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 f45YXrvf8a7H for ; Wed, 15 Apr 2015 00:26:12 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 6C8481B3239 for ; Wed, 15 Apr 2015 00:26:11 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 31BECD0886CB3; Wed, 15 Apr 2015 07:26:07 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t3F7Q74v025721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Apr 2015 09:26:08 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 15 Apr 2015 09:26:07 +0200 From: "Scharf, Michael (Michael)" To: "gorry@erg.abdn.ac.uk" , "tcpm@ietf.org" Thread-Topic: [tcpm] draft-ietf-tcpm-newcwv-10 Thread-Index: AQHQd0vbhboAQUt0xkWZOk0eNHqwrZ1NqnhA Date: Wed, 15 Apr 2015 07:26:06 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C8D06C@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] draft-ietf-tcpm-newcwv-10 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, 15 Apr 2015 07:26:13 -0000 I had some private conversation with Gorry regarding the explanation of the= implementation flexibility. I confirm that my comments are addressed in th= is new version. Michael > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of > gorry@erg.abdn.ac.uk > Sent: Wednesday, April 15, 2015 9:14 AM > To: tcpm@ietf.org > Subject: [tcpm] draft-ietf-tcpm-newcwv-10 >=20 > Following the WGLC, we have uploaded a new version of the draft, which > we > hope addresses the issues raised: >=20 > https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ >=20 > Best wishes, >=20 > Gorry, Raffaello and Arjuna >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Apr 15 10:58:12 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 648931B368B; Wed, 15 Apr 2015 10:58:06 -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 4bBoSlJesN43; Wed, 15 Apr 2015 10:58:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1A41B367B; Wed, 15 Apr 2015 10:58:05 -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.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150415175805.17797.49699.idtracker@ietfa.amsl.com> Date: Wed, 15 Apr 2015 10:58:05 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-02.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: Wed, 15 Apr 2015 17:58:06 -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 Extended Data Offset Option Authors : Joe Touch Wesley M. Eddy Filename : draft-ietf-tcpm-tcp-edo-02.txt Pages : 22 Date : 2015-04-15 Abstract: TCP segments include a Data Offset field to indicate space for TCP options but the size of the field can limit the space available for complex options such as SACK and Multipath TCP and can limit the combination of such options supported in a single connection. This document updates RFC 793 with an optional TCP extension to that space to support the use of multiple large options. It also explains why the initial SYN of a connection cannot be extending a single segment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-edo/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-edo-02 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 Wed Apr 15 11:13:45 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 783FB1A0104; Wed, 15 Apr 2015 11:13:43 -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 gOMUlmQrgSqL; Wed, 15 Apr 2015 11:13:42 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB18B1A00F3; Wed, 15 Apr 2015 11:13:41 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t3FIAPbk022102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Apr 2015 11:10:26 -0700 (PDT) Message-ID: <552EA990.5000207@isi.edu> Date: Wed, 15 Apr 2015 11:10:24 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: internet-drafts@ietf.org, i-d-announce@ietf.org References: <20150415175805.17797.49699.idtracker@ietfa.amsl.com> In-Reply-To: <20150415175805.17797.49699.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-02.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: Wed, 15 Apr 2015 18:13:43 -0000 Hi, all, This revision addresses feedback from the last IETF meeting. It includes a variant that indicates the TCP segment length to detect when coalescing that might interfere with EDO occurs. It also includes more detailed motivation. I'm doing an additional round of wordsmithing, but wanted to post one ASAP since the previous one expired. Joe On 4/15/2015 10:58 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 : TCP Extended Data Offset Option > Authors : Joe Touch > Wesley M. Eddy > Filename : draft-ietf-tcpm-tcp-edo-02.txt > Pages : 22 > Date : 2015-04-15 > > Abstract: > TCP segments include a Data Offset field to indicate space for TCP > options but the size of the field can limit the space available for > complex options such as SACK and Multipath TCP and can limit the > combination of such options supported in a single connection. This > document updates RFC 793 with an optional TCP extension to that > space to support the use of multiple large options. It also explains > why the initial SYN of a connection cannot be extending a single > segment. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-edo/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-edo-02 > > > 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 > From nobody Wed Apr 15 11:23:46 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 01EC91A0367; Wed, 15 Apr 2015 11:23:45 -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 i5pKn8eC0l3K; Wed, 15 Apr 2015 11:23:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D65F11A0318; Wed, 15 Apr 2015 11:23:43 -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.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150415182343.20832.45769.idtracker@ietfa.amsl.com> Date: Wed, 15 Apr 2015 11:23:43 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-03.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: Wed, 15 Apr 2015 18:23:45 -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 Extended Data Offset Option Authors : Joe Touch Wesley M. Eddy Filename : draft-ietf-tcpm-tcp-edo-03.txt Pages : 23 Date : 2015-04-15 Abstract: TCP segments include a Data Offset field to indicate space for TCP options but the size of the field can limit the space available for complex options such as SACK and Multipath TCP and can limit the combination of such options supported in a single connection. This document updates RFC 793 with an optional TCP extension to that space to support the use of multiple large options. It also explains why the initial SYN of a connection cannot be extending a single segment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-edo/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-edo-03 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 Wed Apr 15 11:32: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 3A3D31A03A8; Wed, 15 Apr 2015 11:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TOOL=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 RUS9swgJ0jUK; Wed, 15 Apr 2015 11:32:22 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C0691A03FF; Wed, 15 Apr 2015 11:32:19 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t3FIVnlq028120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Apr 2015 11:31:49 -0700 (PDT) Message-ID: <552EAE94.9050607@isi.edu> Date: Wed, 15 Apr 2015 11:31:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: internet-drafts@ietf.org, i-d-announce@ietf.org References: <20150415182343.20832.45769.idtracker@ietfa.amsl.com> In-Reply-To: <20150415182343.20832.45769.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-03.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: Wed, 15 Apr 2015 18:32:23 -0000 A bit more word-smithing and deeper explanation of the Segment Length field. For discussions, please compare 03 to 01. Joe On 4/15/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 : TCP Extended Data Offset Option > Authors : Joe Touch > Wesley M. Eddy > Filename : draft-ietf-tcpm-tcp-edo-03.txt > Pages : 23 > Date : 2015-04-15 > > Abstract: > TCP segments include a Data Offset field to indicate space for TCP > options but the size of the field can limit the space available for > complex options such as SACK and Multipath TCP and can limit the > combination of such options supported in a single connection. This > document updates RFC 793 with an optional TCP extension to that > space to support the use of multiple large options. It also explains > why the initial SYN of a connection cannot be extending a single > segment. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-edo/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-edo-03 > > > 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 > From nobody Wed Apr 15 15:55: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 495F81AC3C4 for ; Wed, 15 Apr 2015 15:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.78 X-Spam-Level: X-Spam-Status: No, score=-3.78 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_MED=-2.3, TVD_SPACE_RATIO=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 t1aSfmqBcvQJ for ; Wed, 15 Apr 2015 15:55:56 -0700 (PDT) Received: from g9t5008.houston.hp.com (g9t5008.houston.hp.com [15.240.92.66]) (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 12E331A912B for ; Wed, 15 Apr 2015 15:55:56 -0700 (PDT) Received: from G9W0364.americas.hpqcorp.net (g9w0364.houston.hp.com [16.216.193.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g9t5008.houston.hp.com (Postfix) with ESMTPS id A1052589 for ; Wed, 15 Apr 2015 22:55:55 +0000 (UTC) Received: from G4W6306.americas.hpqcorp.net (16.210.26.231) by G9W0364.americas.hpqcorp.net (16.216.193.45) with Microsoft SMTP Server (TLS) id 14.3.169.1; Wed, 15 Apr 2015 22:53:29 +0000 Received: from G9W0721.americas.hpqcorp.net ([169.254.2.185]) by G4W6306.americas.hpqcorp.net ([16.210.26.231]) with mapi id 14.03.0169.001; Wed, 15 Apr 2015 22:53:29 +0000 From: "Cronin, Jon" To: "tcpm@ietf.org" Thread-Topic: unsubscribe Thread-Index: AdB3zvum9forq+4JRTSW0Rib/CwbaQ== Date: Wed, 15 Apr 2015 22:53:28 +0000 Message-ID: <0B874456FB46054F8B16F61EA0B8A56423A76413@G9W0721.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.210.48.14] Content-Type: multipart/alternative; boundary="_000_0B874456FB46054F8B16F61EA0B8A56423A76413G9W0721americas_" MIME-Version: 1.0 Archived-At: Subject: [tcpm] unsubscribe 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, 15 Apr 2015 22:55:57 -0000 --_000_0B874456FB46054F8B16F61EA0B8A56423A76413G9W0721americas_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable unsubscribe --_000_0B874456FB46054F8B16F61EA0B8A56423A76413G9W0721americas_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

unsubscribe

 

--_000_0B874456FB46054F8B16F61EA0B8A56423A76413G9W0721americas_-- From nobody Wed Apr 15 17:30:41 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 4F8D31ACEDE for ; Wed, 15 Apr 2015 17:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 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, 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 bS37FAa3RA49 for ; Wed, 15 Apr 2015 17:30:32 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (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 4B5121ACEDC for ; Wed, 15 Apr 2015 17:30:32 -0700 (PDT) Received: by iget9 with SMTP id t9so40471ige.1 for ; Wed, 15 Apr 2015 17:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cvaV1IjENmqy+ywazf6Y2Fkzh7oyqwT+4saTc/GxI74=; b=EBtfqviADJOvpWvpPNWkJvfUzAql96AKxlJpi0GiEVWAJrs/VxIFT/bcoGKNvQTn5V y5hqlTkFb8s0OUmVb2Plz91JG/fEpA5wvLO786PoRvGitGBBLQTBRa0E7ytXKCUzrTzB yKKZgsFl2hH+x19dKLBV7bfDeogLAP1gStf5D+OjqIzRkC8FPzdw+Uq5BA3yCE7HytKX hmfCAaV+7gUpkJdwZOZqQSHL8XC+C5IBhsaEeQd2GK7CkDg0xHXs0THhVJz/lUnxiWi3 b2KUvFrKj0PsbR21uTL8r2fsoThlIldp29CX/e0dAKWMex0/qf3H5GZr6QnNyR/JYtY2 ZnVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cvaV1IjENmqy+ywazf6Y2Fkzh7oyqwT+4saTc/GxI74=; b=m94KRjo81coIhglfhiUopUk6HhJa86bmAkJU/KyeZym45jCgC1KvDlFAF4wONYT9Rv KVH1ISLzLksScC1/+RFZQnEAgAb/smEcNgHXsfK7g5Ulgi3GQw39JjZlzDIevCN2MzFQ h9/4MSF5Y6qPW8lLL+hpn/LJF2rKIdFaUD5e5QwXQkakXLQU0xx0F0l+fmonmD8fNgbs KWbXege0Bulyr4BmrBHYMSiywtZiM+6NncaWFAsShcKDeOcRdrMJ/9ZvV02MztqP8oro 119XiF5nOC+bJf+kF48qYP0z0v9U8klML949BCiVxoTZgwznmXYpUPzhfkHELUwuTOMJ WG+Q== X-Gm-Message-State: ALoCoQmJtXtoRLIBAorV1uV/C7wUM5D07iyM2YnIv4gPhWU9+eIxOoyCpHbRrviSJZsY5Vq53xJ1 X-Received: by 10.50.117.4 with SMTP id ka4mr2018505igb.10.1429144231658; Wed, 15 Apr 2015 17:30:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.133.112 with HTTP; Wed, 15 Apr 2015 17:29:51 -0700 (PDT) In-Reply-To: <552EAE94.9050607@isi.edu> References: <20150415182343.20832.45769.idtracker@ietfa.amsl.com> <552EAE94.9050607@isi.edu> From: Yuchung Cheng Date: Wed, 15 Apr 2015 17:29:51 -0700 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-03.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, 16 Apr 2015 00:30:33 -0000 Joe you cited michio's paper that "In the split case, the key concern is if the split happens within the option extension space or if EDO is silently copied to both segments without copying the corresponding extended option space contents. However, the most comprehensive study of these cases indicates that "although middleboxes do split and coalesce segments, none did so while passing unknown options" [Ho11]." a) their "unknown options", according to the paper (sec 4.6), was really one (MP_DATA) option. b) MP_DATA, is not like EDO that touches payload space afaict Don't want to be pedantic, but there are middleboxes out there use GRO stuff How do we safely use EDO w/o worrying TCP is still reliable? From nobody Wed Apr 15 20:59: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 94BC41B2F50 for ; Wed, 15 Apr 2015 20:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=unavailable 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 3zTFKzDlTcEt for ; Wed, 15 Apr 2015 20:59:33 -0700 (PDT) Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3991B2F4D for ; Wed, 15 Apr 2015 20:59:33 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t3G3xUL1007147 for ; Wed, 15 Apr 2015 23:59:30 -0400 Received: (qmail 25044 invoked by uid 0); 16 Apr 2015 03:59:30 -0000 X-TCPREMOTEIP: 69.81.157.169 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.157.169) by 0 with ESMTPA; 16 Apr 2015 03:59:30 -0000 Message-ID: <552F339A.3000605@mti-systems.com> Date: Wed, 15 Apr 2015 23:59:22 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Joe Touch , internet-drafts@ietf.org, i-d-announce@ietf.org References: <20150415175805.17797.49699.idtracker@ietfa.amsl.com> <552EA990.5000207@isi.edu> In-Reply-To: <552EA990.5000207@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-02.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, 16 Apr 2015 03:59:34 -0000 On 4/15/2015 2:10 PM, Joe Touch wrote: > It includes a variant that indicates the TCP segment length to detect > when coalescing that might interfere with EDO occurs. This is one thing that I think we particularly want feedback from the group on. I think it's a very low-impact way (compared to adding checksums, using AO, using IPsec, etc) in order to reasonably detect an accidental pollution of the user data due to resegmentation. -- Wes Eddy MTI Systems From nobody Wed Apr 15 21:05:12 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 729381B2DBC for ; Wed, 15 Apr 2015 21:05:11 -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 X4w1BJaNAeqK for ; Wed, 15 Apr 2015 21:05:10 -0700 (PDT) Received: from atl4mhob03.myregisteredsite.com (atl4mhob03.myregisteredsite.com [209.17.115.41]) by ietfa.amsl.com (Postfix) with ESMTP id 46A271B2DBB for ; Wed, 15 Apr 2015 21:05:10 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob03.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t3G458uZ009084 for ; Thu, 16 Apr 2015 00:05:08 -0400 Received: (qmail 9266 invoked by uid 0); 16 Apr 2015 04:05:08 -0000 X-TCPREMOTEIP: 69.81.157.169 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.157.169) by 0 with ESMTPA; 16 Apr 2015 04:05:08 -0000 Message-ID: <552F34F3.6070300@mti-systems.com> Date: Thu, 16 Apr 2015 00:05:07 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Yuchung Cheng , Joe Touch References: <20150415182343.20832.45769.idtracker@ietfa.amsl.com> <552EAE94.9050607@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-03.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, 16 Apr 2015 04:05:11 -0000 On 4/15/2015 8:29 PM, Yuchung Cheng wrote: > Joe > > you cited michio's paper that > "In the split case, the key concern is if the split happens within > the option extension > space or if EDO is silently copied to both segments without copying > the corresponding extended option space contents. However, the most > comprehensive study of these cases indicates that "although > middleboxes do split and coalesce segments, none did so while > passing unknown options" [Ho11]." > > a) their "unknown options", according to the paper (sec 4.6), was > really one (MP_DATA) option. > b) MP_DATA, is not like EDO that touches payload space afaict > > Don't want to be pedantic, but there are middleboxes out there use GRO stuff > How do we safely use EDO w/o worrying TCP is still reliable? My guess has been that this would be treated very similarly to ECN blackholes. Once the issue in the path is detected, that fact is cached, and subsequent connections to the same destination don't attempt to use the feature. I think the change to add segment length to the option actually goes a long way in making this detectable too, and of course, there are other ways as well (such as John Leslie's checksum draft). -- Wes Eddy MTI Systems From nobody Wed Apr 15 21:57:25 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 4E4BA1B2FAD for ; Wed, 15 Apr 2015 21:57:24 -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 rAqmbMav9SUn for ; Wed, 15 Apr 2015 21:57:23 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70D31B2FAA for ; Wed, 15 Apr 2015 21:57:22 -0700 (PDT) Received: from [192.168.1.11] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t3G4us9K007734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Apr 2015 21:57:04 -0700 (PDT) Message-ID: <552F4115.8060203@isi.edu> Date: Wed, 15 Apr 2015 21:56:53 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Wesley Eddy , Yuchung Cheng References: <20150415182343.20832.45769.idtracker@ietfa.amsl.com> <552EAE94.9050607@isi.edu> <552F34F3.6070300@mti-systems.com> In-Reply-To: <552F34F3.6070300@mti-systems.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-03.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, 16 Apr 2015 04:57:24 -0000 On 4/15/2015 9:05 PM, Wesley Eddy wrote: > On 4/15/2015 8:29 PM, Yuchung Cheng wrote: >> Joe >> >> you cited michio's paper that >> "In the split case, the key concern is if the split happens within >> the option extension >> space or if EDO is silently copied to both segments without copying >> the corresponding extended option space contents. However, the most >> comprehensive study of these cases indicates that "although >> middleboxes do split and coalesce segments, none did so while >> passing unknown options" [Ho11]." >> >> a) their "unknown options", according to the paper (sec 4.6), was >> really one (MP_DATA) option. >> b) MP_DATA, is not like EDO that touches payload space afaict Although they are different, they both are unknown options. Middleboxes should not modify segments with options they don't understand - even before there were middleboxes, there were options that prohibited segment modification (alternate checksum, e.g.). That said, they clearly already do what they shouldn't, which is why we extended EDO to provide a detection mechanism. >> Don't want to be pedantic, but there are middleboxes out there use GRO stuff Our experience with GRO is a different issue. GRO explicitly claims to NOT merge or split segments with options that are not understood, but our experience with GRO in Linux was that this self-proclaimed requirement was not satisfied. Our code was not bulletproofed; it's entirely possible that there is a bug in how we implemented EDO that caused an undesired interaction with GRO. However, it's also entirely possible that GRO has a bug in it that needs to be fixed. We need to separate the GRO issue from middlebox manipulation until we understand why GRO is behaving in was that currently appear inconsistent *with its own claims*. >> How do we safely use EDO w/o worrying TCP is still reliable? a) use the Segment_Length variant, as is already recommended in this version (that's why we put it there) b) use EDO with a mechanism that truly protects TCP against middlebox misbehavior (e.g., IPsec, TCP-AO) ... > My guess has been that this would be treated very similarly to ECN > blackholes. Once the issue in the path is detected, that fact is > cached, and subsequent connections to the same destination don't > attempt to use the feature. > > I think the change to add segment length to the option actually goes > a long way in making this detectable too, and of course, there are > other ways as well (such as John Leslie's checksum draft). The length field will catch any changes that modify the length of a segment in transit. It will not catch other content rewriting. A checksum might catch rewriting too, but costs more to implement. Ultimately, we have to acknowledge that TCP describes communications between the endpoints - and that any intermediary should not modify what it doesn't *completely* understand (or, more specifically, that when it does modify things, it acts as an endpoint in place of the receiver). Joe From nobody Wed Apr 15 22:21:08 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 F19F11B301C for ; Wed, 15 Apr 2015 22:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.221 X-Spam-Level: * X-Spam-Status: No, score=1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 S6jntWF2zODo for ; Wed, 15 Apr 2015 22:21:04 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7A61B2FB1 for ; Wed, 15 Apr 2015 22:21:03 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 4B66F2780E6 for ; Thu, 16 Apr 2015 14:21:00 +0900 (JST) Received: by widdi4 with SMTP id di4so83800923wid.0 for ; Wed, 15 Apr 2015 22:20:57 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.181.13.144 with SMTP id ey16mr1720404wid.38.1429161657948; Wed, 15 Apr 2015 22:20:57 -0700 (PDT) Received: by 10.194.41.167 with HTTP; Wed, 15 Apr 2015 22:20:57 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D16C8D06C@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D16C8D06C@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Wed, 15 Apr 2015 22:20:57 -0700 Message-ID: From: Yoshifumi Nishida To: "Scharf, Michael (Michael)" Content-Type: multipart/alternative; boundary=f46d043c804cf2e5cf0513d0a013 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] draft-ietf-tcpm-newcwv-10 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, 16 Apr 2015 05:21:07 -0000 --f46d043c804cf2e5cf0513d0a013 Content-Type: text/plain; charset=UTF-8 It seems that it is settled. We'll proceed to the next step in a couple of days. Thank you so much! -- Yoshi On Wed, Apr 15, 2015 at 12:26 AM, Scharf, Michael (Michael) < michael.scharf@alcatel-lucent.com> wrote: > I had some private conversation with Gorry regarding the explanation of > the implementation flexibility. I confirm that my comments are addressed in > this new version. > > Michael > > > > -----Original Message----- > > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of > > gorry@erg.abdn.ac.uk > > Sent: Wednesday, April 15, 2015 9:14 AM > > To: tcpm@ietf.org > > Subject: [tcpm] draft-ietf-tcpm-newcwv-10 > > > > Following the WGLC, we have uploaded a new version of the draft, which > > we > > hope addresses the issues raised: > > > > https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ > > > > Best wishes, > > > > Gorry, Raffaello and Arjuna > > > > _______________________________________________ > > 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 > --f46d043c804cf2e5cf0513d0a013 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It seems that it is settled.
We'll proceed to the = next step in a couple of days.
Thank you so much!
--
Yoshi

= On Wed, Apr 15, 2015 at 12:26 AM, Scharf, Michael (Michael) <michael.scharf@alcatel-lucent.com> wrote:
I had some private conversation with Gorry regarding the = explanation of the implementation flexibility. I confirm that my comments a= re addressed in this new version.

Michael


> -----Original Message-----
> From: tcpm [mailto:tcpm-bounc= es@ietf.org] On Behalf Of
> gorry@erg.abdn.ac.uk
> Sent: Wednesday, April 15, 2015 9:14 AM
> To: tcpm@ietf.org
> Subject: [tcpm] draft-ietf-tcpm-newcwv-10
>
> Following the WGLC, we have uploaded a new version of the draft, which=
> we
> hope addresses the issues raised:
>
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/
>
> Best wishes,
>
> Gorry, Raffaello and Arjuna
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

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

--f46d043c804cf2e5cf0513d0a013-- From nobody Wed Apr 15 23:45:40 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 90DB71B2A42; Wed, 15 Apr 2015 23:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.215 X-Spam-Level: ** X-Spam-Status: No, score=2.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, 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 KA1IjhksROY9; Wed, 15 Apr 2015 23:45:36 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE24C1B2A2A; Wed, 15 Apr 2015 23:45:35 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2E526278068; Thu, 16 Apr 2015 15:45:33 +0900 (JST) Received: by wizk4 with SMTP id k4so182077863wiz.1; Wed, 15 Apr 2015 23:45:30 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.89.227 with SMTP id br3mr4894298wib.67.1429166730875; Wed, 15 Apr 2015 23:45:30 -0700 (PDT) Received: by 10.194.41.167 with HTTP; Wed, 15 Apr 2015 23:45:30 -0700 (PDT) In-Reply-To: <552F339A.3000605@mti-systems.com> References: <20150415175805.17797.49699.idtracker@ietfa.amsl.com> <552EA990.5000207@isi.edu> <552F339A.3000605@mti-systems.com> Date: Wed, 15 Apr 2015 23:45:30 -0700 Message-ID: From: Yoshifumi Nishida To: Wesley Eddy Content-Type: multipart/alternative; boundary=e89a8f23550f519b270513d1cf0b Archived-At: Cc: "tcpm@ietf.org" , i-d-announce@ietf.org, internet-drafts@ietf.org, Joe Touch Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-02.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, 16 Apr 2015 06:45:37 -0000 --e89a8f23550f519b270513d1cf0b Content-Type: text/plain; charset=UTF-8 Hi, On Wed, Apr 15, 2015 at 8:59 PM, Wesley Eddy wrote: > On 4/15/2015 2:10 PM, Joe Touch wrote: > > It includes a variant that indicates the TCP segment length to detect > > when coalescing that might interfere with EDO occurs. > > This is one thing that I think we particularly want feedback from > the group on. > > I think it's a very low-impact way (compared to adding checksums, > using AO, using IPsec, etc) in order to reasonably detect an > accidental pollution of the user data due to resegmentation. > >> When an endpoint receives a segment using the 6-byte EDO Extension option, it MUST validate the Segment_Length field with the length of the segment as indicated in the TCP pseudoheader. If the segment lengths do not match, the segment MUST be discarded and an error SHOULD be logged in a rate-limited manner. I am wondering if discarding a segment is safe enough. Once resegmentation happens, I think we are not very sure how to recover it. I guess it would be better to reset a connection. Thanks, -- Yoshi --e89a8f23550f519b270513d1cf0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On Wed, Apr 15, 2015 at 8:59 PM, Wesley Eddy <<= a href=3D"mailto:wes@mti-systems.com" target=3D"_blank">wes@mti-systems.com= > wrote:
On 4/15/2015 2:= 10 PM, Joe Touch wrote:
> It includes a variant that indicates the TCP segment length to detect<= br> > when coalescing that might interfere with EDO occurs.

This is one thing that I think we particularly want feedback from the group on.

I think it's a very low-impact way (compared to adding checksums,
using AO, using IPsec, etc) in order to reasonably detect an
accidental pollution of the user data due to resegmentation.

>> When an endpoint receives a s=
egment using the 6-byte EDO
   Extension option, it MUST validate the Segment_Length field with the
   length of the segment as indicated in the TCP pseudoheader. If the
   segment lengths do not match, the segment MUST be discarded and an
   error SHOULD be logged in a rate-limited manner.
I am wondering if discarding a segment is safe enough=
.
Once resegmentation happens, I think we are not very =
sure how to recover it.
I guess it would be better to r=
eset a connection.

Thanks,
--
Yoshi
--e89a8f23550f519b270513d1cf0b-- From nobody Mon Apr 20 14:01:11 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 1905B1B31C0; Mon, 20 Apr 2015 14:01: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 mGHfyT_yro0P; Mon, 20 Apr 2015 14:01:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9951B2D22; Mon, 20 Apr 2015 14:01: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.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150420210108.30665.97795.idtracker@ietfa.amsl.com> Date: Mon, 20 Apr 2015 14:01:08 -0700 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-07.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, 20 Apr 2015 21:01: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-07.txt Pages : 16 Date : 2015-04-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 more aggressively 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: http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rtorestart-07 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 Apr 20 14:31:34 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 4C0BC1B3246; Mon, 20 Apr 2015 14:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 sDu3CzCIL-IG; Mon, 20 Apr 2015 14:31:32 -0700 (PDT) Received: from mail-b.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A49F1B3245; Mon, 20 Apr 2015 14:31:32 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t3KLVCdu006997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Apr 2015 14:31:12 -0700 (PDT) Message-ID: <5535701F.9070709@isi.edu> Date: Mon, 20 Apr 2015 14:31:11 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Yoshifumi Nishida , Wesley Eddy References: <20150415175805.17797.49699.idtracker@ietfa.amsl.com> <552EA990.5000207@isi.edu> <552F339A.3000605@mti-systems.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org" , internet-drafts@ietf.org, i-d-announce@ietf.org Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-02.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, 20 Apr 2015 21:31:33 -0000 On 4/15/2015 11:45 PM, Yoshifumi Nishida wrote: > Hi, > > On Wed, Apr 15, 2015 at 8:59 PM, Wesley Eddy > wrote: > > On 4/15/2015 2:10 PM, Joe Touch wrote: > > It includes a variant that indicates the TCP segment length to detect > > when coalescing that might interfere with EDO occurs. > > This is one thing that I think we particularly want feedback from > the group on. > > I think it's a very low-impact way (compared to adding checksums, > using AO, using IPsec, etc) in order to reasonably detect an > accidental pollution of the user data due to resegmentation. > > >>> When an endpoint receives a segment using the 6-byte EDO > Extension option, it MUST validate the Segment_Length field with the > length of the segment as indicated in the TCP pseudoheader. If the > segment lengths do not match, the segment MUST be discarded and an > error SHOULD be logged in a rate-limited manner. > > > I am wondering if discarding a segment is safe enough. > Once resegmentation happens, I think we are not very sure how to recover it. > I guess it would be better to reset a connection. It's safe - the connection will fail after several failed retransmissions anyway. That limit can be controlled with the TCP User Timeout option. Jumping to a reset would be quicker but might be premature. The sender might be able to resend segments without EDO or the situation might be transient. Joe From nobody Mon Apr 20 15:01:41 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 D19FC1B32AD for ; Mon, 20 Apr 2015 15:01:38 -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 raAInz05WMy9 for ; Mon, 20 Apr 2015 15:01:37 -0700 (PDT) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF23C1A8747 for ; Mon, 20 Apr 2015 15:01:36 -0700 (PDT) X-Spam-Processed: mail.kau.se, Tue, 21 Apr 2015 00:01:29 +0200 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 213.113.181.237 X-MDArrival-Date: Tue, 21 Apr 2015 00:01:29 +0200 X-Authenticated-Sender: anna.brunstrom@kau.se X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se Message-ID: <55357723.7030009@kau.se> Date: Tue, 21 Apr 2015 00:01:07 +0200 From: Anna Brunstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk, "tcpm@ietf.org" References: <20150408135752.3890.64572.idtracker@ietfa.amsl.com> <552697FD.2070807@erg.abdn.ac.uk> In-Reply-To: <552697FD.2070807@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] Comments draft-ietf-tcpm-rtorestart-06.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, 20 Apr 2015 22:01:39 -0000 Thanks Gorry. We have submitted a new version of the draft, addressing the comments. BR, Anna On 2015-04-09 17:17, Gorry Fairhurst wrote: > > A few quick comments on this latest revision: > > * I believe this is a sender-side only change, but the abstract > doesn't explicitly say this, i.e. "This document specifies a > sender-only modification to TCP and SCTP " > > * The introduction does not explain why the WG has requested this to > be experimental (is it the maturity or options of the algorithm; > deployment experience; etc), e.g. "The specification in this draft is > classified as "Experimental" pending experience with deployed > implementations of the methods." > > * Section 4 specifies the experimental algorithm, it may be useful to > add a sentence at the start of this section that explicitly says this > "This section specifies the modifications required", to contrast with > the informative material in section 3,5,6. > > * I have reviewed section 7, and this seems to me to address the > SCTP-related comments received at the Dallas IETF meeting. > > * To avoid doubt by security reviewers, You could possibly also note > this in the security considerations section: i.e. "This document > specifies an experimental sender-only modification to TCP and SCTP." > > Gorry > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Apr 21 00:13:40 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 313541B369B for ; Tue, 21 Apr 2015 00:13:39 -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 5--M9lZYG-UA for ; Tue, 21 Apr 2015 00:13:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA021B36A9 for ; Tue, 21 Apr 2015 00:13:37 -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.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150421071337.30261.4020.idtracker@ietfa.amsl.com> Date: Tue, 21 Apr 2015 00:13:37 -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: Tue, 21 Apr 2015 07:13:39 -0000 Changed milestone "Submit revision of TCP roadmap (RFC 4614) to the IESG for publication as an Informational RFC", resolved as "Done". URL: http://datatracker.ietf.org/wg/tcpm/charter/ From nobody Tue Apr 21 00:28:08 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 E4ED51B36C8 for ; Tue, 21 Apr 2015 00:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 oOr4xJoDaDV8 for ; Tue, 21 Apr 2015 00:28:04 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 4577A1B36C7 for ; Tue, 21 Apr 2015 00:27:45 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 1E5712256F7ED; Tue, 21 Apr 2015 07:27:43 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t3L7Rgbf023180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Apr 2015 09:27:44 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 21 Apr 2015 09:27:43 +0200 From: "Scharf, Michael (Michael)" To: Wesley Eddy , "tcpm@ietf.org" Thread-Topic: Confirmation of WG acceptance of draft-eddy-rfc793bis-05 Thread-Index: AdB8BKdqojJo/im+QEC0I07Ix27kBg== Date: Tue, 21 Apr 2015 07:27:43 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C91F68@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] Confirmation of WG acceptance of draft-eddy-rfc793bis-05 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, 21 Apr 2015 07:28:06 -0000 Wes, all, This e-mail confirms that it is the consensus in TCPM to adopt draft-eddy-r= fc793bis-05 as new WG document with the milestone: Nov 2017 Submit RFC793bis document to the IESG for publication as Intern= et Standard Please resubmit the document as draft-ietf-tcpm-rfc793bis-00. This draft will need very careful review prior to publication. David Borman= , Fernando Gont, Brian Trammell, Joe Touch, and Alexander Zimmermann have a= lready committed to reviews. Help from further volunteers would be very use= ful. Thanks Michael, Pasi, Yoshifumi From nobody Tue Apr 21 00:36:33 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 3CC131A88EB for ; Tue, 21 Apr 2015 00:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 nAJ9Wv4HPHkU for ; Tue, 21 Apr 2015 00:36:31 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 248D91A887A for ; Tue, 21 Apr 2015 00:36:30 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 810CF8F09D7A8 for ; Tue, 21 Apr 2015 07:36:27 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t3L7aSIO015060 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 21 Apr 2015 09:36:28 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 21 Apr 2015 09:36:28 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: WGLC for draft-ietf-tcpm-rtorestart-07 Thread-Index: AdB8Bd/sIHkMj+bvQ2iusYYLd5k9MQ== Date: Tue, 21 Apr 2015 07:36:27 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C91F85@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] WGLC for 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: Tue, 21 Apr 2015 07:36:32 -0000 Hi all, This email starts a WGLC for draft-ietf-tcpm-rtorestart-07, running until M= ay 6. Please review the latest version and please let us know if there are any co= mments. Thanks a lot! Michael From nobody Tue Apr 21 01:17:30 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 41AF41B3760 for ; Tue, 21 Apr 2015 01:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nQt4xLyFZWqZ for ; Tue, 21 Apr 2015 01:17:27 -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 590441B3761 for ; Tue, 21 Apr 2015 01:17:14 -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 A0A3B1B00523; Tue, 21 Apr 2015 09:17:26 +0100 (BST) Received: from 130.243.28.208 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Tue, 21 Apr 2015 09:16:32 +0100 Message-ID: In-Reply-To: <655C07320163294895BBADA28372AF5D16C91F85@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D16C91F85@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Tue, 21 Apr 2015 09:16:32 +0100 From: gorry@erg.abdn.ac.uk To: "Scharf, Michael (Michael)" 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" Subject: Re: [tcpm] WGLC for 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: Tue, 21 Apr 2015 08:17:28 -0000 I've read the latest version and support this work. The draft addresses my recent comments. Gorry > Hi all, > > This email starts a WGLC for draft-ietf-tcpm-rtorestart-07, running until > May 6. > > Please review the latest version and please let us know if there are any > comments. > > Thanks a lot! > > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Tue Apr 21 01:19: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 BE78F1B3754 for ; Tue, 21 Apr 2015 01:19: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 ZQVOeN7gezYH for ; Tue, 21 Apr 2015 01:19:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB871B375F for ; Tue, 21 Apr 2015 01:19:20 -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.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150421081920.11081.15063.idtracker@ietfa.amsl.com> Date: Tue, 21 Apr 2015 01:19:20 -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: Tue, 21 Apr 2015 08:19:22 -0000 Changed milestone "Submit RFC793bis document to the IESG for publication as Internet Standard", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/tcpm/charter/ From nobody Tue Apr 21 12:39:41 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 18FB81B2ADA; Tue, 21 Apr 2015 12:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sHFbYOsMzZI; Tue, 21 Apr 2015 12:39:29 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id EFE5D1B2AD6; Tue, 21 Apr 2015 12:39:17 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3B046180207; Tue, 21 Apr 2015 12:38:21 -0700 (PDT) To: yirkajk@vcu.edu, fernando@gont.com.ar, ayourtch@cisco.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150421193821.3B046180207@rfc-editor.org> Date: Tue, 21 Apr 2015 12:38:21 -0700 (PDT) Archived-At: Cc: mls.ietf@gmail.com, tcpm@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] [Errata Rejected] RFC6093 (4312) 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, 21 Apr 2015 19:39:35 -0000 The following errata report has been rejected for RFC6093, "On the Implementation of the TCP Urgent Mechanism". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6093&eid=4312 -------------------------------------- Status: Rejected Type: Technical Reported by: Justin Yirka Date Reported: 2015-03-24 Rejected by: Martin Stiemerling (IESG) Section: 3.1 Original Text ------------- Unfortunately, virtually all TCP implementations process TCP urgent indications differently. By default, the last byte of "urgent data" is delivered "out of band" to the application. That is, it is not delivered as part of the normal data stream [UNPv1]. For example, the "out-of-band" byte is read by an application when a recv(2) system call with the MSG_OOB flag set is issued. Corrected Text -------------- Unfortunately, virtually all TCP implementations process TCP urgent indications differently. For example, by default in particular UNIX implementations, the last byte of "urgent data" is delivered "out of band" to the application. That is, it is not delivered as part of the normal data stream [UNPv1]. For example, the "out-of-band" byte is read by an application when a recv(2) system call with the MSG_OOB flag set is issued. Notes ----- The first and latter statements are contradictory, as a default is unlikely to apply when "virtually all" implementations process differently. This correction to include "in particular UNIX implementations" would be appropriate at many points throughout the document in order to differentiate references to implementation specific features and terminology from references to terminology established in prior RFCs. --VERIFIER NOTES-- Reading the text in a flow isn't giving the contradiction that there is a contradiction. -------------------------------------- RFC6093 (draft-ietf-tcpm-urgent-data-07) -------------------------------------- Title : On the Implementation of the TCP Urgent Mechanism Publication Date : January 2011 Author(s) : F. Gont, A. Yourtchenko Category : PROPOSED STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Wed Apr 22 01:53:51 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 4E7E21B2DD0 for ; Wed, 22 Apr 2015 01:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 rQ4ny9ozPa4P for ; Wed, 22 Apr 2015 01:53:47 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 C01331B317F for ; Wed, 22 Apr 2015 01:53:47 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id F3C7264C24692 for ; Wed, 22 Apr 2015 08:53:44 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t3M8rkwC010798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 22 Apr 2015 10:53:46 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 22 Apr 2015 10:53:46 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: Feedback on WG acceptance of draft-zimmermann-tcpm-cubic-01 Thread-Index: AdB82dct7bOB/OJdSd689asNJWANrg== Date: Wed, 22 Apr 2015 08:53:46 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C939DA@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic-01 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, 22 Apr 2015 08:53:50 -0000 Dear all, During IETF 91 [1] and on the list there has been strong support for WG ado= ption of draft-zimmermann-tcpm-cubic [2]. It seems consensus in TCPM to ado= pt this document. In order to move forward, the chairs seek for additional community guidance= regarding the intended status: a) Proposed standard b) Experimental c) Informational During IETF 91, there was strong support for Proposed Standard [1]. Yet, gi= ven the running code and the potential evolution of congestion control algo= rithms in future, the chairs want to ensure that there is strong consensus = in TCPM on the intended status. Also, we would like to handle this question= consistently among potential other alternative congestion control algorith= ms. Additional information regarding the RFC status can be found in [3], and th= ere is also an IESG statement on the difference between Experimental and In= formational [4]. Please let us know any feedback on the WG acceptance of draft-zimmermann-tc= pm-cubic-01 and specifically the intended status until May 8. Thanks! Michael, Pasi, Yoshifumi [1] http://www.ietf.org/proceedings/91/minutes/minutes-91-tcpm [2] https://tools.ietf.org/html/draft-zimmermann-tcpm-cubic-01 [2] RFC 2026, Section 4.1.1, 4.2.1, 4.2.2 [3] https://www.ietf.org/iesg/informational-vs-experimental.html From nobody Wed Apr 22 01:54:02 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 A932C1B3184 for ; Wed, 22 Apr 2015 01:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 b9tu7rRif-cE for ; Wed, 22 Apr 2015 01:53:56 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 D26831B31D0 for ; Wed, 22 Apr 2015 01:53:55 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 4FE36CBC828EA for ; Wed, 22 Apr 2015 08:53:52 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t3M8rsIJ014469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 22 Apr 2015 10:53:54 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 22 Apr 2015 10:53:54 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Thread-Topic: Feedback on WG acceptance of draft-bensley-tcpm-dctcp-03 Thread-Index: AdB82dvas/DQQ7w2TuSWSxKiXj5XLg== Date: Wed, 22 Apr 2015 08:53:54 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C939E2@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [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: Wed, 22 Apr 2015 08:53:59 -0000 Dear all, During IETF 89 [1] and on the list there has been a discussion about WG ado= ption of draft-bensley-tcpm-dctcp [2]. The understanding of the chairs is t= hat 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, et= c. The TCPM chairs believe that adoption of alternative congestion control alg= orithms 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-bensl= ey-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 From nobody Wed Apr 22 08:03: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 D5BEE1B33DF for ; Wed, 22 Apr 2015 03:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hycuvoDP4ydh for ; Wed, 22 Apr 2015 03:30:46 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 666601B33F4 for ; Wed, 22 Apr 2015 03:30:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BB103180206; Wed, 22 Apr 2015 03:29:34 -0700 (PDT) To: fernando@gont.com.ar, ayourtch@cisco.com, spencerdawkins.ietf@gmail.com, mls.ietf@gmail.com, michael.scharf@alcatel-lucent.com, nishida@sfc.wide.ad.jp, pasi.sarolahti@iki.fi X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150422102934.BB103180206@rfc-editor.org> Date: Wed, 22 Apr 2015 03:29:34 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Wed, 22 Apr 2015 08:03:24 -0700 Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] [Editorial Errata Reported] RFC6093 (4343) 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, 22 Apr 2015 10:30:48 -0000 The following errata report has been submitted for RFC6093, "On the Implementation of the TCP Urgent Mechanism". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6093&eid=4343 -------------------------------------- Type: Editorial Reported by: Andrew Yourtchenko Section: 3.1 Original Text ------------- As discussed in Section 2, the TCP urgent mechanism simply permits a point in the data stream to be designated as the end of urgent information but does NOT provide a mechanism for sending "out-of- band" data. Unfortunately, virtually all TCP implementations process TCP urgent indications differently. By default, the last byte of "urgent data" is delivered "out of band" to the application. That is, it is not delivered as part of the normal data stream [UNPv1]. For example, the "out-of-band" byte is read by an application when a recv(2) system call with the MSG_OOB flag set is issued. Corrected Text -------------- As discussed in Section 2, the TCP urgent mechanism simply permits a point in the data stream to be designated as the end of urgent information but does NOT provide a mechanism for sending "out-of- band" data. Unfortunately, virtually all TCP implementations process TCP urgent indications differently from that. By default, the last byte of "urgent data" is delivered "out of band" to the application. That is, it is not delivered as part of the normal data stream [UNPv1]. For example, the "out-of-band" byte is read by an application when a recv(2) system call with the MSG_OOB flag set is issued. Notes ----- Errata #4312 has uncovered that the second paragraph in section 3.1 can be interpreted incorrectly - as "all implementations differ from one another" vs. the intended "all implementations differ from the behavior described in the spec". This errata adds splits the sentence in question and adds the "from that" to its end in order to minimize this potential for misinterpretation when the second paragraph is read in isolation. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6093 (draft-ietf-tcpm-urgent-data-07) -------------------------------------- Title : On the Implementation of the TCP Urgent Mechanism Publication Date : January 2011 Author(s) : F. Gont, A. Yourtchenko Category : PROPOSED STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Thu Apr 23 09:22:53 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 0B6561A3BA3 for ; Thu, 23 Apr 2015 09:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 FTKkLqzASh4a for ; Thu, 23 Apr 2015 09:22:49 -0700 (PDT) Received: from zproxy220.enst-bretagne.fr (zproxy220.enst-bretagne.fr [192.108.117.9]) by ietfa.amsl.com (Postfix) with ESMTP id 97F831A6EF0 for ; Thu, 23 Apr 2015 09:22:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTP id 2A341301FB for ; Thu, 23 Apr 2015 18:22:41 +0200 (CEST) Received: from zproxy220.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy220.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id GoYI8PCvxTJb for ; Thu, 23 Apr 2015 18:22:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTP id 4E4BA301FD for ; Thu, 23 Apr 2015 18:22:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at zproxy220.enst-bretagne.fr Received: from zproxy220.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy220.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9vad-ftdgbwE for ; Thu, 23 Apr 2015 18:22:40 +0200 (CEST) Received: from [172.24.36.178] (c-89-160-21-91.cust.bredband2.com [89.160.21.91]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTPSA id 95327301FB for ; Thu, 23 Apr 2015 18:22:34 +0200 (CEST) From: Nicolas Kuhn Content-Type: multipart/alternative; boundary="Apple-Mail=_E234CAB6-EBD5-4349-892B-2C69F250A2DC" Message-Id: Date: Thu, 23 Apr 2015 18:22:23 +0200 To: tcpm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: Subject: [tcpm] last_max in CUBIC 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, 23 Apr 2015 16:22:52 -0000 --Apple-Mail=_E234CAB6-EBD5-4349-892B-2C69F250A2DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all,=20 We were currently working on CUBIC and LEDBAT in NS-2, using Michael = Welzl=E2=80=99s updated TCP Linux for NS-2=20 [http://www.ietf.org/mail-archive/web/iccrg/current/msg01160.html].=20 We see some strange behaviour in CUBIC=E2=80=99s window reduction, which = we wanted to share with you here. =E2=80=94 Topology =E2=80=94=20 The topology is a simple dumbbell topology with a bottleneck of 10Mbps = and an RTT of 100ms. The queue size of the router is set=20 to 42 packets (with DropTail). There are two non-application limited = bulk flows that randomly start within the first second of the = simulation.=20 Flow#1 is CUBIC (using ns-2.35/tcp/src/tcp_cubic.c version); Flow#2 is LEDBAT with a target delay of 5 ms or 25ms. =E2=80=94 Problem illustration =E2=80=94=20 In cwnd_case_1_default.pdf and cwnd_case_2_default.pdf, we plot the = congestion window evaluation and the=20 =E2=80=9Cnew last_max_cwnd=E2=80=9D, that is the W_last_max in the CUBIC = draft [https://datatracker.ietf.org/doc/draft-zimmermann-tcpm-cubic]. We recall here how CUBIC deals with fast convergence:=20 if (W_max < W_last_max){ =20 W_last_max =3D W_max; =20 W_max =3D W_max*(2-beta)/2; =20 } else { =20 W_last_max =3D W_max =20 } In the case with LEDBAT25, at 15s, W_last_max =E2=80=9Cshould=E2=80=9D = have been reduced, but we have W_max =3D=3D W_last_max, which makes that CUBIC does not reduce W_last_max and =E2=80=9Cloops=E2=80= =9D, would not have its expected behaviour. =20 =E2=80=94 Problem resolution =E2=80=94=20 Based on that observation, we have changed the following CUBIC code as = follows: =20 if (W_max < W_last_max){ =20 ->=20 if (W_max <=3D W_last_max){ =20 We plot the updated performance in cwnd_case_1_NK.pdf and = cwnd_case_2_NK.pdf. =20 =E2=80=94 Discussion =E2=80=94=20 We acknowledge that this effect may not occur often in real life and = might be a simulation artefact. However, we have been looking around and are wondering the = rationale of having if (W_max < W_last_max){ =20 instead of=20 if (W_max <=3D W_last_max){ =20 What do you think about it ? Why would not we change the =E2=80=98<=E2=80=98 for a =E2=80=98<=3D=E2=80=98= ? Kind regards, =20 Nicolas KUHN Emmanuel LOCHIN Si Quoc Viet TRANG= --Apple-Mail=_E234CAB6-EBD5-4349-892B-2C69F250A2DC Content-Type: multipart/mixed; boundary="Apple-Mail=_36CEB004-21A5-4692-B172-56A6C2400850" --Apple-Mail=_36CEB004-21A5-4692-B172-56A6C2400850 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all, 

We were currently working on CUBIC and LEDBAT in NS-2, using = Michael Welzl=E2=80=99s updated TCP Linux for NS-2 
[http://www.ietf.org/mail-archive/web/iccrg/current/msg01160.htm= l]. 
We see some strange behaviour in = CUBIC=E2=80=99s window reduction, which we wanted to share with you = here.

=E2=80=94 = Topology =E2=80=94 

The topology is a simple dumbbell topology with a bottleneck = of 10Mbps and an RTT of 100ms. The queue size of the router is = set 
to 42 packets (with DropTail). There are = two non-application limited bulk flows that randomly start within the = first second of the simulation. 
Flow#1 is = CUBIC (using ns-2.35/tcp/src/tcp_cubic.c version);
Flow#2 is LEDBAT with a target delay of 5 ms or = 25ms.

=E2=80=94 = Problem illustration =E2=80=94 

In cwnd_case_1_default.pdf and = cwnd_case_2_default.pdf, we plot the congestion window evaluation and = the 
=E2=80=9Cnew last_max_cwnd=E2=80=9D, that = is the W_last_max in the CUBIC draft [https://datatracker.ietf.org/doc/draft-zimmermann-tcpm-cubic].
= --Apple-Mail=_36CEB004-21A5-4692-B172-56A6C2400850 Content-Disposition: inline; filename=cwnd_case_1_default.pdf Content-Type: application/pdf; x-unix-mode=0644; name="cwnd_case_1_default.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nJVcTZNst23d96+4S2fhDknwc5vYlVVcZb9XlYXKC3kkuRyrXbYll/Lzg2+C rRm9GWvxiL4ACQLnkCDvHf/jSvd8JfpP/3153P79D+P68w+3r6525XT9EX/85pbuvbTrpxvc5/Xf Nza4/vBftwbraqNcjxvUlO+Nhe9vn9BY7MhmK7WRXCcYoDWM5LbS+z//fPvHLUtb/3l5XP/xGd2b V87X5+9u4nG+YN5z6f1qcG/QyvX5cfvVlf7t8//efvv59vvXJ0JOjYIG23cRX/PeFMV/0zvMdA67 j3c7X+4pp3X1ee/TnC/v8H6OGr0X8TXvTVG8N73DTL3ffXzU+wn34d7Xd3ifU+nbeZZe813VxHXV ijbquNt/1O8178sh09/jdx4jhl3lV303VfXeNE9Lm8Hu56NzyLne02wyh/meOUBZYQYkveq/qKn3 ohVtzHOzf6/fpd3nanDlsu4F1O+c3uN4nSk4TtKrjouaOi5a0cYcN/sPO17rHdzx93A1d8gHakR+ 1XlTVfdN87S0Kex+PjyJtu7VUJPfQ1ldw7ePv7DQY6snWQrPSbGQPhb3uu6QAa5a3r++T5yn7S7S fsPpnyua44fZ7uWDziOtV392vv2y8xn/506p8Ib7r6naBE7L0NMHp5Cpv9TOKeQvJCDDmuYWNd/y /0nNfQ823sNH/cYVMrdnv78U+z6rOUTNt/x+UnO/g4338FG/e7qPZ7+/tMzk5cXVw4S3fH9F1f0/ LENPH53DxOXlGTPlC7EvpXV3TIU35vCaqs3htAw9fXAOJc97ep4DfCEPpVUwt6j5lv9Pau57sPEe Pup37ff+jB/4UuxnsdWbm2/5/aTmfgcb7+Gjfo92L89+f2lngpz3Aq7CG76/pmr+n5ahpw/OAbC/ 9YyZ+oXYn2ehXywRXlP1OTyXCCZ/dA64bv5svW87D7bPl9kLF+JYSrTrn9++Ywjq/tc0Ti732uu8 xrzDyIvH+M//+d1vrq/+/tcff/gjjeVLCW6hFXlQ+j2ZO5//8vj2+kr02KeOXG0XT7yMhMolvc8j H6VgB2Pg/nBfdpJ5+def/vLiQ2CPP6k6Hn0xqjRiXl3XyVRVkJKnzUH1TsVcLTlVUbunIu2Wr56T t4b9SuksoQ2mP65ek7dMn/4lqnt7AbU7XCMl0eH25Fa9Ru7cWuEcq6dayNzu2Jry++TjbWWLWa7R VH/SSKOz/sQU9sUtPCcPnf/CkXDnoxZqrqy/8qiLtDt7N5PodzmK5srtfs2S9feB7WVt0oFB7Vyu WSWqPcNF+aJWxZZq53nNLrrLz7XYpj6mxLTz/OdK3K7cHvqEuE80pna/VlYLSNcqSVqkUVSfcYcH SZVIe1XgNlq3pL/TbFeb3CbL1c2CIr6GWNCpVC0q9zTZAvtbq3Or0nEJVIUImDM3B7MxT33C+JST ca+LBVCrRnyobNWowKtLmkJnzUqrLHZOS6Pm0Ly0ToLYIGXSNAvxYIkFj48OkNDlCJw0PV1OwJkz 1As2i6YI4ZqxcJMmK4HZsDu5ig3v6LmZFXqRu2apE7dHkuY9nLw74z7nyYKeypdaDVoDeKXsg5e1 ktRq0Fk1a6oGBr8UkCargSZrNBE5W8wEnJRZoX+liRV6V7rZLBLEgn0rg9PFAMAlSdM1ybfF6UIi YlNTPNEzSGLBwcJzkj5h36CIjZ/f+8TMAWi6OG0ZKqeLWZ2haYrnFFHO9kF8oECXA107WXQFMKo0 WWly9pZcFEzNHocZc8nZW3SITpo7REuuWWzY65rNhiNai9iwsxXMatA5XHNHp4PakjRZrWnueM3J tZOASyI2h9iMlO0GYCBEsTn0d3a0rqYix7UlYAFdbTnpE/o9T25iVFsxC3a0gVhwVFs1m0nCVAHD 2FqXJqt1yd7gIXIbmYVMTbXBOOU22SbzId4s2E1cSFmoIiwWWlRr27zJGNZxOz3o7hs3ZTZZpmYz VVFik0eIGgsWad7dLAcqVHs2d05FYCSMLGlM/iSCiQoGhZk0m8x0RQSbyLgfJRkbuGkMQoGJxtwa oII+g2rsGtA3t3B/9L6q33+NKgRUbg1mvnJr1INbo67NrUF3MUYmOvUpmQYtrDrHnsPcaYEUGg1Z BD1IsthpAGUNMyoNWauESmPEoNOC4umg46oQacy5aSRbuKVQaWnpXcuINBNsIsnm7pCYDGOGymRE KY2mZECI9CmKfOWy0TZx81UcTvZdbUyQriEOCX79N+Hw2cQmz/qOgAgatQl9R1QFCT3VIZ4SETSF E8ZOrgmMgsm4AVObG1ETBN6MNRUEkpPuy2wbEKHJPFfcX0zkvWcK9PxZ3VZNNjbdfSZt47L7SN2k u8+UjdeHpc1V3dGdURkyR/SbgOQzmmvvP3M5DxetuhaDJRW0RGflgyNYWlkQF4dKw8tXl8IQrJf2 doO1RNkZQSEkC2uGHImCZUPIK1YHeacci4NuPMHaYG2iYD3Q49KFJUExCGF7xG2HKoRNGJTWxh5m SZ5NsaTZGWcwacfug/IwaGMOs6A+6bPWjQOaUucKynVvQpxj34MwySlqsqS9jHSOYDfo5t3I229u d/v9nL3KHrlRPKbSlsgXXaTS1gsZLcNTrW2GA7UjUlxmGH065MeWitpWQ6W0Dcokbdq5xHzAf5oR RdvVokcLppAL22NzC6W1bVbefUmNY+RCucdx14wEQ2oV4xf+UzfBUBqbYSiFzY6UNstQ8uhge4XI QSl7rUJJasZudkXoKRkAKJ4Z4J3RuAbMT2EaPDENZC3SfAMtRc40aLD3JJTGgRnoYV8ip5xroKg0 tMHYTIMRmQZSBStiYZ1o5jtlZ1pNvomQuwcPainOkQoQ2CMOBs0n/tK9xR5RJPOu1rhGmFT9aQ3R EMkiV2sNUVXJ81Hr5pC0LaNVixLJt0ngT7sjSNqGNZT2Om+SI7jSGqXolnb3aHBOlR8mgcRRVjNn UpXTpum2GfuR46KyiQLm4/UVPbHtKYt0cqnOuuegpx2f4dpcaim88EQp7NqY6FDWIQwgsKlBZFPT elBj/+npF1yZWov8arqXSt64gPaMDuaeMGxQhJ1fQyKjSJD7l40TK9uEYTPVg2EzR4ZN28GYK5Nm 5gybshIoUrXgchxP8AIwzwPvUzLubKB7GuPYpPrWeTO77m1TpHCeynN44YdtOY7ZXjbl0B1028HH OfoekdrbN42V+q2Sz5gO7BYLbmsMxzgibLLlY469FkpbsmuVkjHRZMPOpHVLUSVtweKUWwHHqcqK 8DlTQL9IwpGpFwjGIJONbXN6UZjnKqeu7lDak+5PwreV4ogrFfeF7z+da0t3p6RW5ywW708yw5U3 15Ye84xtSw4DGpdVaojYKtO5tuho4LFdUl9p5JeW4MKrVcNRCiXRlHytg1mrZefVajHnqy3Hw5JS 2Tm1+nG8zWvsGnEx/gxhcsdnnFozMmrZTiV2K+C2JP2OQTmF8jKEF7n6c/SXRDESTpVELDWelFSf NEXeo1TntLbVt0+H/DCpm1VkkcsanZLo2lEip+20n+xMuMQ5QylbNrWtGCBp48MlxhJKxTAmbcMm SZtDLjG+UQJDvrYbaDvyx2VQzRGfSS1ulr1ubqE0NrdKGnmPPMKeitKMPs4a/ecbtyRW67j2K5nP VzLrLOcVjUeWmsa4hfIKscsl1IUlQ7j8K1mvK7pZytlCM5L1plFyBbwjKr9KqAwLtHDnV0B5ksVq HpcVBdbY+1apchvmKKp8TaQMwwMT7H0LpRXwV3WnEnTWmuK+VayKEpRXQbxZam1qLON6RFlW+1Hz oTz23oUHthJ4VodfnmF7xb2r1Jnj3uWy9zvLHpNvadRTjZbPQ2Wf9YQdD25rHOWK2KNssuVE6qM1 dlsyXOdxLnDZ0FLnxpG0DY0o7V3AJMV0pXO2412kIR/xbelh7e4x6YFbJhnzuIqzZ3qSMkut6pR5 LUXWtxR94YpPvcRkBOY1uWXV+VgtaLNt2fft0kp25jU9VxnzWgnX7uhtOqJ5VJEo9RD5Vv2uvVg1 KbxrWssb85pyVrLZDu7RG0RjXpO1yjHR+uZd6+H2o7RxnE9QDvViaYxPQ2CTvCjv2jp511aovDA/ 4fIdpXXwrme//yjyjm7zo8s+r7zrwmZnU2816rKk/chJY4/Rjnq28Ksu9V3aMkdsHxEw2WLHb8U0 rtzW6He5bfLcmCx55BdonmGRqj05cGOyIKy3cIEokmJWX7w5nk0W5Pe2AitEkl2MX705l/QNm7JJ 35xtu7H3SXm5JUx6enFV9D2UebYim/T1jrJJ39T4jEYaPtehe5fwiV8TeFRGCSeyMiByadTqTBqS LY/0GJtLI764Kov3QsvWqntVlMrPeKT3j5rxNWdEA8gLWuUSpHy8vfr09MsD5XLwC+W1+QUJwgoP qYbaEaW+0QtaO+lXr6mFqg7kQw1HPnBtIqzA9lERQhqBXSjNzS1IulOBWMq6bvsayiMy0WUdZ87o AUvqq0bQZ6KyRoBOLDs6c+3Yyl3zjvwMax9ItTTt2X5bSe2ICJerPg031SopNknayDXJMI9yMT5o uyd/sjnlkjIOuHbTZznVyDfQWk4Yh5IwWsbgm28fPcseJYyzr5iMcygv9zuXOKdcfG0Buz2XT76z 7lAWi6w7lMQp8w6ljIPMO1QTu1pCdLPuUBJ7qymZcZDb8a4Yctv5y5FzIO/4lXMoHfcdkPVmUHCR R2AcShE/eYaqEaXj9h4yZU3ZlXW3MlSW5JUYyBcCm18lR3YVuV1V3Bd+fWXsKvLCRtlV2nF7j/I6 uIgw2P30FEfske0mNX+afY7StmiUHm6GXEq+Oh2/PEj2GyhtS+aK5EOzapKhofC7ylp3WxBVut7J 5yA5RgufmFbebUG9vtNwTphs/Cl8LwiqO89nVJUrt4p+qOH9jLA/QpmhMkQpVIbofdqerZNZwCcv YRaksJMB2O6VRZoeByjHDSwA7HhBPepClMNLY7TIgVswIreA7gskPx/4/C3Pe8YgVfr6LXf+/O37 b7/509c/7m8XSS9++zbDp2/z+cs3+f6jjaWQevdHoKnRV4dXHvRHLfId3t++/en6/usffiRPyGLe J5lghKDO69dwh+vzN7dfPey59DjumIg6Lnv89f892ed87zhVt3857eu9uu1Pf/smhIH8xDCURVzU DwAxl5wE/QSQv7SgLzAe9oLa32qlcH+p7wv0md1e2gkx1elVSaVvgPwJ17PKwUTvnXz31bXD8p8p t/THdAO5Wdwnl6Dd8YdR852+2spUm+Lv4r20X/jjn0VHJP2l44F3bGMXsf1yMwlPBHdkits2XFGG 9qztl5uPa0/VLTWOPr/cvrPPV9od6OsAcRI3ow48VUIcjD1FmPx5rX4HE5+LTVDRPg+tPY53tMea k/3lMD9cqkgL+mM4Wln4qyb6Cyf6aFE/vlgSz4lqNXX/ZeBqXra5idQ3hsgkhBeGxG1xQaAxDVwi Yd82tj03R9U8+E0RNXM8IvBczVUkoc0UN6EZptrojy0DwPy52kQV6fXsxUcyrTAWrpkyWUHzI/xA Sx0dVZBefOE5BWXCJhFe6HU50Cz3Y9yCRzQ3mfsnA/shI9up/NIO6gIel/tX4eXmw9tjd0/NT/8p wPZ+vd/nlNfRJOLOlXXK9LE+zDDlgn3TXmmMjjpiF5Wk41NrD2ZaYbyKRdZOp4uKPax65l3ut5dg Ul9oGnax2Oo8VVOA1SJ4XRaEbVHw5+YKT18ADb/ugCuYv9ZB8J8DbD0YsNzlgKuKu9uce9IIB34F YYukPXcMb5WN4d3LHkq14ljrwNgj/KAgXHSDHzBsq76jeOJWXwOK6fVbJIHLhmL/QWFoHRhMdYSN Y3PBFNYTDdYTT74Lb9YMXPZDwBZWDhwgn/rEQ30+sew6jmVXClh2rT2cae3xSgpYe2xRoYjVeRVM C1RlO3UkYyGfBVH2OKVIBZcFaVsUILq5AlU3a8OxD+6PTyIcvlOA1d6gpc5uXOF4leltkx2ZuW0Y 9ueO4a2yMbx72QOpVhyrHQh7hB8EgnhgGXEd1urEEFzoZX5Yh3FVhUiBLSu+9g8CQO9AASr9O359 eHvcTgI8+c/hFQ8NTioGLNGhKa7DOEZ9Woe3jmF3K23sbi0fzLXCeAMpGLBrooGPLtIidrng29jt ZRzY7akf2DVZseuigs/MDZxSTjp2bXB77L6qefSdgyv2DilxNuCJ/lwiYLePcWLXnm/sukrArvey B1KtMBYeu+qB3f2DgI9vSAJ2tX427AK9vgvYhQQrYnfLiq39g4DPO1BwSv+OXR/eHrt7an76T+FV Dw1OKm4s4YhwYBfHSE/Y3TqG3a20sbu1fDDXCuNBQNdjiwo+PDS3WEPYkcTRC/QFZKgh8GRcIvhd FnxtUeDn5gpPP/IYft0BU4AT/of/HGDrwYDlLgdcFTzt7BoC6FIg1hD+3DG8VTaGdy97KNU6MNyk +LGzpcp8o4TFPf01vK6jPL/M91Aqvcj9LK+i8pgAWYK1ytK7Ip7kkfhoYeZ0R1e8d5UIwDK4P1Zf zfrwnaOrHYzCR4CH/VBK4hOAAA+jQHHxGUPmqKx+PzXMKuhox0c/YTDRiqPRH1L+7P/D5pW/Zvz9 7f8B1s7WeWVuZHN0cmVhbQplbmRvYmoKNiAwIG9iago0OTU1CmVuZG9iago0IDAgb2JqCjw8L1R5 cGUvUGFnZS9NZWRpYUJveCBbMCAwIDM2MCAxNzZdCi9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8 L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMCAwIFIKL0ZvbnQgMTEgMCBSCj4+Ci9D b250ZW50cyA1IDAgUgo+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL0tpZHMgWwo0 IDAgUgpdIC9Db3VudCAxCj4+CmVuZG9iagoxIDAgb2JqCjw8L1R5cGUgL0NhdGFsb2cgL1BhZ2Vz IDMgMCBSCi9NZXRhZGF0YSAxMyAwIFIKPj4KZW5kb2JqCjcgMCBvYmoKPDwvVHlwZS9FeHRHU3Rh dGUKL09QTSAxPj5lbmRvYmoKMTAgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTEgMCBvYmoK PDwvUjgKOCAwIFI+PgplbmRvYmoKOCAwIG9iago8PC9CYXNlRm9udC9aSkxCS1ErSGVsdmV0aWNh L0ZvbnREZXNjcmlwdG9yIDkgMCBSL1R5cGUvRm9udAovRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDEy MC9XaWR0aHNbCjI3OCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAo1NTYgNTU2IDU1NiA1 NTYgNTU2IDU1NiA1NTYgMCA1NTYgMCAwIDAgMCAwIDAgMAowIDAgMCA3MjIgNzIyIDAgMCAwIDAg MCAwIDAgMCAwIDcyMiAwCjAgMCAwIDAgNjExIDAgMCA5NDQgMCAwIDAgMjc4IDAgMjc4IDAgMAow IDU1NiA1NTYgNTAwIDU1NiA1NTYgMCAwIDAgMjIyIDAgNTAwIDIyMiA4MzMgNTU2IDAKNTU2IDAg MCA1MDAgMjc4IDU1NiAwIDcyMiA1MDBdCi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvU3VidHlw ZS9UeXBlMT4+CmVuZG9iago5IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUv WkpMQktRK0hlbHZldGljYS9Gb250QkJveFswIC0yMTggOTI5IDc0MV0vRmxhZ3MgMzIKL0FzY2Vu dCA3NDEKL0NhcEhlaWdodCA3NDEKL0Rlc2NlbnQgLTIxOAovSXRhbGljQW5nbGUgMAovU3RlbVYg MTM5Ci9NaXNzaW5nV2lkdGggMjc4Ci9YSGVpZ2h0IDUzOQovQ2hhclNldCgvQy9EL04vVC9XL2Ev Yi9icmFja2V0bGVmdC9icmFja2V0cmlnaHQvYy9kL2UvZWlnaHQvZml2ZS9mb3VyL2kvay9sL20v bi9vbmUvcC9zL3NpeC9zcGFjZS90L3RocmVlL3R3by91L3cveC96ZXJvKS9Gb250RmlsZTMgMTIg MCBSPj4KZW5kb2JqCjEyIDAgb2JqCjw8L0ZpbHRlci9GbGF0ZURlY29kZQovU3VidHlwZS9UeXBl MUMvTGVuZ3RoIDIzNjg+PnN0cmVhbQp4nJ1Ve1RU1Ro/h5k552RIynQgBedMgKSIgspLFFTecJlB ngaJiIJAzowIiErm1aw0d2q5Qs2bgXAVNUuw0K6Agg/EUtFAZEQezjCFSFfiWt+Z9nDv3YO1uv17 1zrrrP1Ye3/f7/v9vt+mKakNRdP0uKhsTXF2Ud6qTOvMW3SiRWcbcYoEYd2vvuZNsimUas+p8aLC lkK2EmQrrXAep7aH3onw6QuweQIlpWn/2NSPpyUnLJ0+Y4Zn6Nr8TQV5OblFyjne3n7KlZuUv+0o w7IL83J0SncyKM7WrM3XZuuK1HnalesLlYmZukJlrDIhO2e9JrPgT4t/3Pf/RaAoSqkLzQ8rLFq/ IXPjylVZ6uy8pDUa7VLv2XPm+vj6KQNeS6eoOMqNiqemUklUMpVCvUqFUKlUKBVGhVNeVAQVQ/lS sZSKUlMB1ETKnpJTL1I85UA5UjQ1iVpABVMvk0pSUnLgJM3S4XQ1/cjGzWapzSOJIFknaZBOkM6X 7pPWSttkUtlk2UZZDcMwrzC7WCnry37AUZyE28aVcQ1w0k5sRGViQntumf2dzuBe2NPjKD91Ryzn LeW9UMvKb/xy+c7Dm7WrYhX4Pz2ikjXEXHZXyL2DUKo2PYQzsnbm1UXd4lA3XTcgMXuIiNeBj5ce +6DpaIEmOS46NMcV4XEI21a7tYZdiW/LH0QQgZ48PgLJ3Axme+q2vM06bZwqLwhxeKoXcBADcQZg waX5UonuhHCs4JB2fxJHssS6MgjVix56+yZrnhcMjvKhJqzje+Eocy65vrAVceBsBBrmQ5gv2GBB kA+HoYQ1WSruPisfCmagJJb/4VognoifVwd6z0noghfghStd/QKBgLrF6910/4DoPCDpd4DPGYgF GShgAxRjKSiwSsCfMwOjTrx4HRax4HbPA6uxaqEHdhPsxJ1FnaJnJ33eAG8ZJGKMaMfvGom8iscT RHYLYj3m1WbBBK2g33j1zYpitHpSatrrIcuzDx4pVmw59M6hd6u5ucxePL41HqYQBC/13hjWZ5x1 /bsw/9PIv+mOoOpJ9WdPtN46rUvarbCDk0Xtokcr3dcjgX2EI19wC8BuYZHfWZRM8mndjSOHd39Q pbjD/nXn1l0liMvZVlotAH7IkvKRg2ll9jd6YG/Pog5H+bBY7CCWB+AGVpkY7hOd+eU3CpENsExj fW4k/qSQt3Si+mP1t7kQK79EHxvLaPGCA8wSy2UzGVeLp5voKZvKvGLxVJKBFwOelnLZI2ZY9PrZ 4iV7Fs27k641wMEeifhZPf/WezvQu4jTvXHoqAAt7EBkA+aD1euzchSF+du07y3lepl939Yc1yPu 3ldrU4X1LMot3hy9HY/bvGnHmi3qdZp0FMl53oz7+WZjRVOz4sPko0VN6DDav7tqH4fdIZJHa7eX FBTlaVa+kYa4mOyTjZdOV5kOCv0HPtlbdZDIZ+czEPA1VPIQBh8SGNgeJ2B7SJB5MhCKS7EKl8kG GZgE6eCI02VDjBWHVXAQXEY39cBFg6TJrOVHtR232C/Vjbp2QpfCRGQSAsF+T7EQ+mr+kiwBjrPg jsv5gWdKU/1Zab9r5SQRyhoY5ndc2Hpqw/Gc+tjjIUQtLt5YikNwkEkJLjDxfge8WCr4M2/6r8gM Q5xXUgdMAMcm/fd3zq0MKRX+N7ujBrhICr2dpBeAK5ncxsSqcHKf8xxM40Ac8RDT4NLWcOzG10LE XRaXiJm86coCgn98/Py5XuoHYAd2LQ++H2uEMnN4GX3PKCqMEvNkct9cywBjmSgOyNxHtUbRyIjj LUbZ07HadEJUK/h00mIpbOFR1zt1m8/kPZx/cTqJ7D4TS/BivNjkAtPAtqcVmHKCpChiWU4USkHL K9ee23Di7RO7LnK7W/l9Q83f9CKurzl6pmAHBYSo4af2N3sDiBHdBg+i8gBLeQ8j7zNrpf4uvSQy kCTZbho+HpDAL2YnHrZ3W27Pg7dHnQaYMaatEK6SFnnZWo9RbQ+sYB50QTiulo0w+HV4TDwmWqZk cAEukI1FtB5o7ZWAJzngP6olQcx3/+SK+dbPUf7F78bYzcpv3bvU0nr9i+woBR61LlinLaezoq1T cQo7mHJhWnhm8ZI0heZyZmUk4uTe4WjZuoxY7i5r92vYs5jmzQ6gMmtlrgyebOnHgWK/7BUG+5Hh FDJ0ZSBuVCv7iQF/8TEssDz+rbP0evqsCapNEqgyp/LRKE63Oi1dVeSJsCOH3+4imvYEj26Qw5ug WP/Dsm8VqxuWVEUhLkg6eN4TJ+L09JnTZy37EVIg5fzgoDD2AtBwwCiBA+Ju3rLbaE6NZzWY3rAZ O5dwsVb3QAaxlhA9zyQR9xh4y3PMR1c/qzZceNL00j+bLrQjA2ouvJR5JrP61cORaDaK0mSpC7K3 ZrwXyhmZPXUfHj9QUXH2H0cbEdd1LWFh4uuvxeYIXkvxNP8VUdux9yRR81ur3e20FwVThMlK/DrQ 8/uZ6vdlQw0ZfnOSUrxmLKsbeUcgXplQuvqTNacj7+QOkQZ0f2SAyabcBr/jgrzv5rFT9d9NBrvA duyEXRcG4Rk7FUbm/bN7K/cfKTtzrvIS4vTnly9M3aTNekMo3KbZodrFjaEHj/s0dJECdEEwj4ON EPz0vou4IobFHZYE2SwWLt7ncQEDBfDNGAd6MOjBy0CL80lB8gkJFhsmxeIge8B8Vf/5J5cRN9gc 4zJ1iWpG8LIzXcUk6QPxpWvL132Z3KbpIkm7PvkXeIBy1mPsnLpqi3alUAVpMqh7VgVo0UMCYXgQ asjl7xLBlQC38DamUBAKX535l4yIDT4I8+RFPbyoNrYm4bqGuCY4DT0BAV6aPYDl4Un5S7OF92Hx 5cfD6Do6m/VxJEesyJfva1ziOScuJnCeqvV747UWA+m2k89CfnYXCvX21aYYE+wiP/Kyik7ic3z7 15VfoFscSH06iVlMnBuEJdEVOe3LFfKRwKxV8QsmY4eh2fAyKH80gYN+VfO8Mwr5EOZgP99RlxER nZaxeNFr52611p3rEOQjuEFqvJYY4Lckyds37kpPT/PlfmsCOLfNXNNGf0vadQ/pPqz+92JQt7mZ a0aYP3bBvkdSgXN5UP+6GKtDR0Zr3Bi7ogqxvAxUZbEVjH5c3/P6D2xt+z6yHU9R/wXvYQ7ECmVu ZHN0cmVhbQplbmRvYmoKMTMgMCBvYmoKPDwvVHlwZS9NZXRhZGF0YQovU3VidHlwZS9YTUwvTGVu Z3RoIDE1MTA+PnN0cmVhbQo8P3hwYWNrZXQgYmVnaW49J++7vycgaWQ9J1c1TTBNcENlaGlIenJl U3pOVGN6a2M5ZCc/Pgo8P2Fkb2JlLXhhcC1maWx0ZXJzIGVzYz0iQ1JMRiI/Pgo8eDp4bXBtZXRh IHhtbG5zOng9J2Fkb2JlOm5zOm1ldGEvJyB4OnhtcHRrPSdYTVAgdG9vbGtpdCAyLjkuMS0xMywg ZnJhbWV3b3JrIDEuNic+CjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIycgeG1sbnM6aVg9J2h0dHA6Ly9ucy5hZG9iZS5jb20vaVgv MS4wLyc+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOjM3YmRhZjg2LTEwYTYtMTFm MC0wMDAwLTBkYjNjMWE0YWRmMycgeG1sbnM6cGRmPSdodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8x LjMvJyBwZGY6UHJvZHVjZXI9J0dQTCBHaG9zdHNjcmlwdCA5LjEwJy8+CjxyZGY6RGVzY3JpcHRp b24gcmRmOmFib3V0PSd1dWlkOjM3YmRhZjg2LTEwYTYtMTFmMC0wMDAwLTBkYjNjMWE0YWRmMycg eG1sbnM6eG1wPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJz48eG1wOk1vZGlmeURhdGU+ MjAxNS0wNC0wMVQxODoxMDo1MiswMjowMDwveG1wOk1vZGlmeURhdGU+Cjx4bXA6Q3JlYXRlRGF0 ZT5XZWQgLUFwLXIgVCAxOiAxOjg6MTA6OjIgPC94bXA6Q3JlYXRlRGF0ZT4KPHhtcDpDcmVhdG9y VG9vbD5nbnVwbG90IDUuMCBwYXRjaGxldmVsIDA8L3htcDpDcmVhdG9yVG9vbD48L3JkZjpEZXNj cmlwdGlvbj4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6MzdiZGFmODYtMTBhNi0x MWYwLTAwMDAtMGRiM2MxYTRhZGYzJyB4bWxuczp4YXBNTT0naHR0cDovL25zLmFkb2JlLmNvbS94 YXAvMS4wL21tLycgeGFwTU06RG9jdW1lbnRJRD0ndXVpZDozN2JkYWY4Ni0xMGE2LTExZjAtMDAw MC0wZGIzYzFhNGFkZjMnLz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6MzdiZGFm ODYtMTBhNi0xMWYwLTAwMDAtMGRiM2MxYTRhZGYzJyB4bWxuczpkYz0naHR0cDovL3B1cmwub3Jn L2RjL2VsZW1lbnRzLzEuMS8nIGRjOmZvcm1hdD0nYXBwbGljYXRpb24vcGRmJz48ZGM6dGl0bGU+ PHJkZjpBbHQ+PHJkZjpsaSB4bWw6bGFuZz0neC1kZWZhdWx0Jz5jd25kX2Nhc2VfMS5lcHM8L3Jk ZjpsaT48L3JkZjpBbHQ+PC9kYzp0aXRsZT48ZGM6Y3JlYXRvcj48cmRmOlNlcT48cmRmOmxpPm5p Y29sYXNrdWhuPC9yZGY6bGk+PC9yZGY6U2VxPjwvZGM6Y3JlYXRvcj48ZGM6ZGVzY3JpcHRpb24+ PHJkZjpTZXE+PHJkZjpsaT5nbnVwbG90IHBsb3Q8L3JkZjpsaT48L3JkZjpTZXE+PC9kYzpkZXNj cmlwdGlvbj48L3JkZjpEZXNjcmlwdGlvbj4KPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNrZXQgZW5kPSd3Jz8+CmVuZHN0cmVhbQpl bmRvYmoKMiAwIG9iago8PC9Qcm9kdWNlcihHUEwgR2hvc3RzY3JpcHQgOS4xMCkKL0NyZWF0aW9u RGF0ZShXZWQgQXByICAxIDE4OjEwOjUyIDIwMTUpCi9Nb2REYXRlKEQ6MjAxNTA0MDExODEwNTIr MDInMDAnKQovVGl0bGUoY3duZF9jYXNlXzEuZXBzKQovQ3JlYXRvcihnbnVwbG90IDUuMCBwYXRj aGxldmVsIDApCi9TdWJqZWN0KGdudXBsb3QgcGxvdCkKL0F1dGhvcihuaWNvbGFza3Vobik+PmVu ZG9iagp4cmVmCjAgMTQKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDA1MjcwIDAwMDAwIG4gCjAw MDAwMTAyMDkgMDAwMDAgbiAKMDAwMDAwNTIxMSAwMDAwMCBuIAowMDAwMDA1MDYwIDAwMDAwIG4g CjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwNTA0MCAwMDAwMCBuIAowMDAwMDA1MzM1IDAwMDAw IG4gCjAwMDAwMDU0MzYgMDAwMDAgbiAKMDAwMDAwNTgzMSAwMDAwMCBuIAowMDAwMDA1Mzc2IDAw MDAwIG4gCjAwMDAwMDU0MDYgMDAwMDAgbiAKMDAwMDAwNjE2OSAwMDAwMCBuIAowMDAwMDA4NjIy IDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgMTQgL1Jvb3QgMSAwIFIgL0luZm8gMiAwIFIKL0lE IFs8QUVFMEFDQzc3QThFRUYxRERCODg1RjU3NjMxQTA5ODM+PEFFRTBBQ0M3N0E4RUVGMUREQjg4 NUY1NzYzMUEwOTgzPl0KPj4Kc3RhcnR4cmVmCjEwNDM2CiUlRU9GCg== --Apple-Mail=_36CEB004-21A5-4692-B172-56A6C2400850 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
--Apple-Mail=_36CEB004-21A5-4692-B172-56A6C2400850 Content-Disposition: inline; filename=cwnd_case_2_default.pdf Content-Type: application/pdf; x-unix-mode=0644; name="cwnd_case_2_default.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nJVcS5Nlt23e319xls7CJ3w/tklcXjlV9kxVFiov5JbscqJ22ZZSys8PiBcB 9h1Nt7QY4ByQBD/g4+vw9j+ucMcrrP/535fXx7/+oV9/+fHxzVWvGK4/wsPvHuFuqV4/P/I9rt89 sMD1h98+ap5X7el6feQS4l1R+eHxCQpTuVVmG9Ue1MYUgNK5By1Ltf/zL49/PCLJ/M/L6/Vvn8G9 ccV4ff7zgzyOVx53TK1dNd8113R9fn386gr/8vm/H7/5/Pj9844sp3qCAtt3Up95L4bkv9i5YtyH Xce7nU93iGFebdxtiPPpHd6PXqz3pD7zXgzJe7Fzxdj7XcdHvR/57up9eYf3MaS2nUftme9sRq6z lS3Djmv5j/o9xz01Zdp7/I69W9hZf+q7mLL3YulLSg92PR/tQ4zlDqNSH8Z7+pDTND1Y2lP/yYy9 JytbRjyX8u/1O9V7zJqvmOadMvsdw3scLyMYx5f21HEyY8fJypYRx6X8hx0v5c7q+Hu4GluOLmtI f+q8mLL7YulLShd2PR/uRJ13kayJ76Esj+Hbx18Y6EFqgYZC3ylUwsdwL/POMeerpPeP7wP6KbML yV9w+q2hOO6K7Vo+6DzQerbT+frLzkf4T51i5QvuPzOVDviSpqYPdiGu+kL1XYhfCUDMc4hbS/yS /4eZ+m7KaA0f9RtGyFhPv7+GfRtFHFril/w+zNRvU0Zr+KjfLdz99Ptrw0ycurh6FeVLvj8xVf9d SVPTR/swYHg5cyZ9BfuUalPHWPlCH56ZSh98SVPTB/uQ4rjD2Yf8lTikWrK4tcQv+X+Yqe+mjNbw Ub9Lu9uZP/lr2I8kozeKX/L7MFO/TRmt4aN+93qn0++vzUw5xj2As/IF35+Ziv++pKnpg33IUN88 c6Z8BXu/F/rFJcIzU+3DuUQQ/aN9gHHzzXhfdxxknk+jJVyIw1KiXv/8/h1NrOp/vdqJ6S6tjKuP O/c4sY1//6///I/rm7//z08//nG1pUMJTKEFeJDaHcSdz399/f76huzQpwZcrRd2PPUAxim8zyNt JUEFvcP8cE/Zybz875/++qJNQI0/szlsfQHV1WKcjcfJUFihJU8dfa13CsRq0q5qyS0kkmu8Wgwq dXm6wpmMnMW+X60ElcR+/buorvLMS2756iGQDcoDpXL12FCaZh/Lu9ocUW4gDXo+cHtbsMRIV69s P1ZLvaH9gBC2iRLskzv3f0JLMPMtCSxn5KfY6lzWDb0bgewbbUVjQbldI0V+3kGeIi+b3Jcc0zUK odpivla8llRAYus4rtHIduq+FuRVxyBMG/Z/zIByQbnzm8X9ReMlt2tGLpHDNRPaA1ozsTVmHWwj WVu2s2SUoWwN/LyDPEhaFk3sF9qzk/3akbJ9wXoGlijL0zkbymVtljIbLfrFiOJY4uDnmJu0K25l opK5TF1cKFimrsVdwYAAhEBkjkctWKJhQOoSO0ektqVQCSBLGFKiY4lJJbB1aH4pjTa/gQPTaO8b MTYNGo2JgwOJGmHJhmJZopRAZ2KhEjiTxyplwIfYODptcboHEm+z426Y7zEOVHg3PrlUX9zHEbJ1 HM5S4FJ97VEjh6mDSylhlPoyyhymjtNEyhgnzH/okJQB71KlMuBbalJmLoVKoGepY6Aw9DAQcaCQ f7BLxlABAUHk8A7wLAcqs4wj7I/4DYKVE5Wpt+7c24DI5czhgsEp5lJIRKPKAR6DVNrTG/UVFHQ2 N65krs1/x0rmWm2PRCIaDY4ewgyxxOhNdLYEjh5kSyyRSq3nUcqAqyVRCUS0ZCmBzpbCsVu7glIx dnPt+ytFDsY+UBqLWKInfmNODjokKIhSZm3sZ2UFPKshk7hK1Bj4TSV1oAKO1iRl1uSRqQy6WYuU GaQOVhHGWlf8OkwCEcZoegNMjrVHFNMSuQSOP7EOKoEg1illijUstrZi2yGF/IvV+B1t92jVw10n hcGKzcCISuXnNiSicig78JxDjCLlQY/d5oiomEodkNUUI6XwczTK+sbm/VpCMCNQFA71NDeHes6b Qz1XLZG7qYlOvtC+pM2fXoprv2A/2bcaLId6TZtDncZS7VEd2tMWhDR9DXgKR2sKFA1cQpjek6JJ 447iTOMIkabTwCGk6cPGZ0yNHFFTScNUQ9oMT5ux+EB5MCiZhTYjGtqMFS7KnZGSpc1IXUgzclKj JUrhT1Z9ZYWazMk5k53fY0WVekQid3vkvCERJci7IhCTiFEYuew8FIVjOrJGm0TMkJGrzUJWJcUG TP+ceiQ26j9NEjwZiMpzxlrg8GzCIputjSA/L77Ems9plhm4QttVrxmaG6VZmOaZQTOqcGSsg0R2 s/sOjCgcGcNwZPCgThjMsVkyaXgUlsyoqM3k8JyMHHJkMn+YI3NNyRQFObKiAMFaodmBAxYFcc8u sCpoO8Qw+UchC8z8bXMFpv4ueQGTfbJcgfk+bLLw7M/ZBdN/tIkHehO+rDjtDAWtSfJCnMKmy4ra TnnQ5h5uIYhlMwa0IZSBbmPLMmSDni27RN/1tmLbRK2J7PvAuva4OTRQIwxTq5ZComssEg5bI20Z Y7tkG3jVOUVA75I9LGPCLdnmoupDvrD5J69b71x+SPazXDPLlj6qZ7LEdZ6+61Qjl+TFWhPU1zJM Whim5cUV8RM6EPYUBP8k36u11pEer+WMcAwexk2ymEPeLAOtOwzz+gxEPFsVGLQzzroUiYyTZJMy NEIzz7IwC+OXczCRzXu0BLm7LMhFpySQLcvyGpeYZZkmQc2rTDsEzbrcdAwHubsMzWsZztmb+7Az Abi4eZZ5cSlZX0I0jChIFWFaISYrf8riK3Ot0GGhcq20Zi1R41ook3cbrIt3ZWUze04y9bA0t4pV XZArK1sZU5QZ+0KZqnERnSJYmo0uaUXeuGwRnTKr4Dc8ybqyJ4MlW8apLvlfcOtE3CCZOFS65Veh mIndCLaGwRMWlaP9CrOIAmlaX3sM8WyalRxolLvEojLdyhCClbSvda1jmEP14FDlmYYwq7TKVh5V w6OaokG6pqwxqI5FNQcXr2p4VPMwLKq00qSYf3L669LcmhpW9LQ4I27VaplV6zSZVXleoLyrB7Nq p7eNtWlytw5qk7hVp51PmmNWc8yiQ5XNl0bLG+YWnhkos5pjFm/tpR7mkraJ/CFvSK77jemjaIRN IyZNsbSY8xkBx0M0ilxD9lBMSZY84KMEzhLRKKMafQ2PKmuG8pkDZ69olOd0AEEMIFmY03o0M1Nz rGqOVXJyILzCz05Sp2NVO1jVDKuaY1VzrGoHq7phVTesWkeNm1PdcaofnJJ9H7GqO1b1tEe2vjYP HJl+cKrzMp2iSEeXO8bd8ir2g0d9HX9xpnTHol6nG6G741HHPJL8645F3bGoOxZ1x6LBRxHCo4Gb f8p+2D0ZZuBGgBk0HIMGc0YtjxlpEGu61cS3wUxpTiv6dhg8huPRIK7oaGX0V9U4IgPZM7SknaMG s4fiPxyzcFOieTTcHDX4Rgpl5nDcGsigoZbRsGIwn4gzw7FLdj7Cr+H4NQ5+DcOvsdYgzK4xhm19 RusZrU+UX2Pute5Yp1favxnM9mp9WDBjzHT8muuUiBGb6+xHuTUdtyatdxT5SaM082safs0cTbym Y9c82LUOuYVbs3STIdMwa1baN0guzYNbE3cnxKzpmDUdsyYfcUj+zrFnhGmZlYJnVgqbWbDdM3us FDazUqAjbOFWCp5boPddi+XV0jbLVav6Vg8pWWYklrbnKtUQT9DmRpo0itCSd+xUwzingDzhHGAt yZudU6ph9oEWd16y1uXNresz1SphsA6jhC+sZbZzXEoBz7u51DCMBK3Y+jeTQDZM+uT0V9Ass0Bz zAK9775ZZsHmPisG0fIKNHe8mOJmFsiGWaANxTt6XoFeTWxi4mNOjFu0zAJNeQWyjXXcrErRsirF Gk2+RM+rFJs5uQBNWQXycBkZu54HgOxYleJmVYqTdm2S5ymY47qUDKuSY1UyrEoHq3CHvy2RR3O/ 8+2xLr7hLp79JrnsNw4L0QW5hGwiTJOdkZZmYiSaxDMRn+aW835jskc0ybPU9eCMZMnkpd26GlNN +JCQRcSUZBi1zDefkuFTcnxKjk+JVh/SFn3K2Z7MpAxKa/xU/iT6yiL+z+n6lg2HctgY5INBmT5a MIdydMd/oG8W5bXaUcyz41B2HMrZfVxK2bAoOxZlw6Jc3P46ZcejfPAoOx5lw6N88CgbHuVhzv9A 2yzKB4uKY1GhFTLx6JPTYZwryX18SoVOX5hbBU8IhVnFMauY2UrOF+a2NPMVnTaI58XMVny+oFgU N18V4tSUdxZ9OWGY3WoUUTpvkGgXN2PxCQPnTHFzFp4waBYWN2eVbueD4matgjwShhQ3axX+4pvZ srl308x2ZXimFse04phWDqYVw7TimFYc08rBtGqYVg3TKp72Cc+q41k9eFYNz6rjWXU8q45n9eBZ NTyr2X2TWlfU7r1uqQfXquNaxRN6YVp1TKtyMh1IM99zYRKhd8S16rhG11Ekm+u0XGt8ui+Z3yzb UjvY1Ry7mmMXnyts22OuorMF8qGZeaodY0Y7Zio8XWB0mpmlmv/yJ7pGhM4aKFrNzFJ8tqDxF12y BU8YOI9YjjTyqPYqMmWlnEJIzoou2d2QUb1tmRgjtymET81xrTmuNce1dnCtjc00vLkgrR08a3K2 HkmzTMOrAtKjg2ddztYjaebWBGiWa91xrR9ck2/SFInu2NbXtyLmWk9DY9cPpnX+LkZc6wfXuuNa P7jW1x0ezqXumNbp859yrTuudce17rjWHde641p3XBsH10bU77xpJMudkfXLVhqOZeNgmehcC/JK 63fzlpxBNKdR//DUQfs+DOP4zEERHG7eolMHicxw85acQVCsh5u38NRBc2a4eYtPHTgTh5u3BrJn qKWdtwazhxgyHJeGv3YEC72wLQ8uDcOlYbg0xrRtOyYNWsEol4bh0gzmZAY0y6TpmDQdkyZ+pSK8 6CuxsGg6Fk3+SiW4z82jT0Z7XfJm1VyXBzRy03FqHpyaRW8hgWzOudI0fJrVXURK82DUbDvfpuPT dHyi6307b9cFP+HTnNXOKTl4RuWwGZWDZRQsyZVRsCSn20ZJSnlOZTyDkFr2rJXl/IE9U72KN01v jrCMyOTgOaQ645vpFGL2LWOMspxBYCxV4yzIeApB+cEy/f6MzyAow0STzMx0CjHjljG7l3xr3qtW BKGudytAbv7d5hLIhpGgVVvn5hLIhks5WC6BVrzHm0s5Wi7laLkEmuFSptuUyqYcN5vWxXWDY8Rv vpVKeS5luU1BEcAL0BqdaBkEml5Jgo1cMNGNmz0gG/bkSLegOEui50+Onj+gK39Ani7zYlf+wLbR 8Qf0ncHx4E+yV/oAx82e5NiTDHvSwR48Z9iWdgbKcsqg7dk5KCc7CohGF/G39iqy4MAnEIpTOtiF pxCMd7LzU5YziJGsJrGmEwnKg2Tnp5yEUdNqkoV4CsH5mez8tDTM5N6sJuxIyCniTTL8SngnVtiV DLuSY1dy7Eqj27boHur2hL5bRZItuxJ/tSL/c3CnNKAX5dcyEQzywa7M362IX9nxKxt+5YNf2fEr O35lx69s+JUdv7LhVy7uVCtnx7B8MCy3aPIqG37lg1/Z8Csf/MqGX9nz6wO/rYBlc6j9KuunFbHh byt++P67P337k/lF2DK0v6wY5ocV4/xdBX1mll9WQAqtHq1XP6zLHPGqfX7Qx7QG2LXN7evH1PT7 j799//P1w7c//rR8XCXGPVaREm4IxfXrfOfr83ePX73Ke6qx3yuz+iWvv/2/ozxsQhugoOVffPly Fy3789++MwAtPwGgtfjQH57AiIVRmXIvtsjd4HWHMu4E1EtjfmhLcvsyrkCtP7vQW7xxfORaRMdf T8yrQ/fXPf/YyvqZ4oUtsvyC18nn4hI/Wd/x+y4sKtX98lAdFiklXlp6XXlIXDfLLw9tWd6Ko1TY +/3y+LNch543JPEraeunNpHO2tqEOHbbUdj/t12Ds+Fy1ojq9TVpW2Jl2lufFHuV9apoJaxOXWOR Eb9iJewFh461l8eA9Cyh6ZM+CnaWi4u66gagRIMNIgyLWnYNSF3rZu3loW3Le3GUixu/F6pSvEKn h8myCV3mnoZ+D9NVyNC4v+fb91TGmlCt3kpbUqvdFgzngVIo0cXh/WCN0bgSw9SLFcY0vEPBPCD1 Zd3WxPzZBrFRIkkFomMLqwA/WAd2Be89UQXrqlPaLbC6CrALYiAuSgW+Dwtk9TJEyih9UKYkFLSL 6ba7vubJtRQ0rFYbKmeNqGpvtZsTK9PeuhSVLNT6gJEqsNYNBmq6LadAF2hlGqBLHC5SqgvQ8kBw kgoER6x/wyzNy2txT4p7/xFmvs8nvSbVdHlNoNlCXCCUzUOsNgqxGhmI1Wo3JlamvX5C3A+I2wFx 8xC3A+J2QNxOiNsBcTsgbh7idkDcD4j7W4ibh7idELcT4vYW4vYG4vYE4vYG4vYE4gkuugFDHzBG ePphIJZbNgrygInIDhgDJjcbI9UFZHkgKEkFgqLc21GYxQUxEBelAt8HhFm81L7LA9P1AQC5AWPA zHUMGGqjUKuRgVqtdnNitdtL8YB6PyCkUvBQ66ULgToFD3UKHuqtMxD6gJHSChhJaUGhVhfEIHqo jz4sqNVL6bs+MF0PB9TQzgn1thGot9GGelvt5p5AvT6w2oFjP2CkYJdkBw7+Eq9AJ8DJDBwpAY42 UqoL0PJAcJIKBEf6tq8wS/PyWtyT4t5/hJk81F6TarqcSnYDR1pX7f3AsW0UYjUyEKvVbkysTHv1 hLgeEJcD4uIhLgfE5YC4nBCXA+JyQFw8xOWAuB4Q17cQFw9xOSEuJ8TlLcTlDcTlCcTlDcTlCcT9 hLgfELcD4uYhbgfE7YC4nRC3A+J2QNw8xO2AuB8Q97cQNw9xOyFuJ8TtLcTtDcTtCcTtDcTtCcQT XHRjsj5gjPCiooFYPsIoyKNENyaPFFyMVBeQ5YGgJBUIinL5VGEWF8RAXJQKfB8QZv1UJH2XB6br AwByY/K6oXmMyWqjUKuRgVqtdnNitdvL8YB6PyCkcvBQ61m9QJ2DhzoHD/XWGQh9wEhpBYyktKBQ qwtiED3URx8W1Oql9F0fmK6HA+oc3kC9bQTqbbSh3la7uSdQ51jdwLEfMFJpFjtw8OmHAg1jrR04 ckpuE7l1AVoeCE5SgeBIR8UKszQvr8U9Ke79R5jJQ+01qabLaf0ZOgsx0OIYOLaNQqxGBmK12o2J lc3mSpkgB0+sp3XqOcu1/kQbTWO4XoIt7UoK1laijUiTWOZUD7RM4NKsU+3LnPUe8OxCigNglKaB 7zQxvty4vmZfpbTzHdHlCiDc64zhVR6ssMYkCToo9bTHmRKPz9q2hZQyNlyxq8c0Rla2tfXXfd78 YdUnf2Ln94//B8uaq0dlbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKNTU4OQplbmRvYmoKNCAwIG9i ago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCAzNjAgMTc2XQovUGFyZW50IDMgMCBSCi9SZXNv dXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTAgMCBSCi9Gb250IDExIDAg Ugo+PgovQ29udGVudHMgNSAwIFIKPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9L aWRzIFsKNCAwIFIKXSAvQ291bnQgMQo+PgplbmRvYmoKMSAwIG9iago8PC9UeXBlIC9DYXRhbG9n IC9QYWdlcyAzIDAgUgovTWV0YWRhdGEgMTMgMCBSCj4+CmVuZG9iago3IDAgb2JqCjw8L1R5cGUv RXh0R1N0YXRlCi9PUE0gMT4+ZW5kb2JqCjEwIDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEx IDAgb2JqCjw8L1I4CjggMCBSPj4KZW5kb2JqCjggMCBvYmoKPDwvQmFzZUZvbnQvWkpMQktRK0hl bHZldGljYS9Gb250RGVzY3JpcHRvciA5IDAgUi9UeXBlL0ZvbnQKL0ZpcnN0Q2hhciAzMi9MYXN0 Q2hhciAxMjAvV2lkdGhzWwoyNzggMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKNTU2IDU1 NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDAgNTU2IDAgMCAwIDAgMCAwIDAKMCAwIDAgNzIyIDcyMiAw IDAgMCAwIDAgMCAwIDAgMCA3MjIgMAowIDAgMCAwIDYxMSAwIDAgOTQ0IDAgMCAwIDI3OCAwIDI3 OCAwIDAKMCA1NTYgNTU2IDUwMCA1NTYgNTU2IDAgMCAwIDIyMiAwIDUwMCAyMjIgODMzIDU1NiAw CjU1NiAwIDAgNTAwIDI3OCA1NTYgMCA3MjIgNTAwXQovRW5jb2RpbmcvV2luQW5zaUVuY29kaW5n L1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKOSAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0Zv bnROYW1lL1pKTEJLUStIZWx2ZXRpY2EvRm9udEJCb3hbMCAtMjE4IDkyOSA3NDFdL0ZsYWdzIDMy Ci9Bc2NlbnQgNzQxCi9DYXBIZWlnaHQgNzQxCi9EZXNjZW50IC0yMTgKL0l0YWxpY0FuZ2xlIDAK L1N0ZW1WIDEzOQovTWlzc2luZ1dpZHRoIDI3OAovWEhlaWdodCA1MzkKL0NoYXJTZXQoL0MvRC9O L1QvVy9hL2IvYnJhY2tldGxlZnQvYnJhY2tldHJpZ2h0L2MvZC9lL2VpZ2h0L2ZpdmUvZm91ci9p L2svbC9tL24vb25lL3Avcy9zaXgvc3BhY2UvdC90aHJlZS90d28vdS93L3gvemVybykvRm9udEZp bGUzIDEyIDAgUj4+CmVuZG9iagoxMiAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUKL1N1YnR5 cGUvVHlwZTFDL0xlbmd0aCAyMzY4Pj5zdHJlYW0KeJydVXtUVNUaP4eZOedkSMp0IAXnTICkiILK SxRU3nCZQZ4GiYiCQM6MCIhK5tWsNHdquULNm4FwFTVLsNCugIIPxFLRQGREHs4whUhX4lrfmfZw 792Dtbr9e9c666z9WHt/3+/7/b7fpimpDUXT9LiobE1xdlHeqkzrzFt0okVnG3GKBGHdr77mTbIp lGrPqfGiwpZCthJkK61wHqe2h96J8OkLsHkCJaVp/9jUj6clJyydPmOGZ+ja/E0FeTm5Rco53t5+ ypWblL/tKMOyC/NydEp3MijO1qzN12britR52pXrC5WJmbpCZawyITtnvSaz4E+Lf9z3/0WgKEqp C80PKyxavyFz48pVWersvKQ1Gu1S79lz5vr4+ikDXkunqDjKjYqnplJJVDKVQr1KhVCpVCgVRoVT XlQEFUP5UrGUilJTAdREyp6SUy9SPOVAOVI0NYlaQAVTL5NKUlJy4CTN0uF0Nf3Ixs1mqc0jiSBZ J2mQTpDOl+6T1krbZFLZZNlGWQ3DMK8wu1gp68t+wFGchNvGlXENcNJObERlYkJ7bpn9nc7gXtjT 4yg/dUcs5y3lvVDLym/8cvnOw5u1q2IV+D89opI1xFx2V8i9g1CqNj2EM7J25tVF3eJQN103IDF7 iIjXgY+XHvug6WiBJjkuOjTHFeFxCNtWu7WGXYlvyx9EEIGePD4CydwMZnvqtrzNOm2cKi8IcXiq F3AQA3EGYMGl+VKJ7oRwrOCQdn8SR7LEujII1Yseevsma54XDI7yoSas43vhKHMuub6wFXHgbAQa 5kOYL9hgQZAPh6GENVkq7j4rHwpmoCSW/+FaIJ6In1cHes9J6IIX4IUrXf0CgYC6xevddP+A6Dwg 6XeAzxmIBRkoYAMUYykosErAnzMDo068eB0WseB2zwOrsWqhB3YT7MSdRZ2iZyd93gBvGSRijGjH 7xqJvIrHE0R2C2I95tVmwQStoN949c2KYrR6Umra6yHLsw8eKVZsOfTOoXerubnMXjy+NR6mEAQv 9d4Y1mecdf27MP/TyL/pjqDqSfVnT7TeOq1L2q2wg5NF7aJHK93XI4F9hCNfcAvAbmGR31mUTPJp 3Y0jh3d/UKW4w/5159ZdJYjL2VZaLQB+yJLykYNpZfY3emBvz6IOR/mwWOwglgfgBlaZGO4Tnfnl NwqRDbBMY31uJP6kkLd0ovpj9be5ECu/RB8by2jxggPMEstlMxlXi6eb6Cmbyrxi8VSSgRcDnpZy 2SNmWPT62eIlexbNu5OuNcDBHon4WT3/1ns70LuI071x6KgALexAZAPmg9Xrs3IUhfnbtO8t5XqZ fd/WHNcj7t5Xa1OF9SzKLd4cvR2P27xpx5ot6nWadBTJed6M+/lmY0VTs+LD5KNFTegw2r+7ah+H 3SGSR2u3lxQU5WlWvpGGuJjsk42XTleZDgr9Bz7ZW3WQyGfnMxDwNVTyEAYfEhjYHidge0iQeTIQ ikuxCpfJBhmYBOngiNNlQ4wVh1VwEFxGN/XARYOkyazlR7Udt9gv1Y26dkKXwkRkEgLBfk+xEPpq /pIsAY6z4I7L+YFnSlP9WWm/a+UkEcoaGOZ3XNh6asPxnPrY4yFELS7eWIpDcJBJCS4w8X4HvFgq +DNv+q/IDEOcV1IHTADHJv33d86tDCkV/je7owa4SAq9naQXgCuZ3MbEqnByn/McTONAHPEQ0+DS 1nDsxtdCxF0Wl4iZvOnKAoJ/fPz8uV7qB2AHdi0Pvh9rhDJzeBl9zygqjBLzZHLfXMsAY5koDsjc R7VG0ciI4y1G2dOx2nRCVCv4dNJiKWzhUdc7dZvP5D2cf3E6iew+E0vwYrzY5ALTwLanFZhygqQo YllOFEpByyvXnttw4u0Tuy5yu1v5fUPN3/Qirq85eqZgBwWEqOGn9jd7A4gR3QYPovIAS3kPI+8z a6X+Lr0kMpAk2W4aPh6QwC9mJx62d1tuz4O3R50GmDGmrRCukhZ52VqPUW0PrGAedEE4rpaNMPh1 eEw8JlqmZHABLpCNRbQeaO2VgCc54D+qJUHMd//kivnWz1H+xe/G2M3Kb9271NJ6/YvsKAUetS5Y py2ns6KtU3EKO5hyYVp4ZvGSNIXmcmZlJOLk3uFo2bqMWO4ua/dr2LOY5s0OoDJrZa4Mnmzpx4Fi v+wVBvuR4RQydGUgblQr+4kBf/ExLLA8/q2z9Hr6rAmqTRKoMqfy0ShOtzotXVXkibAjh9/uIpr2 BI9ukMOboFj/w7JvFasbllRFIS5IOnjeEyfi9PSZ02ct+xFSIOX84KAw9gLQcMAogQPibt6y22hO jWc1mN6wGTuXcLFW90AGsZYQPc8kEfcYeMtzzEdXP6s2XHjS9NI/my60IwNqLryUeSaz+tXDkWg2 itJkqQuyt2a8F8oZmT11Hx4/UFFx9h9HGxHXdS1hYeLrr8XmCF5L8TT/FVHbsfckUfNbq93ttBcF U4TJSvw60PP7mer3ZUMNGX5zklK8ZiyrG3lHIF6ZULr6kzWnI+/kDpEGdH9kgMmm3Aa/44K87+ax U/XfTQa7wHbshF0XBuEZOxVG5v2zeyv3Hyk7c67yEuL055cvTN2kzXpDKNym2aHaxY2hB4/7NHSR AnRBMI+DjRD89L6LuCKGxR2WBNksFi7e53EBAwXwzRgHejDowctAi/NJQfIJCRYbJsXiIHvAfFX/ +SeXETfYHOMydYlqRvCyM13FJOkD8aVry9d9mdym6SJJuz75F3iActZj7Jy6aot2pVAFaTKoe1YF aNFDAmF4EGrI5e8SwZUAt/A2plAQCl+d+ZeMiA0+CPPkRT28qDa2JuG6hrgmOA09AQFemj2A5eFJ +Uuzhfdh8eXHw+g6Opv1cSRHrMiX72tc4jknLiZwnqr1e+O1FgPptpPPQn52Fwr19tWmGBPsIj/y sopO4nN8+9eVX6BbHEh9OolZTJwbhCXRFTntyxXykcCsVfELJmOHodnwMih/NIGDflXzvDMK+RDm YD/fUZcREZ2WsXjRa+dutdad6xDkI7hBaryWGOC3JMnbN+5KT0/z5X5rAji3zVzTRn9L2nUP6T6s /vdiULe5mWtGmD92wb5HUoFzeVD/uhirQ0dGa9wYu6IKsbwMVGWxFYx+XN/z+g9sbfs+sh1PUf8F 72EOxAplbmRzdHJlYW0KZW5kb2JqCjEzIDAgb2JqCjw8L1R5cGUvTWV0YWRhdGEKL1N1YnR5cGUv WE1ML0xlbmd0aCAxNTEwPj5zdHJlYW0KPD94cGFja2V0IGJlZ2luPSfvu78nIGlkPSdXNU0wTXBD ZWhpSHpyZVN6TlRjemtjOWQnPz4KPD9hZG9iZS14YXAtZmlsdGVycyBlc2M9IkNSTEYiPz4KPHg6 eG1wbWV0YSB4bWxuczp4PSdhZG9iZTpuczptZXRhLycgeDp4bXB0az0nWE1QIHRvb2xraXQgMi45 LjEtMTMsIGZyYW1ld29yayAxLjYnPgo8cmRmOlJERiB4bWxuczpyZGY9J2h0dHA6Ly93d3cudzMu b3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMnIHhtbG5zOmlYPSdodHRwOi8vbnMuYWRvYmUu Y29tL2lYLzEuMC8nPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDozODU2NDYwNi0x MGE2LTExZjAtMDAwMC00ZGYyZTMwMDFlZDQnIHhtbG5zOnBkZj0naHR0cDovL25zLmFkb2JlLmNv bS9wZGYvMS4zLycgcGRmOlByb2R1Y2VyPSdHUEwgR2hvc3RzY3JpcHQgOS4xMCcvPgo8cmRmOkRl c2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDozODU2NDYwNi0xMGE2LTExZjAtMDAwMC00ZGYyZTMw MDFlZDQnIHhtbG5zOnhtcD0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyc+PHhtcDpNb2Rp ZnlEYXRlPjIwMTUtMDQtMDFUMTg6MTA6NTMrMDI6MDA8L3htcDpNb2RpZnlEYXRlPgo8eG1wOkNy ZWF0ZURhdGU+V2VkIC1BcC1yIFQgMTogMTo4OjEwOjozIDwveG1wOkNyZWF0ZURhdGU+Cjx4bXA6 Q3JlYXRvclRvb2w+Z251cGxvdCA1LjAgcGF0Y2hsZXZlbCAwPC94bXA6Q3JlYXRvclRvb2w+PC9y ZGY6RGVzY3JpcHRpb24+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOjM4NTY0NjA2 LTEwYTYtMTFmMC0wMDAwLTRkZjJlMzAwMWVkNCcgeG1sbnM6eGFwTU09J2h0dHA6Ly9ucy5hZG9i ZS5jb20veGFwLzEuMC9tbS8nIHhhcE1NOkRvY3VtZW50SUQ9J3V1aWQ6Mzg1NjQ2MDYtMTBhNi0x MWYwLTAwMDAtNGRmMmUzMDAxZWQ0Jy8+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlk OjM4NTY0NjA2LTEwYTYtMTFmMC0wMDAwLTRkZjJlMzAwMWVkNCcgeG1sbnM6ZGM9J2h0dHA6Ly9w dXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJyBkYzpmb3JtYXQ9J2FwcGxpY2F0aW9uL3BkZic+PGRj OnRpdGxlPjxyZGY6QWx0PjxyZGY6bGkgeG1sOmxhbmc9J3gtZGVmYXVsdCc+Y3duZF9jYXNlXzIu ZXBzPC9yZGY6bGk+PC9yZGY6QWx0PjwvZGM6dGl0bGU+PGRjOmNyZWF0b3I+PHJkZjpTZXE+PHJk ZjpsaT5uaWNvbGFza3VobjwvcmRmOmxpPjwvcmRmOlNlcT48L2RjOmNyZWF0b3I+PGRjOmRlc2Ny aXB0aW9uPjxyZGY6U2VxPjxyZGY6bGk+Z251cGxvdCBwbG90PC9yZGY6bGk+PC9yZGY6U2VxPjwv ZGM6ZGVzY3JpcHRpb24+PC9yZGY6RGVzY3JpcHRpb24+CjwvcmRmOlJERj4KPC94OnhtcG1ldGE+ CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0ndyc/PgplbmRz dHJlYW0KZW5kb2JqCjIgMCBvYmoKPDwvUHJvZHVjZXIoR1BMIEdob3N0c2NyaXB0IDkuMTApCi9D cmVhdGlvbkRhdGUoV2VkIEFwciAgMSAxODoxMDo1MyAyMDE1KQovTW9kRGF0ZShEOjIwMTUwNDAx MTgxMDUzKzAyJzAwJykKL1RpdGxlKGN3bmRfY2FzZV8yLmVwcykKL0NyZWF0b3IoZ251cGxvdCA1 LjAgcGF0Y2hsZXZlbCAwKQovU3ViamVjdChnbnVwbG90IHBsb3QpCi9BdXRob3Iobmljb2xhc2t1 aG4pPj5lbmRvYmoKeHJlZgowIDE0CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDAwNTkwNCAwMDAw MCBuIAowMDAwMDEwODQzIDAwMDAwIG4gCjAwMDAwMDU4NDUgMDAwMDAgbiAKMDAwMDAwNTY5NCAw MDAwMCBuIAowMDAwMDAwMDE1IDAwMDAwIG4gCjAwMDAwMDU2NzQgMDAwMDAgbiAKMDAwMDAwNTk2 OSAwMDAwMCBuIAowMDAwMDA2MDcwIDAwMDAwIG4gCjAwMDAwMDY0NjUgMDAwMDAgbiAKMDAwMDAw NjAxMCAwMDAwMCBuIAowMDAwMDA2MDQwIDAwMDAwIG4gCjAwMDAwMDY4MDMgMDAwMDAgbiAKMDAw MDAwOTI1NiAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDE0IC9Sb290IDEgMCBSIC9JbmZvIDIg MCBSCi9JRCBbPEU1QjhFODgxOTM0MkQxNTQxRDI2MUUwNkREOTkxRDA2PjxFNUI4RTg4MTkzNDJE MTU0MUQyNjFFMDZERDk5MUQwNj5dCj4+CnN0YXJ0eHJlZgoxMTA3MAolJUVPRgo= --Apple-Mail=_36CEB004-21A5-4692-B172-56A6C2400850 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

We recall here how CUBIC deals with = fast convergence: 

      if (W_max < = W_last_max){     
    =       W_last_max =3D W_max;       =  
          W_max =3D = W_max*(2-beta)/2;   
      = } else {   
        =   W_last_max =3D W_max  
    =   }

In the case with LEDBAT25, at 15s, W_last_max =E2=80=9Cshould=E2= =80=9D have been reduced, but we have  W_max =3D=3D = W_last_max,
which makes that CUBIC does not reduce = W_last_max and =E2=80=9Cloops=E2=80=9D, would not have its expected = behaviour.  

=E2=80=94 Problem resolution =E2=80=94 

Based on that = observation, we have changed the following CUBIC code as = follows:
 
    =   if (W_max < W_last_max){     
-> 
    =   if (W_max <=3D W_last_max){    

We plot the updated = performance in cwnd_case_1_NK.pdf and cwnd_case_2_NK.pdf.

 
= --Apple-Mail=_36CEB004-21A5-4692-B172-56A6C2400850 Content-Disposition: inline; filename=cwnd_case_1_NK.pdf Content-Type: application/pdf; x-unix-mode=0644; name="cwnd_case_1_NK.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nJVcTZNst23d96+4S2fhDknwc5vYlVVcZb9XlYXKC3kkuRyrXbYll/Lzg2+C rRm9GWvxiL4ACQLnkCDvHf/jSvd8JfpP/3153P79D+P68w+3r6525XT9EX/85pbuvbTrpxvc5/Xf Nza4/vBftwbraqNcjxvUlO+Nhe9vn9BY7MhmK7WRXCcYoDWM5LbS+z//fPvHLUtb/3l5XP/xGd2b V87X5+9u4nG+YN5z6f1qcG/QyvX5cfvVlf7t8//efvv59vvXJ0JOjYIG23cRX/PeFMV/0zvMdA67 j3c7X+4pp3X1ee/TnC/v8H6OGr0X8TXvTVG8N73DTL3ffXzU+wn34d7Xd3ifU+nbeZZe813VxHXV ijbquNt/1O8178sh09/jdx4jhl3lV303VfXeNE9Lm8Hu56NzyLne02wyh/meOUBZYQYkveq/qKn3 ohVtzHOzf6/fpd3nanDlsu4F1O+c3uN4nSk4TtKrjouaOi5a0cYcN/sPO17rHdzx93A1d8gHakR+ 1XlTVfdN87S0Kex+PjyJtu7VUJPfQ1ldw7ePv7DQY6snWQrPSbGQPhb3uu6QAa5a3r++T5yn7S7S fsPpnyua44fZ7uWDziOtV392vv2y8xn/506p8Ib7r6naBE7L0NMHp5Cpv9TOKeQvJCDDmuYWNd/y /0nNfQ823sNH/cYVMrdnv78U+z6rOUTNt/x+UnO/g4338FG/e7qPZ7+/tMzk5cXVw4S3fH9F1f0/ LENPH53DxOXlGTPlC7EvpXV3TIU35vCaqs3htAw9fXAOJc97ep4DfCEPpVUwt6j5lv9Pau57sPEe Pup37ff+jB/4UuxnsdWbm2/5/aTmfgcb7+Gjfo92L89+f2lngpz3Aq7CG76/pmr+n5ahpw/OAbC/ 9YyZ+oXYn2ehXywRXlP1OTyXCCZ/dA64bv5svW87D7bPl9kLF+JYSrTrn9++Ywjq/tc0Ti732uu8 xrzDyIvH+M//+d1vrq/+/tcff/gjjeVLCW6hFXlQ+j2ZO5//8vj2+kr02KeOXG0XT7yMhMolvc8j H6VgB2Pg/nBfdpJ5+def/vLiQ2CPP6k6Hn0xqjRiXl3XyVRVkJKnzUH1TsVcLTlVUbunIu2Wr56T t4b9SuksoQ2mP65ek7dMn/4lqnt7AbU7XCMl0eH25Fa9Ru7cWuEcq6dayNzu2Jry++TjbWWLWa7R VH/SSKOz/sQU9sUtPCcPnf/CkXDnoxZqrqy/8qiLtDt7N5PodzmK5srtfs2S9feB7WVt0oFB7Vyu WSWqPcNF+aJWxZZq53nNLrrLz7XYpj6mxLTz/OdK3K7cHvqEuE80pna/VlYLSNcqSVqkUVSfcYcH SZVIe1XgNlq3pL/TbFeb3CbL1c2CIr6GWNCpVC0q9zTZAvtbq3Or0nEJVIUImDM3B7MxT33C+JST ca+LBVCrRnyobNWowKtLmkJnzUqrLHZOS6Pm0Ly0ToLYIGXSNAvxYIkFj48OkNDlCJw0PV1OwJkz 1As2i6YI4ZqxcJMmK4HZsDu5ig3v6LmZFXqRu2apE7dHkuY9nLw74z7nyYKeypdaDVoDeKXsg5e1 ktRq0Fk1a6oGBr8UkCargSZrNBE5W8wEnJRZoX+liRV6V7rZLBLEgn0rg9PFAMAlSdM1ybfF6UIi YlNTPNEzSGLBwcJzkj5h36CIjZ/f+8TMAWi6OG0ZKqeLWZ2haYrnFFHO9kF8oECXA107WXQFMKo0 WWly9pZcFEzNHocZc8nZW3SITpo7REuuWWzY65rNhiNai9iwsxXMatA5XHNHp4PakjRZrWnueM3J tZOASyI2h9iMlO0GYCBEsTn0d3a0rqYix7UlYAFdbTnpE/o9T25iVFsxC3a0gVhwVFs1m0nCVAHD 2FqXJqt1yd7gIXIbmYVMTbXBOOU22SbzId4s2E1cSFmoIiwWWlRr27zJGNZxOz3o7hs3ZTZZpmYz VVFik0eIGgsWad7dLAcqVHs2d05FYCSMLGlM/iSCiQoGhZk0m8x0RQSbyLgfJRkbuGkMQoGJxtwa oII+g2rsGtA3t3B/9L6q33+NKgRUbg1mvnJr1INbo67NrUF3MUYmOvUpmQYtrDrHnsPcaYEUGg1Z BD1IsthpAGUNMyoNWauESmPEoNOC4umg46oQacy5aSRbuKVQaWnpXcuINBNsIsnm7pCYDGOGymRE KY2mZECI9CmKfOWy0TZx81UcTvZdbUyQriEOCX79N+Hw2cQmz/qOgAgatQl9R1QFCT3VIZ4SETSF E8ZOrgmMgsm4AVObG1ETBN6MNRUEkpPuy2wbEKHJPFfcX0zkvWcK9PxZ3VZNNjbdfSZt47L7SN2k u8+UjdeHpc1V3dGdURkyR/SbgOQzmmvvP3M5DxetuhaDJRW0RGflgyNYWlkQF4dKw8tXl8IQrJf2 doO1RNkZQSEkC2uGHImCZUPIK1YHeacci4NuPMHaYG2iYD3Q49KFJUExCGF7xG2HKoRNGJTWxh5m SZ5NsaTZGWcwacfug/IwaGMOs6A+6bPWjQOaUucKynVvQpxj34MwySlqsqS9jHSOYDfo5t3I229u d/v9nL3KHrlRPKbSlsgXXaTS1gsZLcNTrW2GA7UjUlxmGH065MeWitpWQ6W0Dcokbdq5xHzAf5oR RdvVokcLppAL22NzC6W1bVbefUmNY+RCucdx14wEQ2oV4xf+UzfBUBqbYSiFzY6UNstQ8uhge4XI QSl7rUJJasZudkXoKRkAKJ4Z4J3RuAbMT2EaPDENZC3SfAMtRc40aLD3JJTGgRnoYV8ip5xroKg0 tMHYTIMRmQZSBStiYZ1o5jtlZ1pNvomQuwcPainOkQoQ2CMOBs0n/tK9xR5RJPOu1rhGmFT9aQ3R EMkiV2sNUVXJ81Hr5pC0LaNVixLJt0ngT7sjSNqGNZT2Om+SI7jSGqXolnb3aHBOlR8mgcRRVjNn UpXTpum2GfuR46KyiQLm4/UVPbHtKYt0cqnOuuegpx2f4dpcaim88EQp7NqY6FDWIQwgsKlBZFPT elBj/+npF1yZWov8arqXSt64gPaMDuaeMGxQhJ1fQyKjSJD7l40TK9uEYTPVg2EzR4ZN28GYK5Nm 5gybshIoUrXgchxP8AIwzwPvUzLubKB7GuPYpPrWeTO77m1TpHCeynN44YdtOY7ZXjbl0B1028HH OfoekdrbN42V+q2Sz5gO7BYLbmsMxzgibLLlY469FkpbsmuVkjHRZMPOpHVLUSVtweKUWwHHqcqK 8DlTQL9IwpGpFwjGIJONbXN6UZjnKqeu7lDak+5PwreV4ogrFfeF7z+da0t3p6RW5ywW708yw5U3 15Ye84xtSw4DGpdVaojYKtO5tuho4LFdUl9p5JeW4MKrVcNRCiXRlHytg1mrZefVajHnqy3Hw5JS 2Tm1+nG8zWvsGnEx/gxhcsdnnFozMmrZTiV2K+C2JP2OQTmF8jKEF7n6c/SXRDESTpVELDWelFSf NEXeo1TntLbVt0+H/DCpm1VkkcsanZLo2lEip+20n+xMuMQ5QylbNrWtGCBp48MlxhJKxTAmbcMm SZtDLjG+UQJDvrYbaDvyx2VQzRGfSS1ulr1ubqE0NrdKGnmPPMKeitKMPs4a/ecbtyRW67j2K5nP VzLrLOcVjUeWmsa4hfIKscsl1IUlQ7j8K1mvK7pZytlCM5L1plFyBbwjKr9KqAwLtHDnV0B5ksVq HpcVBdbY+1apchvmKKp8TaQMwwMT7H0LpRXwV3WnEnTWmuK+VayKEpRXQbxZam1qLON6RFlW+1Hz oTz23oUHthJ4VodfnmF7xb2r1Jnj3uWy9zvLHpNvadRTjZbPQ2Wf9YQdD25rHOWK2KNssuVE6qM1 dlsyXOdxLnDZ0FLnxpG0DY0o7V3AJMV0pXO2412kIR/xbelh7e4x6YFbJhnzuIqzZ3qSMkut6pR5 LUXWtxR94YpPvcRkBOY1uWXV+VgtaLNt2fft0kp25jU9VxnzWgnX7uhtOqJ5VJEo9RD5Vv2uvVg1 KbxrWssb85pyVrLZDu7RG0RjXpO1yjHR+uZd6+H2o7RxnE9QDvViaYxPQ2CTvCjv2jp511aovDA/ 4fIdpXXwrme//yjyjm7zo8s+r7zrwmZnU2816rKk/chJY4/Rjnq28Ksu9V3aMkdsHxEw2WLHb8U0 rtzW6He5bfLcmCx55BdonmGRqj05cGOyIKy3cIEokmJWX7w5nk0W5Pe2AitEkl2MX705l/QNm7JJ 35xtu7H3SXm5JUx6enFV9D2UebYim/T1jrJJ39T4jEYaPtehe5fwiV8TeFRGCSeyMiByadTqTBqS LY/0GJtLI764Kov3QsvWqntVlMrPeKT3j5rxNWdEA8gLWuUSpHy8vfr09MsD5XLwC+W1+QUJwgoP qYbaEaW+0QtaO+lXr6mFqg7kQw1HPnBtIqzA9lERQhqBXSjNzS1IulOBWMq6bvsayiMy0WUdZ87o AUvqq0bQZ6KyRoBOLDs6c+3Yyl3zjvwMax9ItTTt2X5bSe2ICJerPg031SopNknayDXJMI9yMT5o uyd/sjnlkjIOuHbTZznVyDfQWk4Yh5IwWsbgm28fPcseJYyzr5iMcygv9zuXOKdcfG0Buz2XT76z 7lAWi6w7lMQp8w6ljIPMO1QTu1pCdLPuUBJ7qymZcZDb8a4Yctv5y5FzIO/4lXMoHfcdkPVmUHCR R2AcShE/eYaqEaXj9h4yZU3ZlXW3MlSW5JUYyBcCm18lR3YVuV1V3Bd+fWXsKvLCRtlV2nF7j/I6 uIgw2P30FEfske0mNX+afY7StmiUHm6GXEq+Oh2/PEj2GyhtS+aK5EOzapKhofC7ylp3WxBVut7J 5yA5RgufmFbebUG9vtNwTphs/Cl8LwiqO89nVJUrt4p+qOH9jLA/QpmhMkQpVIbofdqerZNZwCcv YRaksJMB2O6VRZoeByjHDSwA7HhBPepClMNLY7TIgVswIreA7gskPx/4/C3Pe8YgVfr6LXf+/O37 b7/509c/7m8XSS9++zbDp2/z+cs3+f6jjaWQevdHoKnRV4dXHvRHLfId3t++/en6/usffiRPyGLe J5lghKDO69dwh+vzN7dfPey59DjumIg6Lnv89f892ed87zhVt3857eu9uu1Pf/smhIH8xDCURVzU DwAxl5wE/QSQv7SgLzAe9oLa32qlcH+p7wv0md1e2gkx1elVSaVvgPwJ17PKwUTvnXz31bXD8p8p t/THdAO5Wdwnl6Dd8YdR852+2spUm+Lv4r20X/jjn0VHJP2l44F3bGMXsf1yMwlPBHdkits2XFGG 9qztl5uPa0/VLTWOPr/cvrPPV9od6OsAcRI3ow48VUIcjD1FmPx5rX4HE5+LTVDRPg+tPY53tMea k/3lMD9cqkgL+mM4Wln4qyb6Cyf6aFE/vlgSz4lqNXX/ZeBqXra5idQ3hsgkhBeGxG1xQaAxDVwi Yd82tj03R9U8+E0RNXM8IvBczVUkoc0UN6EZptrojy0DwPy52kQV6fXsxUcyrTAWrpkyWUHzI/xA Sx0dVZBefOE5BWXCJhFe6HU50Cz3Y9yCRzQ3mfsnA/shI9up/NIO6gIel/tX4eXmw9tjd0/NT/8p wPZ+vd/nlNfRJOLOlXXK9LE+zDDlgn3TXmmMjjpiF5Wk41NrD2ZaYbyKRdZOp4uKPax65l3ut5dg Ul9oGnax2Oo8VVOA1SJ4XRaEbVHw5+YKT18ADb/ugCuYv9ZB8J8DbD0YsNzlgKuKu9uce9IIB34F YYukPXcMb5WN4d3LHkq14ljrwNgj/KAgXHSDHzBsq76jeOJWXwOK6fVbJIHLhmL/QWFoHRhMdYSN Y3PBFNYTDdYTT74Lb9YMXPZDwBZWDhwgn/rEQ30+sew6jmVXClh2rT2cae3xSgpYe2xRoYjVeRVM C1RlO3UkYyGfBVH2OKVIBZcFaVsUILq5AlU3a8OxD+6PTyIcvlOA1d6gpc5uXOF4leltkx2ZuW0Y 9ueO4a2yMbx72QOpVhyrHQh7hB8EgnhgGXEd1urEEFzoZX5Yh3FVhUiBLSu+9g8CQO9AASr9O359 eHvcTgI8+c/hFQ8NTioGLNGhKa7DOEZ9Woe3jmF3K23sbi0fzLXCeAMpGLBrooGPLtIidrng29jt ZRzY7akf2DVZseuigs/MDZxSTjp2bXB77L6qefSdgyv2DilxNuCJ/lwiYLePcWLXnm/sukrArvey B1KtMBYeu+qB3f2DgI9vSAJ2tX427AK9vgvYhQQrYnfLiq39g4DPO1BwSv+OXR/eHrt7an76T+FV Dw1OKm4s4YhwYBfHSE/Y3TqG3a20sbu1fDDXCuNBQNdjiwo+PDS3WEPYkcTRC/QFZKgh8GRcIvhd FnxtUeDn5gpPP/IYft0BU4AT/of/HGDrwYDlLgdcFTzt7BoC6FIg1hD+3DG8VTaGdy97KNU6MNyk +LGzpcp8o4TFPf01vK6jPL/M91Aqvcj9LK+i8pgAWYK1ytK7Ip7kkfhoYeZ0R1e8d5UIwDK4P1Zf zfrwnaOrHYzCR4CH/VBK4hOAAA+jQHHxGUPmqKx+PzXMKuhox0c/YTDRiqPRH1L+7P/D5pW/Zvz9 7f8B1s7WeWVuZHN0cmVhbQplbmRvYmoKNiAwIG9iago0OTU1CmVuZG9iago0IDAgb2JqCjw8L1R5 cGUvUGFnZS9NZWRpYUJveCBbMCAwIDM2MCAxNzZdCi9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8 L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMCAwIFIKL0ZvbnQgMTEgMCBSCj4+Ci9D b250ZW50cyA1IDAgUgo+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL0tpZHMgWwo0 IDAgUgpdIC9Db3VudCAxCj4+CmVuZG9iagoxIDAgb2JqCjw8L1R5cGUgL0NhdGFsb2cgL1BhZ2Vz IDMgMCBSCi9NZXRhZGF0YSAxMyAwIFIKPj4KZW5kb2JqCjcgMCBvYmoKPDwvVHlwZS9FeHRHU3Rh dGUKL09QTSAxPj5lbmRvYmoKMTAgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRvYmoKMTEgMCBvYmoK PDwvUjgKOCAwIFI+PgplbmRvYmoKOCAwIG9iago8PC9CYXNlRm9udC9aSkxCS1ErSGVsdmV0aWNh L0ZvbnREZXNjcmlwdG9yIDkgMCBSL1R5cGUvRm9udAovRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDEy MC9XaWR0aHNbCjI3OCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAo1NTYgNTU2IDU1NiA1 NTYgNTU2IDU1NiA1NTYgMCA1NTYgMCAwIDAgMCAwIDAgMAowIDAgMCA3MjIgNzIyIDAgMCAwIDAg MCAwIDAgMCAwIDcyMiAwCjAgMCAwIDAgNjExIDAgMCA5NDQgMCAwIDAgMjc4IDAgMjc4IDAgMAow IDU1NiA1NTYgNTAwIDU1NiA1NTYgMCAwIDAgMjIyIDAgNTAwIDIyMiA4MzMgNTU2IDAKNTU2IDAg MCA1MDAgMjc4IDU1NiAwIDcyMiA1MDBdCi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvU3VidHlw ZS9UeXBlMT4+CmVuZG9iago5IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUv WkpMQktRK0hlbHZldGljYS9Gb250QkJveFswIC0yMTggOTI5IDc0MV0vRmxhZ3MgMzIKL0FzY2Vu dCA3NDEKL0NhcEhlaWdodCA3NDEKL0Rlc2NlbnQgLTIxOAovSXRhbGljQW5nbGUgMAovU3RlbVYg MTM5Ci9NaXNzaW5nV2lkdGggMjc4Ci9YSGVpZ2h0IDUzOQovQ2hhclNldCgvQy9EL04vVC9XL2Ev Yi9icmFja2V0bGVmdC9icmFja2V0cmlnaHQvYy9kL2UvZWlnaHQvZml2ZS9mb3VyL2kvay9sL20v bi9vbmUvcC9zL3NpeC9zcGFjZS90L3RocmVlL3R3by91L3cveC96ZXJvKS9Gb250RmlsZTMgMTIg MCBSPj4KZW5kb2JqCjEyIDAgb2JqCjw8L0ZpbHRlci9GbGF0ZURlY29kZQovU3VidHlwZS9UeXBl MUMvTGVuZ3RoIDIzNjg+PnN0cmVhbQp4nJ1Ve1RU1Ro/h5k552RIynQgBedMgKSIgspLFFTecJlB ngaJiIJAzowIiErm1aw0d2q5Qs2bgXAVNUuw0K6Agg/EUtFAZEQezjCFSFfiWt+Z9nDv3YO1uv17 1zrrrP1Ye3/f7/v9vt+mKakNRdP0uKhsTXF2Ud6qTOvMW3SiRWcbcYoEYd2vvuZNsimUas+p8aLC lkK2EmQrrXAep7aH3onw6QuweQIlpWn/2NSPpyUnLJ0+Y4Zn6Nr8TQV5OblFyjne3n7KlZuUv+0o w7IL83J0SncyKM7WrM3XZuuK1HnalesLlYmZukJlrDIhO2e9JrPgT4t/3Pf/RaAoSqkLzQ8rLFq/ IXPjylVZ6uy8pDUa7VLv2XPm+vj6KQNeS6eoOMqNiqemUklUMpVCvUqFUKlUKBVGhVNeVAQVQ/lS sZSKUlMB1ETKnpJTL1I85UA5UjQ1iVpABVMvk0pSUnLgJM3S4XQ1/cjGzWapzSOJIFknaZBOkM6X 7pPWSttkUtlk2UZZDcMwrzC7WCnry37AUZyE28aVcQ1w0k5sRGViQntumf2dzuBe2NPjKD91Ryzn LeW9UMvKb/xy+c7Dm7WrYhX4Pz2ikjXEXHZXyL2DUKo2PYQzsnbm1UXd4lA3XTcgMXuIiNeBj5ce +6DpaIEmOS46NMcV4XEI21a7tYZdiW/LH0QQgZ48PgLJ3Axme+q2vM06bZwqLwhxeKoXcBADcQZg waX5UonuhHCs4JB2fxJHssS6MgjVix56+yZrnhcMjvKhJqzje+Eocy65vrAVceBsBBrmQ5gv2GBB kA+HoYQ1WSruPisfCmagJJb/4VognoifVwd6z0noghfghStd/QKBgLrF6910/4DoPCDpd4DPGYgF GShgAxRjKSiwSsCfMwOjTrx4HRax4HbPA6uxaqEHdhPsxJ1FnaJnJ33eAG8ZJGKMaMfvGom8iscT RHYLYj3m1WbBBK2g33j1zYpitHpSatrrIcuzDx4pVmw59M6hd6u5ucxePL41HqYQBC/13hjWZ5x1 /bsw/9PIv+mOoOpJ9WdPtN46rUvarbCDk0Xtokcr3dcjgX2EI19wC8BuYZHfWZRM8mndjSOHd39Q pbjD/nXn1l0liMvZVlotAH7IkvKRg2ll9jd6YG/Pog5H+bBY7CCWB+AGVpkY7hOd+eU3CpENsExj fW4k/qSQt3Si+mP1t7kQK79EHxvLaPGCA8wSy2UzGVeLp5voKZvKvGLxVJKBFwOelnLZI2ZY9PrZ 4iV7Fs27k641wMEeifhZPf/WezvQu4jTvXHoqAAt7EBkA+aD1euzchSF+du07y3lepl939Yc1yPu 3ldrU4X1LMot3hy9HY/bvGnHmi3qdZp0FMl53oz7+WZjRVOz4sPko0VN6DDav7tqH4fdIZJHa7eX FBTlaVa+kYa4mOyTjZdOV5kOCv0HPtlbdZDIZ+czEPA1VPIQBh8SGNgeJ2B7SJB5MhCKS7EKl8kG GZgE6eCI02VDjBWHVXAQXEY39cBFg6TJrOVHtR232C/Vjbp2QpfCRGQSAsF+T7EQ+mr+kiwBjrPg jsv5gWdKU/1Zab9r5SQRyhoY5ndc2Hpqw/Gc+tjjIUQtLt5YikNwkEkJLjDxfge8WCr4M2/6r8gM Q5xXUgdMAMcm/fd3zq0MKRX+N7ujBrhICr2dpBeAK5ncxsSqcHKf8xxM40Ac8RDT4NLWcOzG10LE XRaXiJm86coCgn98/Py5XuoHYAd2LQ++H2uEMnN4GX3PKCqMEvNkct9cywBjmSgOyNxHtUbRyIjj LUbZ07HadEJUK/h00mIpbOFR1zt1m8/kPZx/cTqJ7D4TS/BivNjkAtPAtqcVmHKCpChiWU4USkHL K9ee23Di7RO7LnK7W/l9Q83f9CKurzl6pmAHBYSo4af2N3sDiBHdBg+i8gBLeQ8j7zNrpf4uvSQy kCTZbho+HpDAL2YnHrZ3W27Pg7dHnQaYMaatEK6SFnnZWo9RbQ+sYB50QTiulo0w+HV4TDwmWqZk cAEukI1FtB5o7ZWAJzngP6olQcx3/+SK+dbPUf7F78bYzcpv3bvU0nr9i+woBR61LlinLaezoq1T cQo7mHJhWnhm8ZI0heZyZmUk4uTe4WjZuoxY7i5r92vYs5jmzQ6gMmtlrgyebOnHgWK/7BUG+5Hh FDJ0ZSBuVCv7iQF/8TEssDz+rbP0evqsCapNEqgyp/LRKE63Oi1dVeSJsCOH3+4imvYEj26Qw5ug WP/Dsm8VqxuWVEUhLkg6eN4TJ+L09JnTZy37EVIg5fzgoDD2AtBwwCiBA+Ju3rLbaE6NZzWY3rAZ O5dwsVb3QAaxlhA9zyQR9xh4y3PMR1c/qzZceNL00j+bLrQjA2ouvJR5JrP61cORaDaK0mSpC7K3 ZrwXyhmZPXUfHj9QUXH2H0cbEdd1LWFh4uuvxeYIXkvxNP8VUdux9yRR81ur3e20FwVThMlK/DrQ 8/uZ6vdlQw0ZfnOSUrxmLKsbeUcgXplQuvqTNacj7+QOkQZ0f2SAyabcBr/jgrzv5rFT9d9NBrvA duyEXRcG4Rk7FUbm/bN7K/cfKTtzrvIS4vTnly9M3aTNekMo3KbZodrFjaEHj/s0dJECdEEwj4ON EPz0vou4IobFHZYE2SwWLt7ncQEDBfDNGAd6MOjBy0CL80lB8gkJFhsmxeIge8B8Vf/5J5cRN9gc 4zJ1iWpG8LIzXcUk6QPxpWvL132Z3KbpIkm7PvkXeIBy1mPsnLpqi3alUAVpMqh7VgVo0UMCYXgQ asjl7xLBlQC38DamUBAKX535l4yIDT4I8+RFPbyoNrYm4bqGuCY4DT0BAV6aPYDl4Un5S7OF92Hx 5cfD6Do6m/VxJEesyJfva1ziOScuJnCeqvV747UWA+m2k89CfnYXCvX21aYYE+wiP/Kyik7ic3z7 15VfoFscSH06iVlMnBuEJdEVOe3LFfKRwKxV8QsmY4eh2fAyKH80gYN+VfO8Mwr5EOZgP99RlxER nZaxeNFr52611p3rEOQjuEFqvJYY4Lckyds37kpPT/PlfmsCOLfNXNNGf0vadQ/pPqz+92JQt7mZ a0aYP3bBvkdSgXN5UP+6GKtDR0Zr3Bi7ogqxvAxUZbEVjH5c3/P6D2xt+z6yHU9R/wXvYQ7ECmVu ZHN0cmVhbQplbmRvYmoKMTMgMCBvYmoKPDwvVHlwZS9NZXRhZGF0YQovU3VidHlwZS9YTUwvTGVu Z3RoIDE1MTA+PnN0cmVhbQo8P3hwYWNrZXQgYmVnaW49J++7vycgaWQ9J1c1TTBNcENlaGlIenJl U3pOVGN6a2M5ZCc/Pgo8P2Fkb2JlLXhhcC1maWx0ZXJzIGVzYz0iQ1JMRiI/Pgo8eDp4bXBtZXRh IHhtbG5zOng9J2Fkb2JlOm5zOm1ldGEvJyB4OnhtcHRrPSdYTVAgdG9vbGtpdCAyLjkuMS0xMywg ZnJhbWV3b3JrIDEuNic+CjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIycgeG1sbnM6aVg9J2h0dHA6Ly9ucy5hZG9iZS5jb20vaVgv MS4wLyc+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOjg4Y2RhMzg3LTEwYTYtMTFm MC0wMDAwLTBkYjNjMWE0YWRmMycgeG1sbnM6cGRmPSdodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8x LjMvJyBwZGY6UHJvZHVjZXI9J0dQTCBHaG9zdHNjcmlwdCA5LjEwJy8+CjxyZGY6RGVzY3JpcHRp b24gcmRmOmFib3V0PSd1dWlkOjg4Y2RhMzg3LTEwYTYtMTFmMC0wMDAwLTBkYjNjMWE0YWRmMycg eG1sbnM6eG1wPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJz48eG1wOk1vZGlmeURhdGU+ MjAxNS0wNC0wMVQxODoxMzowOCswMjowMDwveG1wOk1vZGlmeURhdGU+Cjx4bXA6Q3JlYXRlRGF0 ZT5XZWQgLUFwLXIgVCAxOiAxOjg6MTM6OjcgPC94bXA6Q3JlYXRlRGF0ZT4KPHhtcDpDcmVhdG9y VG9vbD5nbnVwbG90IDUuMCBwYXRjaGxldmVsIDA8L3htcDpDcmVhdG9yVG9vbD48L3JkZjpEZXNj cmlwdGlvbj4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6ODhjZGEzODctMTBhNi0x MWYwLTAwMDAtMGRiM2MxYTRhZGYzJyB4bWxuczp4YXBNTT0naHR0cDovL25zLmFkb2JlLmNvbS94 YXAvMS4wL21tLycgeGFwTU06RG9jdW1lbnRJRD0ndXVpZDo4OGNkYTM4Ny0xMGE2LTExZjAtMDAw MC0wZGIzYzFhNGFkZjMnLz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6ODhjZGEz ODctMTBhNi0xMWYwLTAwMDAtMGRiM2MxYTRhZGYzJyB4bWxuczpkYz0naHR0cDovL3B1cmwub3Jn L2RjL2VsZW1lbnRzLzEuMS8nIGRjOmZvcm1hdD0nYXBwbGljYXRpb24vcGRmJz48ZGM6dGl0bGU+ PHJkZjpBbHQ+PHJkZjpsaSB4bWw6bGFuZz0neC1kZWZhdWx0Jz5jd25kX2Nhc2VfMS5lcHM8L3Jk ZjpsaT48L3JkZjpBbHQ+PC9kYzp0aXRsZT48ZGM6Y3JlYXRvcj48cmRmOlNlcT48cmRmOmxpPm5p Y29sYXNrdWhuPC9yZGY6bGk+PC9yZGY6U2VxPjwvZGM6Y3JlYXRvcj48ZGM6ZGVzY3JpcHRpb24+ PHJkZjpTZXE+PHJkZjpsaT5nbnVwbG90IHBsb3Q8L3JkZjpsaT48L3JkZjpTZXE+PC9kYzpkZXNj cmlwdGlvbj48L3JkZjpEZXNjcmlwdGlvbj4KPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNrZXQgZW5kPSd3Jz8+CmVuZHN0cmVhbQpl bmRvYmoKMiAwIG9iago8PC9Qcm9kdWNlcihHUEwgR2hvc3RzY3JpcHQgOS4xMCkKL0NyZWF0aW9u RGF0ZShXZWQgQXByICAxIDE4OjEzOjA3IDIwMTUpCi9Nb2REYXRlKEQ6MjAxNTA0MDExODEzMDgr MDInMDAnKQovVGl0bGUoY3duZF9jYXNlXzEuZXBzKQovQ3JlYXRvcihnbnVwbG90IDUuMCBwYXRj aGxldmVsIDApCi9TdWJqZWN0KGdudXBsb3QgcGxvdCkKL0F1dGhvcihuaWNvbGFza3Vobik+PmVu ZG9iagp4cmVmCjAgMTQKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDA1MjcwIDAwMDAwIG4gCjAw MDAwMTAyMDkgMDAwMDAgbiAKMDAwMDAwNTIxMSAwMDAwMCBuIAowMDAwMDA1MDYwIDAwMDAwIG4g CjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwNTA0MCAwMDAwMCBuIAowMDAwMDA1MzM1IDAwMDAw IG4gCjAwMDAwMDU0MzYgMDAwMDAgbiAKMDAwMDAwNTgzMSAwMDAwMCBuIAowMDAwMDA1Mzc2IDAw MDAwIG4gCjAwMDAwMDU0MDYgMDAwMDAgbiAKMDAwMDAwNjE2OSAwMDAwMCBuIAowMDAwMDA4NjIy IDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgMTQgL1Jvb3QgMSAwIFIgL0luZm8gMiAwIFIKL0lE IFs8N0UzMzExQUQ2OUQ0NjUwMTA2RkQxQkFGNDhGNkYxNjY+PDdFMzMxMUFENjlENDY1MDEwNkZE MUJBRjQ4RjZGMTY2Pl0KPj4Kc3RhcnR4cmVmCjEwNDM2CiUlRU9GCg== --Apple-Mail=_36CEB004-21A5-4692-B172-56A6C2400850 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
--Apple-Mail=_36CEB004-21A5-4692-B172-56A6C2400850 Content-Disposition: inline; filename=cwnd_case_2_NK.pdf Content-Type: application/pdf; x-unix-mode=0644; name="cwnd_case_2_NK.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nJVcTZNst23d96+4S2fhDgl+b5O4vHKq7PeqslB5IY9klRO1y5aUUn5+8E2w NaM3Yy0e0BcgQeIckuC9439e6Z6vRP/pvy+P27/+aVzf/Xj76mpXTtef8cdvbuneoV0/38p9Xn+4 scP1p9/fWllXG3A9bqWmfG+sfH/7hM7iRz7bqI3kNsEBvctI7iut//Dd7Z+3LLL+8/K4/u0zhjev nK/Pf71JxPkq856h96uVeysNrs+P22+u9C+f//v2u8+3P74+EApqADrs2EV9LXozlPjN7nDTMew2 3h083FNO6+rz3qcFD++Ifo4aoxf1tejNUKI3u8NNo99tfDT6We7Do6/viD4n6Dt41l6LXc0kdLWK Phq4+3807jXvyyHT3xN3HiNOu+qvxm6mGr1Znp42gt3OR8eQc72n2WQM8z1jKLDCCEh7NX4x0+jF KvpY5Ob/3rih3edq5cqw7lA07pzeE3idKQRO2quBi5kGLlbRxwI3/w8HXuu9eODv4WruJR+oEf3V 4M1UwzfL09OGsNv58CDauldDTX4PZXUN3zH+ykKPUk+yFJ6DYiV9bN7rupdcylXh/ev7xHHa7iLy G0H/0tACP9x2Kx8MHmm9+nPw7deDz/g/D0qVN8J/zdQGcHqGlj44hEztpXYOIX8hAbmsaWGR+Fb8 T2Yee/DxFj4aN66QuT3H/aW577NaQCS+FfeTmccdfLyFj8bd0308x/2lZSYvP1w9THkr9ldMPf7D M7T00TFMXF6eMQNfmHuA1j0wVd4Yw2umNobTM7T0wTFAnvf0PIbyhTxAq8XCIvGt+J/MPPbg4y18 NO7a7/0ZP+VLcz/BVm8W34r7yczjDj7ewkfjHu0Oz3F/aWcqOe8FXJU3Yn/N1OI/PUNLHxxDwfbW M2bqF+b+rIV+9YjwmqmP4fmIYPpHx4Dr5i/W+7bzYPs8zA58EMejRLt++PYdXVDzv6V+Mtxrr/Ma 815GXtzHv//Xf/7H9dU//uenH/9MfflSgltoRR5AvycL5/PfHt9eX4kdx9SRq+3igcNIaAzpfRF5 L4ANjIH7w31ZJfPyv3/524t3gS3+rOZY+uKsUo95dV0nU1VFjjxtDjrvVMzVkqqK5J5A5JavnpNL w36ldEKQi9mPq9fkktnTv0R1l1chuZdrpCQ2LE+W6jVyZ2mFOlar2pJZ7ihN+X1yeVvZY8I1mtpP 6ml0tp+Ywr5Ywjp56PgX9oQ7H0loubL+yr0usu4c3Uxi36UUzZXlfk3I+vtAeZlMNmWQnOGaVWa1 53JRvkiqKKl1ntfsYru8rkWZ2pgyp53HP1diubI89Alxn2hMcr9WVo+SrgVsj7O1QK0ZdVhGqka2 qxaW0bcl/X2gPEUii272NNtriD1VpGpfuZ3JHpUiXauzXKlYKmpE9MuZxUni1N8Zm1IV97pYKerT iAuVfRod7ionBKcQiaz5aJU9OiekkTg0I62TIh5IljTNY7DHEg/uHbsnpUvxmzQxXWrfzLnp2GkG TQ4CNeORjcVKonlwMLmKB+/kuZkPxpC7ZqcTp0cS8R4q7s54z3myotX4Uq9B3OcVsg9eziCp16Aa NWuaBoYEwFkaZFQ0TYO3CSicJ8Y/Dsh8MDpo4oOxQTefRYp4cGQwOFGcelyINFHMP6ySOVVIQBQ1 vRMjK0l8yDhjfaRPeLIKiE+7e+XeJ2auFE0XLk651CoiGzVN8JyiSk0f1AcqHGzp2sii4n9wI4tO 2xNEZKOp2eNpxlxy9hYHW5NmD9GSaxYv+j2bD4ZaQTx4RmsxDw62Vs0dVQW1ce4W1f1NModrHypd RfYYoE/CzcFAgKJoPlTYr6YKRtZSEZE8Wk76pIk6WcFAG5gPbR5FfDjMVs1nijpV5WlsjfI3cBPI uEbLE2RybiOzCCSqB68/uU3x4Elsy3xqNKyxtRr7EUXiyy3EnePw5NSjQxdFJyv3MI2sNP09psRU TeVAnmuKWRQcjDwiRkxlKA2cWYeYKFV/Z6PiTyLu6QihjGDRODRgbQ6NUjaHRmnuUUZoSW6+2L7C 5s+o9ei/8jg1tpYih0aDzaEha6mPqE0faU9GmkELnk9H7z5RsnAZYcYAn01Zd3yeZR0R0gxZOIw0 Y8b8zOWZE2o6aZRqTJt50mYSHwQHU8BstJk50GZSugQ7EyDSZsIw0swCbkSiOX+K6kMV6bLAEUw5 4p6UVRmRiDrsWcqeElOSPas2xSJyFmapG4emaE5n8WyLyAiZpUUUqmoQm7j9K/RE7DJ+2SR0MzBV 9ww64OhuoqKaUSGov9fTg/Zz2WUmn9B207RDa6eyC8s+M2VHNY5MukjUMMc5gJmNI3MGjkxd1GUO 1twsWbI8GktW9llbcMzn0pljjizlj3Jk0ZYsWbArK0kQnhV6XDjwUJD37oKngr5TjJt/NrLgzt83 V3DrH4YL3OwhcgX3+7TJoru/ogu3/xyBh3o3vlCeNkJR6wZezFPadKGsbcijtvZyi0msmzGoTaMM Dpt7tiUb9RLZZfput9fYJ2vd5HMMqvuI+zEbrMkcQm+RQqZ7LoCXrQlb5tySHBPvukIE9WHoUZkB R3LEouvT3rCdvzy2PtR/GvpVbkXlSB/Xi1jyOc+fDWlRPfWw1m3W6RhmPczQM3HF4sQBpL0F4T9w jorOOjZiOs4Yx/DHvEmWSyqbZaiNYw4LvQYSnlEDYbYL77qSicKbZDcfWaGVZ8WYxfkrJYXMlr1a ojwOFJTqWxLKkWWF1iVlWZFN0HFVpEJw1JXuazjK40BooWO4oreMGXcCDHHzrOjh0lBfUw6MqEwV Y1oVJjt/KvFVuVblstC5VnuPlqxpK4Lk3YfqFl0lNGvkIssIaz9Osa7bzFVCq84pyzr3VZDqeTFd Mlh7zK5o1Z4caDFdkFX5HZ6hru7NgOTIONcN/5VLJ+GGyMKhOiK/quTM7LSo8TaYN8KhSmcT5VBV nnjfcjrRyFoK1RBqwgZhUdMdw0bU9KQoo226DQmPGuPc5qUJtnXWWj3XLTpHG5Mar1M213Q5YlmQ Cx7j0ag55Gs0P9hhZZoOHo2p5zn5BiLquLLZccwQMrOfbPKEGZilRxDH1qQIFHezjsCrKadUxeek 3caRqxd7yqzJ2DVezZEP1M+xGTGlgnW2zNmcV3TRslk1ha1Sj2S5ePGCCfV12Mouae2so/+V4v4q mo1j6bz1Q6v+NIeZE81meGmhKCxUzTO5CH+aY5ENCyuFs79rxZ8Wx57Igtklq7sj2nRDP18uKjNE FjYtKU6da4vWfnuWj3Mm6sJD4dqCcCBE7ak/aIFtctEVoit5R05HbufaksOscm2VcDLMqz7NhRZU wrZF11fOtUV7h80hnYr2/LZQK+bV4+lwySloZ6l7xZn5TOlsW6PG7Oqu4rmfgn7h16LdfKOEbjo2 glY8Hy5FpjIMUvJzF8rHzgUpe0WF8oo7Fx5Jx8Y3JClEhGGQaL81fkGiCzzhBSThrLEG5Mou2A7Y rQzYvQ84IxtwjmL43qwyz8unoD1YjnPous446n6GUJkzSPI9HP1dVySg7hhRmbFFclzlTTeMou61 l8p9qhxZ4Xr1WfP6C5Lex/mz6cxDeZzt6ClPe1nOV5TnZhaWF+FSD7URYs7ZVwSUj/sNwCh87BnW 5hVkvr1QVkGOrMLyBcJcZmVLEz/Js898noFZALqnMrOAT3bGKyxusueyjFBzQVlp8woLn+OOAqqs OYIfqFqSK7Og1sAs1PpmFmYAAiJFMGZVrX0Mv3aaEnTXEe74UDtObFCpwFVO1BnOeViYpb3noBaZ VXl34p0LmqzwtnOhXg8WtvP6EOi9mvXIssbZdK5sFKbbmFvyGzeVZRZbOu7bXLeMtORroMqSXzsz WfZNN6y05DdvKgv2WjpxqbriuaVw96aaMKKlo3Zy3bhFE63c+hQ0egUO+fTUvUrb1Z1KuNbg6J/2 KYusHHUX6l53oTzjiGiFtdHWUHWhdlRdqK/AtdZKnL/mdRfKK850D3UXaqHugjZC3QX0jtVzd/Cs 6XWf8KzNGhEgPDZ8LAgca3yzbhzreh4SVPV03AygvpxjPZ8co5dqhlx5dbY51uOlHmrhhgN6HYEL XSst4VgX3jpz9GXKtuaXs9rOGLHHERlvmo9jzD3GEc7KpIWZMi350+WzL7LkSF/ZaP5Ms7z3mRwR Igt29N2O4sre9Bga+9xIFVnwbK+ABOumGWfknVDRZ+3p2fK9St/BOIO6nFqs1RVeQfG7882gIfsT x6UvITxmuZsXBg2AwKABob4EuWiXWRjnGRBG27M12rkCDbs3Es8RXguAXl1rDvgOWrOz2nFSh6Wt SB7XDKdAWMwG5lChl6jOoZJkVRFklCTnWMNNSTWwqCTZm5LIB/ZwdvzuAuXjBPjp6ZcH6nyeks9V k2HaWpqBVUVeuyobSlp58wS18IaqZOG4sQr1ansXynPvXCXraym35DdT2grL0luWmxSPxXQdF+rZ xyyyzI3e5Pq8mW5znrPfJIksOSM5ZtR1xUKRUxOjROWyn+zV2zVGLGp1Y1m16Z8C1c0I17rNE9Xe wiyVq82E7kz6DEb0At8LkScptl+O23jU/eSK8oxR6m23jqAeb34LvSBXzqG89rjbMSfNdyyUZ2Rc yT3UrqjVc567v7kqeXj9i3KN2RHcWu70TZQyruTZdo75TZRnf4W3NaiNg3HAb2oNObDPQjjedDAO sp8MUV4BlwC+RxR5q7LZRYvoRjTIzCreoR1vsgp0cF4AMdYZA/PJUnVtZ5bYB2sem7zFt7hV0xHy 7u5jj3s9afc9o6rp3PONtOdFNM3lp0N/sBYyb5qgBOKHA6oZ5kDWIUWkaord4xZcte4zE+7VXSsy p+vY5VAPlit8RlH0hlxZVVI4CZYST6KF78Q1rqL3IMaqwpWVjKBAOAmWsl/0lcI3ecKoUo83GGhW fbaK3kEYp8qInCr6tYZxqqxwg/uBb9VwCcSt5qr0qVru/K3a999+85evfwpf2JJh/FJthg/V5vN3 avItlH2phtNNsKFHfDmeLzlwfuhjTkoHTeCgP06R7+n+/u3P1/df//gTxUge8z7JBXegUuf123Iv 1+dvbr952HNpcdwxm7i42eOv/+/JHzeSjrPg/i+nf71X9/3579+ECaI4cYLwkJD8Qz7kO+No2XcG 1b61oHfSeafLX8IdLwr0KkouMKtfMoRrKi8Jqx9sQwng23A9FxF5+gmnl/774bvbwGKeVjSLzXT+ xm1dA/35FqJX+pj84nGo/MIf/SxaRfUX+qxqbGdTpe2Xm+t4REceuDddkYO2rfLLzXu2pxaoOJ9x v9z+ah+trPucNA4OFFGTpRbsWIiXEQdaBn8261/ABBv1i0bS7tmS92VWob+JZcDQJD9cq4kGdU3a ZvirJeBRKCBUe7lNBH2V6px/Gbgiw3Y3ldrGiTINy0pcmtyXXsUNb1u1l5v3bc8tUHUPcdOsmnvD Qc+AXdxZu44US/4Zhoq4z9D2arSfi080kVZPK+/JrXZfuKgmgRDI5x37B1opea1m6GUsevl3Y5eo L/ROnfGzDXIXIFkDpnMP5KA/VCxwKr+dkgbohRTsHlQlBw3BDCxEa+AcA02yR4k7ESPKf6jLAIX9 Mtz20Gm/y+HgEG3ELxpJ06fV7s6sQn8N9y/QJeOx1Yq7AJf0WDvxv/Tnd3zo6K680Gq/7nzHbY+z MUDdVafWydxUTDq7qTtukuLGi6IoLzfv3B57rOoeY+cJFn88qDK0NFhkiuGKDkZ8fSODrZjCXsJy ac/VJ5pIo2cruyO1in2tqgjjtfkRfqD9HEdFr01odHQFQ6OTXUCUF3pTBjJIe4zIHcHddW6fHOwH LEEIgNZAXTJL3L4qLzfv3h57eOp+xs/TKxEiUQROouLB37BEHwSVGYcMwPNi+1O0Eb9oJA2fVt6Z W+3++Np7OHZdVfBBorpgY9c2VkcvJDw11hwMoEbwuy742qrAz90Vnr5xG349ADPIJ/yP+GmCvQUD loe8cYW9Dqa1DpoK+Bww7M8dw9tkY3i3srtSq9hXOzD2CD8ICPGgnWQdFpD6acVQDLQ61o1ivo0P JNi6omz/IDD0BhSm1oPj2ENwg5MGT2PgafZrdgWX/xCwhbWfrrE2dJi6eBqWt41heRttLG+r3Z1Z hf7o7ysClk01KA56cxCwrMfAjeWOG2rEcrcVWRswXbHsqkLR3A2qdsx0LFsAZuDxagMxfp5ka8EB ZiEHfHWslgOW6fPrA8v2fGPZTQKWvRXvyqxCXwVn+8Dy/kGgiIVci1j2s7VhuSSsxwKWC71DDVje uiJt/yBQ9AYUqtaDY9lDcAMLURs4x0DT7FEauPyHjS3stx1Ypr+PfsLytjEsb6ON5W21uzOr0B9W vgHLrioUsT6bEctWtDiWC/0FZsBygdIill0XrG1VoOjuClUvigzLHoAZeLzaQIyfJ9laMIB5yAFf gA83lrGPfmDZnzuWt8nG8m7FuzKrE8tyILIqVHWgj/Tw0M9J4dW1KJLpykQ1BnKWtbUojhMvGeat urTOMBZ9JC45zB1RqiiW67flIC4KYsWwxGreR+wKYW4AjytUGjzsB4DElYECr/C8+IixQKFZWf1+ WphXsNGGj3ZCZ2IVe6M/nfzF/2vNK3+/+Mfb/wOXxdOPZW5kc3RyZWFtCmVuZG9iago2IDAgb2Jq CjQ5ODEKZW5kb2JqCjQgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgMzYwIDE3Nl0K L1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRl IDEwIDAgUgovRm9udCAxMSAwIFIKPj4KL0NvbnRlbnRzIDUgMCBSCj4+CmVuZG9iagozIDAgb2Jq Cjw8IC9UeXBlIC9QYWdlcyAvS2lkcyBbCjQgMCBSCl0gL0NvdW50IDEKPj4KZW5kb2JqCjEgMCBv YmoKPDwvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIKL01ldGFkYXRhIDEzIDAgUgo+PgplbmRv YmoKNyAwIG9iago8PC9UeXBlL0V4dEdTdGF0ZQovT1BNIDE+PmVuZG9iagoxMCAwIG9iago8PC9S Nwo3IDAgUj4+CmVuZG9iagoxMSAwIG9iago8PC9SOAo4IDAgUj4+CmVuZG9iago4IDAgb2JqCjw8 L0Jhc2VGb250L1pKTEJLUStIZWx2ZXRpY2EvRm9udERlc2NyaXB0b3IgOSAwIFIvVHlwZS9Gb250 Ci9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIwL1dpZHRoc1sKMjc4IDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwCjU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAwIDU1NiAwIDAgMCAwIDAg MCAwCjAgMCAwIDcyMiA3MjIgMCAwIDAgMCAwIDAgMCAwIDAgNzIyIDAKMCAwIDAgMCA2MTEgMCAw IDk0NCAwIDAgMCAyNzggMCAyNzggMCAwCjAgNTU2IDU1NiA1MDAgNTU2IDU1NiAwIDAgMCAyMjIg MCA1MDAgMjIyIDgzMyA1NTYgMAo1NTYgMCAwIDUwMCAyNzggNTU2IDAgNzIyIDUwMF0KL0VuY29k aW5nL1dpbkFuc2lFbmNvZGluZy9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjkgMCBvYmoKPDwvVHlw ZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9aSkxCS1ErSGVsdmV0aWNhL0ZvbnRCQm94WzAgLTIx OCA5MjkgNzQxXS9GbGFncyAzMgovQXNjZW50IDc0MQovQ2FwSGVpZ2h0IDc0MQovRGVzY2VudCAt MjE4Ci9JdGFsaWNBbmdsZSAwCi9TdGVtViAxMzkKL01pc3NpbmdXaWR0aCAyNzgKL1hIZWlnaHQg NTM5Ci9DaGFyU2V0KC9DL0QvTi9UL1cvYS9iL2JyYWNrZXRsZWZ0L2JyYWNrZXRyaWdodC9jL2Qv ZS9laWdodC9maXZlL2ZvdXIvaS9rL2wvbS9uL29uZS9wL3Mvc2l4L3NwYWNlL3QvdGhyZWUvdHdv L3Uvdy94L3plcm8pL0ZvbnRGaWxlMyAxMiAwIFI+PgplbmRvYmoKMTIgMCBvYmoKPDwvRmlsdGVy L0ZsYXRlRGVjb2RlCi9TdWJ0eXBlL1R5cGUxQy9MZW5ndGggMjM2OD4+c3RyZWFtCnicnVV7VFTV Gj+HmTnnZEjKdCAF50yApIiCyksUVN5wmUGeBomIgkDOjAiISubVrDR3arlCzZuBcBU1S7DQroCC D8RS0UBkRB7OMIVIV+Ja35n2cO/dg7W6/XvXOuus/Vh7f9/v+/2+36YpqQ1F0/S4qGxNcXZR3qpM 68xbdKJFZxtxigRh3a++5k2yKZRqz6nxosKWQrYSZCutcB6ntofeifDpC7B5AiWlaf/Y1I+nJScs nT5jhmfo2vxNBXk5uUXKOd7efsqVm5S/7SjDsgvzcnRKdzIoztaszddm64rUedqV6wuViZm6QmWs MiE7Z70ms+BPi3/c9/9FoChKqQvNDyssWr8hc+PKVVnq7LykNRrtUu/Zc+b6+PopA15Lp6g4yo2K p6ZSSVQylUK9SoVQqVQoFUaFU15UBBVD+VKxlIpSUwHURMqeklMvUjzlQDlSNDWJWkAFUy+TSlJS cuAkzdLhdDX9yMbNZqnNI4kgWSdpkE6Qzpfuk9ZK22RS2WTZRlkNwzCvMLtYKevLfsBRnITbxpVx DXDSTmxEZWJCe26Z/Z3O4F7Y0+MoP3VHLOct5b1Qy8pv/HL5zsObtatiFfg/PaKSNcRcdlfIvYNQ qjY9hDOydubVRd3iUDddNyAxe4iI14GPlx77oOlogSY5Ljo0xxXhcQjbVru1hl2Jb8sfRBCBnjw+ AsncDGZ76ra8zTptnCovCHF4qhdwEANxBmDBpflSie6EcKzgkHZ/EkeyxLoyCNWLHnr7JmueFwyO 8qEmrON74ShzLrm+sBVx4GwEGuZDmC/YYEGQD4ehhDVZKu4+Kx8KZqAklv/hWiCeiJ9XB3rPSeiC F+CFK139AoGAusXr3XT/gOg8IOl3gM8ZiAUZKGADFGMpKLBKwJ8zA6NOvHgdFrHgds8Dq7FqoQd2 E+zEnUWdomcnfd4AbxkkYoxox+8aibyKxxNEdgtiPebVZsEEraDfePXNimK0elJq2ushy7MPHilW bDn0zqF3q7m5zF48vjUephAEL/XeGNZnnHX9uzD/08i/6Y6g6kn1Z0+03jqtS9qtsIOTRe2iRyvd 1yOBfYQjX3ALwG5hkd9ZlEzyad2NI4d3f1CluMP+defWXSWIy9lWWi0AfsiS8pGDaWX2N3pgb8+i Dkf5sFjsIJYH4AZWmRjuE5355TcKkQ2wTGN9biT+pJC3dKL6Y/W3uRArv0QfG8to8YIDzBLLZTMZ V4unm+gpm8q8YvFUkoEXA56WctkjZlj0+tniJXsWzbuTrjXAwR6J+Fk9/9Z7O9C7iNO9ceioAC3s QGQD5oPV67NyFIX527TvLeV6mX3f1hzXI+7eV2tThfUsyi3eHL0dj9u8aceaLep1mnQUyXnejPv5 ZmNFU7Piw+SjRU3oMNq/u2ofh90hkkdrt5cUFOVpVr6RhriY7JONl05XmQ4K/Qc+2Vt1kMhn5zMQ 8DVU8hAGHxIY2B4nYHtIkHkyEIpLsQqXyQYZmATp4IjTZUOMFYdVcBBcRjf1wEWDpMms5Ue1HbfY L9WNunZCl8JEZBICwX5PsRD6av6SLAGOs+COy/mBZ0pT/Vlpv2vlJBHKGhjmd1zYemrD8Zz62OMh RC0u3liKQ3CQSQkuMPF+B7xYKvgzb/qvyAxDnFdSB0wAxyb993fOrQwpFf43u6MGuEgKvZ2kF4Ar mdzGxKpwcp/zHEzjQBzxENPg0tZw7MbXQsRdFpeImbzpygKCf3z8/Lle6gdgB3YtD74fa4Qyc3gZ fc8oKowS82Ry31zLAGOZKA7I3Ee1RtHIiOMtRtnTsdp0QlQr+HTSYils4VHXO3Wbz+Q9nH9xOons PhNL8GK82OQC08C2pxWYcoKkKGJZThRKQcsr157bcOLtE7sucrtb+X1Dzd/0Iq6vOXqmYAcFhKjh p/Y3ewOIEd0GD6LyAEt5DyPvM2ul/i69JDKQJNluGj4ekMAvZicetndbbs+Dt0edBpgxpq0QrpIW edlaj1FtD6xgHnRBOK6WjTD4dXhMPCZapmRwAS6QjUW0HmjtlYAnOeA/qiVBzHf/5Ir51s9R/sXv xtjNym/du9TSev2L7CgFHrUuWKctp7OirVNxCjuYcmFaeGbxkjSF5nJmZSTi5N7haNm6jFjuLmv3 a9izmObNDqAya2WuDJ5s6ceBYr/sFQb7keEUMnRlIG5UK/uJAX/xMSywPP6ts/R6+qwJqk0SqDKn 8tEoTrc6LV1V5ImwI4ff7iKa9gSPbpDDm6BY/8OybxWrG5ZURSEuSDp43hMn4vT0mdNnLfsRUiDl /OCgMPYC0HDAKIED4m7esttoTo1nNZjesBk7l3CxVvdABrGWED3PJBH3GHjLc8xHVz+rNlx40vTS P5sutCMDai68lHkms/rVw5FoNorSZKkLsrdmvBfKGZk9dR8eP1BRcfYfRxsR13UtYWHi66/F5ghe S/E0/xVR27H3JFHzW6vd7bQXBVOEyUr8OtDz+5nq92VDDRl+c5JSvGYsqxt5RyBemVC6+pM1pyPv 5A6RBnR/ZIDJptwGv+OCvO/msVP1300Gu8B27IRdFwbhGTsVRub9s3sr9x8pO3Ou8hLi9OeXL0zd pM16Qyjcptmh2sWNoQeP+zR0kQJ0QTCPg40Q/PS+i7gihsUdlgTZLBYu3udxAQMF8M0YB3ow6MHL QIvzSUHyCQkWGybF4iB7wHxV//knlxE32BzjMnWJakbwsjNdxSTpA/Gla8vXfZncpukiSbs++Rd4 gHLWY+ycumqLdqVQBWkyqHtWBWjRQwJheBBqyOXvEsGVALfwNqZQEApfnfmXjIgNPgjz5EU9vKg2 tibhuoa4JjgNPQEBXpo9gOXhSflLs4X3YfHlx8PoOjqb9XEkR6zIl+9rXOI5Jy4mcJ6q9XvjtRYD 6baTz0J+dhcK9fbVphgT7CI/8rKKTuJzfPvXlV+gWxxIfTqJWUycG4Ql0RU57csV8pHArFXxCyZj h6HZ8DIofzSBg35V87wzCvkQ5mA/31GXERGdlrF40WvnbrXWnesQ5CO4QWq8lhjgtyTJ2zfuSk9P 8+V+awI4t81c00Z/S9p1D+k+rP73YlC3uZlrRpg/dsG+R1KBc3lQ/7oYq0NHRmvcGLuiCrG8DFRl sRWMflzf8/oPbG37PrIdT1H/Be9hDsQKZW5kc3RyZWFtCmVuZG9iagoxMyAwIG9iago8PC9UeXBl L01ldGFkYXRhCi9TdWJ0eXBlL1hNTC9MZW5ndGggMTUxMD4+c3RyZWFtCjw/eHBhY2tldCBiZWdp bj0n77u/JyBpZD0nVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkJz8+Cjw/YWRvYmUteGFwLWZpbHRl cnMgZXNjPSJDUkxGIj8+Cjx4OnhtcG1ldGEgeG1sbnM6eD0nYWRvYmU6bnM6bWV0YS8nIHg6eG1w dGs9J1hNUCB0b29sa2l0IDIuOS4xLTEzLCBmcmFtZXdvcmsgMS42Jz4KPHJkZjpSREYgeG1sbnM6 cmRmPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjJyB4bWxuczpp WD0naHR0cDovL25zLmFkb2JlLmNvbS9pWC8xLjAvJz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJv dXQ9J3V1aWQ6ODhjZGEzODctMTBhNi0xMWYwLTAwMDAtODc4Y2M0NDIwNDNlJyB4bWxuczpwZGY9 J2h0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8nIHBkZjpQcm9kdWNlcj0nR1BMIEdob3N0c2Ny aXB0IDkuMTAnLz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6ODhjZGEzODctMTBh Ni0xMWYwLTAwMDAtODc4Y2M0NDIwNDNlJyB4bWxuczp4bXA9J2h0dHA6Ly9ucy5hZG9iZS5jb20v eGFwLzEuMC8nPjx4bXA6TW9kaWZ5RGF0ZT4yMDE1LTA0LTAxVDE4OjEzOjA4KzAyOjAwPC94bXA6 TW9kaWZ5RGF0ZT4KPHhtcDpDcmVhdGVEYXRlPldlZCAtQXAtciBUIDE6IDE6ODoxMzo6OCA8L3ht cDpDcmVhdGVEYXRlPgo8eG1wOkNyZWF0b3JUb29sPmdudXBsb3QgNS4wIHBhdGNobGV2ZWwgMDwv eG1wOkNyZWF0b3JUb29sPjwvcmRmOkRlc2NyaXB0aW9uPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjph Ym91dD0ndXVpZDo4OGNkYTM4Ny0xMGE2LTExZjAtMDAwMC04NzhjYzQ0MjA0M2UnIHhtbG5zOnhh cE1NPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vJyB4YXBNTTpEb2N1bWVudElEPSd1 dWlkOjg4Y2RhMzg3LTEwYTYtMTFmMC0wMDAwLTg3OGNjNDQyMDQzZScvPgo8cmRmOkRlc2NyaXB0 aW9uIHJkZjphYm91dD0ndXVpZDo4OGNkYTM4Ny0xMGE2LTExZjAtMDAwMC04NzhjYzQ0MjA0M2Un IHhtbG5zOmRjPSdodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLycgZGM6Zm9ybWF0PSdh cHBsaWNhdGlvbi9wZGYnPjxkYzp0aXRsZT48cmRmOkFsdD48cmRmOmxpIHhtbDpsYW5nPSd4LWRl ZmF1bHQnPmN3bmRfY2FzZV8yLmVwczwvcmRmOmxpPjwvcmRmOkFsdD48L2RjOnRpdGxlPjxkYzpj cmVhdG9yPjxyZGY6U2VxPjxyZGY6bGk+bmljb2xhc2t1aG48L3JkZjpsaT48L3JkZjpTZXE+PC9k YzpjcmVhdG9yPjxkYzpkZXNjcmlwdGlvbj48cmRmOlNlcT48cmRmOmxpPmdudXBsb3QgcGxvdDwv cmRmOmxpPjwvcmRmOlNlcT48L2RjOmRlc2NyaXB0aW9uPjwvcmRmOkRlc2NyaXB0aW9uPgo8L3Jk ZjpSREY+CjwveDp4bXBtZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBh Y2tldCBlbmQ9J3cnPz4KZW5kc3RyZWFtCmVuZG9iagoyIDAgb2JqCjw8L1Byb2R1Y2VyKEdQTCBH aG9zdHNjcmlwdCA5LjEwKQovQ3JlYXRpb25EYXRlKFdlZCBBcHIgIDEgMTg6MTM6MDggMjAxNSkK L01vZERhdGUoRDoyMDE1MDQwMTE4MTMwOCswMicwMCcpCi9UaXRsZShjd25kX2Nhc2VfMi5lcHMp Ci9DcmVhdG9yKGdudXBsb3QgNS4wIHBhdGNobGV2ZWwgMCkKL1N1YmplY3QoZ251cGxvdCBwbG90 KQovQXV0aG9yKG5pY29sYXNrdWhuKT4+ZW5kb2JqCnhyZWYKMCAxNAowMDAwMDAwMDAwIDY1NTM1 IGYgCjAwMDAwMDUyOTYgMDAwMDAgbiAKMDAwMDAxMDIzNSAwMDAwMCBuIAowMDAwMDA1MjM3IDAw MDAwIG4gCjAwMDAwMDUwODYgMDAwMDAgbiAKMDAwMDAwMDAxNSAwMDAwMCBuIAowMDAwMDA1MDY2 IDAwMDAwIG4gCjAwMDAwMDUzNjEgMDAwMDAgbiAKMDAwMDAwNTQ2MiAwMDAwMCBuIAowMDAwMDA1 ODU3IDAwMDAwIG4gCjAwMDAwMDU0MDIgMDAwMDAgbiAKMDAwMDAwNTQzMiAwMDAwMCBuIAowMDAw MDA2MTk1IDAwMDAwIG4gCjAwMDAwMDg2NDggMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSAxNCAv Um9vdCAxIDAgUiAvSW5mbyAyIDAgUgovSUQgWzxCMDM5QURFMEE3QTMyOEExNDM0MDNGOTE1QUJD NjczND48QjAzOUFERTBBN0EzMjhBMTQzNDAzRjkxNUFCQzY3MzQ+XQo+PgpzdGFydHhyZWYKMTA0 NjIKJSVFT0YK --Apple-Mail=_36CEB004-21A5-4692-B172-56A6C2400850 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

=E2=80=94 Discussion =E2=80=94 

We acknowledge that this effect may not = occur often in real life and might be a simulation
artefact. However, we have been looking around and are = wondering the rationale of having

      if (W_max < = W_last_max){   

instead of 

      if (W_max <=3D W_last_max){ =   

What do you think about it ?
Why would = not we change the =E2=80=98<=E2=80=98 for a =E2=80=98<=3D=E2=80=98 = ?

Kind = regards,  

Nicolas KUHN
Emmanuel LOCHIN
Si Quoc Viet TRANG
= --Apple-Mail=_36CEB004-21A5-4692-B172-56A6C2400850-- --Apple-Mail=_E234CAB6-EBD5-4349-892B-2C69F250A2DC-- From nobody Thu Apr 23 12:58: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 D87931B3237 for ; Thu, 23 Apr 2015 12:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 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, 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 h5alHE_F97_Y for ; Thu, 23 Apr 2015 12:58:33 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (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 C71A81B3231 for ; Thu, 23 Apr 2015 12:58:18 -0700 (PDT) Received: by obcux3 with SMTP id ux3so22231667obc.2 for ; Thu, 23 Apr 2015 12:58: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:content-transfer-encoding; bh=b7lhXaD8DteqtN07lI6dp/mvPvZrj6Q6Qhml8aQOL3E=; b=IiMRpLimF0MwCyV8ZvMmgPQH32NETxw1jdMGBz4HAx0JFXF4RIc/k+VAon3E4A6HMh l7gyDqcDAon1yBtLagA4W3SqAloYCBWrZP7IoHQoSIddJ2GmZ6YOVBdZDr2lFOuSVZ3V yey5o85fZDARwRfMbt3vkZSyao55yb2ACR18KprhmSXmoy6yPwBsu2AhUtDGEOs+WQqV fx5sxL3m9umeqoJ/0rcMuoBrLUw9IOoRH9XJBtI0qMgO8GReSX9GZTkpaRqGG/2nM39q Hsfc9kvxV+CKGN09Jdbh9x0OSIKZNEf3sEWpM7XjAFcpAoTMclY2VEh+z95r63E98xsa j1FQ== 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 :content-transfer-encoding; bh=b7lhXaD8DteqtN07lI6dp/mvPvZrj6Q6Qhml8aQOL3E=; b=Z3ssmqGi1C1LgMqAAE9sKA4gL11ZOfaQpGKhlqwxzV4/DCEKo2FzoS4Twdg7geRV/+ iW6lETTvqSVeX2xi63teap9e6jWa4PXxf0tABXii06Mjn0IfREHFNn4L2xT0J/H/pMHQ HqFS61MzCrJ5+OcUNyuDX7g+ZEII89uR4NbGz58xpZsC0ImKw32Uw2EQwYfOlbq4JPPl niLiYaifM7D5wtMDRvOBq0LJQTZuvSH+/Sv3FCzuJjmy0flIAJonDzwFI/NeDEe4LFEI 4rXRmw5qU+Np17ZWPNHcr0ASQ1l0JlUYQpo703vFpMhoHIqHRERSMJXVbXlaGaJ43vaD triA== X-Gm-Message-State: ALoCoQkpuseOqLe+yWlumsZREpTj4Sj62qHHjo+lcnrwRrH31SvxiFimPpTGBgu1O8l6V2AP2k7A MIME-Version: 1.0 X-Received: by 10.182.216.168 with SMTP id or8mr2143185obc.31.1429819098278; Thu, 23 Apr 2015 12:58:18 -0700 (PDT) Received: by 10.202.50.195 with HTTP; Thu, 23 Apr 2015 12:58:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Apr 2015 15:58:18 -0400 Message-ID: From: Neal Cardwell To: Nicolas Kuhn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] last_max in CUBIC 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, 23 Apr 2015 19:58:35 -0000 On Thu, Apr 23, 2015 at 12:22 PM, Nicolas Kuhn wrote: > Hi all, > > We were currently working on CUBIC and LEDBAT in NS-2, using Michael Welz= l=E2=80=99s > updated TCP Linux for NS-2 > [http://www.ietf.org/mail-archive/web/iccrg/current/msg01160.html]. > We see some strange behaviour in CUBIC=E2=80=99s window reduction, which = we wanted > to share with you here. > > =E2=80=94 Topology =E2=80=94 > > The topology is a simple dumbbell topology with a bottleneck of 10Mbps an= d > an RTT of 100ms. The queue size of the router is set > to 42 packets (with DropTail). There are two non-application limited bulk > flows that randomly start within the first second of the simulation. > Flow#1 is CUBIC (using ns-2.35/tcp/src/tcp_cubic.c version); > Flow#2 is LEDBAT with a target delay of 5 ms or 25ms. > > =E2=80=94 Problem illustration =E2=80=94 > > In cwnd_case_1_default.pdf and cwnd_case_2_default.pdf, we plot the > congestion window evaluation and the > =E2=80=9Cnew last_max_cwnd=E2=80=9D, that is the W_last_max in the CUBIC = draft > [https://datatracker.ietf.org/doc/draft-zimmermann-tcpm-cubic]. > > > > We recall here how CUBIC deals with fast convergence: > > if (W_max < W_last_max){ > W_last_max =3D W_max; > W_max =3D W_max*(2-beta)/2; > } else { > W_last_max =3D W_max > } > > In the case with LEDBAT25, at 15s, W_last_max =E2=80=9Cshould=E2=80=9D ha= ve been reduced, Can you explain why you feel that in the case with LEDBAT25, at 15s, W_last_max should have been reduced? AFAICT, in the LEDBAT25 case with the existing CUBIC code (cwnd_case_2_default.pdf) the CUBIC behavior is reasonable. From 15s to 50s CUBIC finds that it is able to get cwnd up all the way to the max value from the previous epoch before another loss happens. That suggests that there are no other competing flows, and the situation is stable, so it is reasonable to try to make cwnd quickly plateau at the same level in the next epoch, rather than some lower level. Can you summarize why this seems problematic? neal From nobody Fri Apr 24 01:08: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 771E21B35A3 for ; Fri, 24 Apr 2015 01:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 W3fUPnatXSEz for ; Fri, 24 Apr 2015 01:08:00 -0700 (PDT) Received: from zproxy210.enst-bretagne.fr (zproxy210.enst-bretagne.fr [192.108.117.8]) by ietfa.amsl.com (Postfix) with ESMTP id 03DC61B359E for ; Fri, 24 Apr 2015 01:07:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id 070BE23226B; Fri, 24 Apr 2015 10:07:25 +0200 (CEST) Received: from zproxy210.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy210.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id pCB5_ftPEpsf; Fri, 24 Apr 2015 10:07:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTP id 024B123226D; Fri, 24 Apr 2015 10:07:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at zproxy210.enst-bretagne.fr Received: from zproxy210.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy210.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id v1kiPTzonCcN; Fri, 24 Apr 2015 10:07:23 +0200 (CEST) Received: from [10.101.5.253] (sjombord-3.ictservices.se [188.121.67.51]) by zproxy210.enst-bretagne.fr (Postfix) with ESMTPSA id 2AEF723226B; Fri, 24 Apr 2015 10:07:23 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2C765C06-A515-4210-BA23-9D42BE0F06CD" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Nicolas Kuhn In-Reply-To: Date: Fri, 24 Apr 2015 10:07:21 +0200 Message-Id: References: To: Neal Cardwell X-Mailer: Apple Mail (2.1990.1) Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] last_max in CUBIC 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, 24 Apr 2015 08:08:02 -0000 --Apple-Mail=_2C765C06-A515-4210-BA23-9D42BE0F06CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23 Apr 2015, at 21:58, Neal Cardwell wrote: >=20 > On Thu, Apr 23, 2015 at 12:22 PM, Nicolas Kuhn > > wrote: >> Hi all, >>=20 >> We were currently working on CUBIC and LEDBAT in NS-2, using Michael = Welzl=E2=80=99s >> updated TCP Linux for NS-2 >> [http://www.ietf.org/mail-archive/web/iccrg/current/msg01160.html]. >> We see some strange behaviour in CUBIC=E2=80=99s window reduction, = which we wanted >> to share with you here. >>=20 >> =E2=80=94 Topology =E2=80=94 >>=20 >> The topology is a simple dumbbell topology with a bottleneck of = 10Mbps and >> an RTT of 100ms. The queue size of the router is set >> to 42 packets (with DropTail). There are two non-application limited = bulk >> flows that randomly start within the first second of the simulation. >> Flow#1 is CUBIC (using ns-2.35/tcp/src/tcp_cubic.c version); >> Flow#2 is LEDBAT with a target delay of 5 ms or 25ms. >>=20 >> =E2=80=94 Problem illustration =E2=80=94 >>=20 >> In cwnd_case_1_default.pdf and cwnd_case_2_default.pdf, we plot the >> congestion window evaluation and the >> =E2=80=9Cnew last_max_cwnd=E2=80=9D, that is the W_last_max in the = CUBIC draft >> [https://datatracker.ietf.org/doc/draft-zimmermann-tcpm-cubic]. >>=20 >>=20 >>=20 >> We recall here how CUBIC deals with fast convergence: >>=20 >> if (W_max < W_last_max){ >> W_last_max =3D W_max; >> W_max =3D W_max*(2-beta)/2; >> } else { >> W_last_max =3D W_max >> } >>=20 >> In the case with LEDBAT25, at 15s, W_last_max =E2=80=9Cshould=E2=80=9D = have been reduced, >=20 > Can you explain why you feel that in the case with LEDBAT25, at 15s, > W_last_max should have been reduced? >=20 > AFAICT, in the LEDBAT25 case with the existing CUBIC code > (cwnd_case_2_default.pdf) the CUBIC behavior is reasonable. =46rom 15s > to 50s CUBIC finds that it is able to get cwnd up all the way to the > max value from the previous epoch before another loss happens. That > suggests that there are no other competing flows, and the situation is > stable, so it is reasonable to try to make cwnd quickly plateau at the > same level in the next epoch, rather than some lower level. >=20 > Can you summarize why this seems problematic? >=20 It may be a simulation artefact (would not happen much in real life), = and I do=20 not believe that it would be somehow problematic; CUBIC is very = aggressive anyway - reducing its aggressiveness in such corner cases is not = =E2=80=9Cneeded=E2=80=9D.=20 I just wanted to point out that this =E2=80=9Cstrange=E2=80=9D behaviour = can be assessed by=20 changing=20 if (W_max < W_last_max){ =20 by=20 if (W_max <=3D W_last_max){ =20 and that it might have a slight impact on the fairness of CUBIC with = latecomer=20 flows.=20 Nicolas=20 > neal --Apple-Mail=_2C765C06-A515-4210-BA23-9D42BE0F06CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 23 Apr 2015, at 21:58, Neal Cardwell <ncardwell@google.com> wrote:

On Thu, Apr 23, 2015 at 12:22 PM, Nicolas = Kuhn
<nicolas.kuhn@telecom-bretagne.eu> wrote:
Hi all,
We were currently working on CUBIC and LEDBAT in NS-2, using = Michael Welzl=E2=80=99s
updated TCP Linux for NS-2
[http://www.ietf.org/mail-archive/web/iccrg/current/msg01160.htm= l].
We see some strange behaviour in CUBIC=E2=80=99s = window reduction, which we wanted
to share with you = here.

=E2=80=94 Topology =E2=80=94

The topology is a simple dumbbell topology = with a bottleneck of 10Mbps and
an RTT of 100ms. The queue = size of the router is set
to 42 packets (with DropTail). = There are two non-application limited bulk
flows that = randomly start within the first second of the simulation.
Flow#1 is CUBIC (using ns-2.35/tcp/src/tcp_cubic.c = version);
Flow#2 is LEDBAT with a target delay of 5 ms or = 25ms.

=E2=80=94 Problem illustration =E2=80=94=

In cwnd_case_1_default.pdf and = cwnd_case_2_default.pdf, we plot the
congestion window = evaluation and the
=E2=80=9Cnew last_max_cwnd=E2=80=9D, = that is the W_last_max in the CUBIC draft
[https://datatracker.ietf.org/doc/draft-zimmermann-tcpm-cubic].



We recall = here how CUBIC deals with fast convergence:

     if (W_max < W_last_max){
         W_last_ma= x =3D W_max;
         W_max =3D= W_max*(2-beta)/2;
     } else = {
         W_last_ma= x =3D W_max
     }

In the case with LEDBAT25, at 15s, W_last_max = =E2=80=9Cshould=E2=80=9D have been reduced,
Can you explain why you feel that in the case = with LEDBAT25, at 15s,
W_last_max should have = been reduced?

AFAICT, in the LEDBAT25 = case with the existing CUBIC code
(cwnd_case_2_default.pdf) the CUBIC behavior is = reasonable. =46rom 15s
to 50s CUBIC finds that it = is able to get cwnd up all the way to the
max value from the previous epoch before another = loss happens. That
suggests that there are no = other competing flows, and the situation is
stable, so it is reasonable to try to make cwnd = quickly plateau at the
same level in the next = epoch, rather than some lower level.

Can you summarize why this seems = problematic?




neal

= --Apple-Mail=_2C765C06-A515-4210-BA23-9D42BE0F06CD-- From nobody Sun Apr 26 23:21:05 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 B37221B2EB8 for ; Sun, 26 Apr 2015 23:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.615 X-Spam-Level: *** X-Spam-Status: No, score=3.615 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, 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 2jBEmDLYgFzf for ; Sun, 26 Apr 2015 23:21:01 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489331A9073 for ; Sun, 26 Apr 2015 23:21:00 -0700 (PDT) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 03BAE2780C3 for ; Mon, 27 Apr 2015 15:20:59 +0900 (JST) Received: by wgso17 with SMTP id o17so104753408wgs.1 for ; Sun, 26 Apr 2015 23:20:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.110.233 with SMTP id id9mr19416620wjb.136.1430115656473; Sun, 26 Apr 2015 23:20:56 -0700 (PDT) Received: by 10.194.41.167 with HTTP; Sun, 26 Apr 2015 23:20:56 -0700 (PDT) In-Reply-To: <5535701F.9070709@isi.edu> References: <20150415175805.17797.49699.idtracker@ietfa.amsl.com> <552EA990.5000207@isi.edu> <552F339A.3000605@mti-systems.com> <5535701F.9070709@isi.edu> Date: Sun, 26 Apr 2015 23:20:56 -0700 Message-ID: From: Yoshifumi Nishida To: Joe Touch Content-Type: multipart/alternative; boundary=047d7bf10b3ab121fe0514aebfcd Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-02.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, 27 Apr 2015 06:21:03 -0000 --047d7bf10b3ab121fe0514aebfcd Content-Type: text/plain; charset=UTF-8 Hi Joe, On Mon, Apr 20, 2015 at 2:31 PM, Joe Touch wrote: > > > On 4/15/2015 11:45 PM, Yoshifumi Nishida wrote: > > Hi, > > > > On Wed, Apr 15, 2015 at 8:59 PM, Wesley Eddy > > wrote: > > > > On 4/15/2015 2:10 PM, Joe Touch wrote: > > > It includes a variant that indicates the TCP segment length to > detect > > > when coalescing that might interfere with EDO occurs. > > > > This is one thing that I think we particularly want feedback from > > the group on. > > > > I think it's a very low-impact way (compared to adding checksums, > > using AO, using IPsec, etc) in order to reasonably detect an > > accidental pollution of the user data due to resegmentation. > > > > > >>> When an endpoint receives a segment using the 6-byte EDO > > Extension option, it MUST validate the Segment_Length field with the > > length of the segment as indicated in the TCP pseudoheader. If the > > segment lengths do not match, the segment MUST be discarded and an > > error SHOULD be logged in a rate-limited manner. > > > > > > I am wondering if discarding a segment is safe enough. > > Once resegmentation happens, I think we are not very sure how to recover > it. > > I guess it would be better to reset a connection. > > It's safe - the connection will fail after several failed > retransmissions anyway. That limit can be controlled with the TCP User > Timeout option. > Yes, you're right. But, I'm guessing discarding segments will be almost the same thing as resetting a connection except it takes rather long time in most cases. Also, I think some applications (or mptcp) that have some sort of recovery mechanisms might want quick reaction. > Jumping to a reset would be quicker but might be premature. The sender > might be able to resend segments without EDO or the situation might be > transient. Hmm. falling back to normal TCP might be risky as we might not be sure if EDO option is removed by a middlebox or not. I think that's why the current draft says TCP MUST put EDO options in all segments once it's negotiated. Thanks, -- Yoshi --047d7bf10b3ab121fe0514aebfcd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe,

On Mon, Apr 20, 2015 at 2:31 PM, Jo= e Touch <touch@isi.edu> wrote:


On 4/15/2015 11:45 PM, Yoshifumi Nishida wrote:
> Hi,
>
> On Wed, Apr 15, 2015 at 8:59 PM, Wesley Eddy <wes@mti-systems.com
> <mailto:wes@mti-systems.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 4/15/2015 2:10 PM, Joe Touch wrote:
>=C2=A0 =C2=A0 =C2=A0> It includes a variant that indicates the TCP s= egment length to detect
>=C2=A0 =C2=A0 =C2=A0> when coalescing that might interfere with EDO = occurs.
>
>=C2=A0 =C2=A0 =C2=A0This is one thing that I think we particularly want= feedback from
>=C2=A0 =C2=A0 =C2=A0the group on.
>
>=C2=A0 =C2=A0 =C2=A0I think it's a very low-impact way (compared to= adding checksums,
>=C2=A0 =C2=A0 =C2=A0using AO, using IPsec, etc) in order to reasonably = detect an
>=C2=A0 =C2=A0 =C2=A0accidental pollution of the user data due to resegm= entation.
>
>
>>> When an endpoint receives a segment using the 6-byte EDO
>=C2=A0 =C2=A0 Extension option, it MUST validate the Segment_Length fie= ld with the
>=C2=A0 =C2=A0 length of the segment as indicated in the TCP pseudoheade= r. If the
>=C2=A0 =C2=A0 segment lengths do not match, the segment MUST be discard= ed and an
>=C2=A0 =C2=A0 error SHOULD be logged in a rate-limited manner.
>
>
> I am wondering if discarding a segment is safe enough.
> Once resegmentation happens, I think we are not very sure how to recov= er it.
> I guess it would be better to reset a connection.

It's safe - the connection will fail after several failed retransmissions anyway. That limit can be controlled with the TCP User
Timeout option.

Yes, you're right.= =C2=A0
But, I'm guessing discarding segments will be almost t= he same thing as resetting a connection except it takes rather long time in= most cases. =C2=A0
Also, I think some applications (or mptcp) th= at have some sort of recovery mechanisms might want quick reaction.=C2=A0
=C2=A0
Jumping to a reset would be quicker but might be premature. The sender
might be able to resend segments without EDO or the situation might be
transient.

Hmm. falling back to normal TCP = might be risky as we might not be sure if EDO option is removed by a middle= box or not.
I think that's why the current draft says TCP MUS= T put EDO options in all segments once it's negotiated.
=C2= =A0
Thanks,
--
Yoshi

--047d7bf10b3ab121fe0514aebfcd-- From nobody Mon Apr 27 08:40:42 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 E25DC1A8886 for ; Mon, 27 Apr 2015 08:40:41 -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 IQbP-Lf1PzNf for ; Mon, 27 Apr 2015 08:40:40 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A70FA1A88AF for ; Mon, 27 Apr 2015 08:40:40 -0700 (PDT) Received: from [192.168.1.11] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t3RFdlul019553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Apr 2015 08:39:56 -0700 (PDT) Message-ID: <553E5842.1000805@isi.edu> Date: Mon, 27 Apr 2015 08:39:46 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Yoshifumi Nishida References: <20150415175805.17797.49699.idtracker@ietfa.amsl.com> <552EA990.5000207@isi.edu> <552F339A.3000605@mti-systems.com> <5535701F.9070709@isi.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-02.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, 27 Apr 2015 15:40:42 -0000 On 4/26/2015 11:20 PM, Yoshifumi Nishida wrote: > Hi Joe, > > On Mon, Apr 20, 2015 at 2:31 PM, Joe Touch > wrote: > > > > On 4/15/2015 11:45 PM, Yoshifumi Nishida wrote: > > Hi, > > > > On Wed, Apr 15, 2015 at 8:59 PM, Wesley Eddy > > >> wrote: > > > > On 4/15/2015 2:10 PM, Joe Touch wrote: > > > It includes a variant that indicates the TCP segment length > to detect > > > when coalescing that might interfere with EDO occurs. > > > > This is one thing that I think we particularly want feedback from > > the group on. > > > > I think it's a very low-impact way (compared to adding checksums, > > using AO, using IPsec, etc) in order to reasonably detect an > > accidental pollution of the user data due to resegmentation. > > > > > >>> When an endpoint receives a segment using the 6-byte EDO > > Extension option, it MUST validate the Segment_Length field > with the > > length of the segment as indicated in the TCP pseudoheader. If the > > segment lengths do not match, the segment MUST be discarded and an > > error SHOULD be logged in a rate-limited manner. > > > > > > I am wondering if discarding a segment is safe enough. > > Once resegmentation happens, I think we are not very sure how to > recover it. > > I guess it would be better to reset a connection. > > It's safe - the connection will fail after several failed > retransmissions anyway. That limit can be controlled with the TCP User > Timeout option. > > Yes, you're right. > But, I'm guessing discarding segments will be almost the same thing as > resetting a connection except it takes rather long time in most cases. It depends on whether the situation is persistent or not. > Also, I think some applications (or mptcp) that have some sort of > recovery mechanisms might want quick reaction. They can set the user timeout to be shorter. > Jumping to a reset would be quicker but might be premature. The sender > might be able to resend segments without EDO or the situation might be > transient. > > Hmm. falling back to normal TCP might be risky as we might not be sure > if EDO option is removed by a middlebox or not. In those cases you'd want stronger protection, e.g., TCP-AO or IPsec. > I think that's why the current draft says TCP MUST put EDO options in > all segments once it's negotiated. Yes. There's also the possibility of using the EDO header without using the extension area it provides (e.g., EDO values of 15 or below), though. That presumes that the extended-area options are "optional", though. Joe From nobody Tue Apr 28 08:58: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 00C401ACF55 for ; Tue, 28 Apr 2015 08:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SsCHGUwm_FES for ; Tue, 28 Apr 2015 08:58:13 -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 81E441ACEF1 for ; Tue, 28 Apr 2015 08:58:10 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:21f:5bff:fe38:7354]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 864FF1B00519 for ; Tue, 28 Apr 2015 16:58:21 +0100 (BST) Message-ID: <553FAE0B.6000609@erg.abdn.ac.uk> Date: Tue, 28 Apr 2015 16:58:03 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: tcpm@ietf.org References: <655C07320163294895BBADA28372AF5D16C939E2@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D16C939E2@FR712WXCHMBA15.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 15:58:15 -0000 On 22/04/2015 09:53, Scharf, Michael (Michael) wrote: > 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 > As an individual: I expect the expertise needed to review this and comment on the text is available in TCPM, and this should be discussed in this WG. However, I doubt if it is appropriate for the WG to work to further develop mechanisms within the existing spec - I therefore do not support making this the spec an IETF standard (even EXP). That said, I fully support the idea of an Informational RFC documenting DCTCP as existing use of TCP - especially if the target deployment area is stated to be within a controlled environment, such as a data centre. I think this could best be an Informational spec as an AD-sponsored draft, but such a draft could (I think) also be adopted in TCPM (or from TSVWG - if this proves to be an appropriate place to see the document published, which could be considered since this changes the ECN reaction). ALSO: I would like to see a standard-track RFC with IETF-specified mechanisms emerge that also handles Accurate ECN, ECN fallback and other related mechanisms. This could perhaps use DTCTP as a basis, if this proves appropriate. Gorry From nobody Wed Apr 29 01:52:18 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 E469F1A89F2 for ; Wed, 29 Apr 2015 01:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.215 X-Spam-Level: ** X-Spam-Status: No, score=2.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, 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 E9CTsTZ6u-lP for ; Wed, 29 Apr 2015 01:52:13 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE351A89E1 for ; Wed, 29 Apr 2015 01:52:12 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A061A278063 for ; Wed, 29 Apr 2015 17:52:10 +0900 (JST) Received: by widdi4 with SMTP id di4so170907039wid.0 for ; Wed, 29 Apr 2015 01:52:08 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.172.72 with SMTP id ba8mr8435871wjc.136.1430297528391; Wed, 29 Apr 2015 01:52:08 -0700 (PDT) Received: by 10.194.41.167 with HTTP; Wed, 29 Apr 2015 01:52:08 -0700 (PDT) In-Reply-To: <20150429074707.31267.78665.idtracker@ietfa.amsl.com> References: <20150429074707.31267.78665.idtracker@ietfa.amsl.com> Date: Wed, 29 Apr 2015 01:52:08 -0700 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=089e013c6b341a60c00514d91878 Archived-At: Subject: [tcpm] Fwd: Publication has been requested for draft-ietf-tcpm-newcwv-10 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, 29 Apr 2015 08:52:17 -0000 --089e013c6b341a60c00514d91878 Content-Type: text/plain; charset=UTF-8 Hi, I have sent a publication request for newcwv draft. Thanks, -- Yoshi ---------- Forwarded message ---------- From: Yoshifumi Nishida Date: Wed, Apr 29, 2015 at 12:47 AM Subject: Publication has been requested for draft-ietf-tcpm-newcwv-10 To: mls.ietf@gmail.com Cc: tcpm-chairs@tools.ietf.org, iesg-secretary@ietf.org, tcpm-chairs@ietf.org, draft-ietf-tcpm-newcwv@ietf.org, Yoshifumi Nishida < nishida@sfc.wide.ad.jp> Yoshifumi Nishida has requested publication of draft-ietf-tcpm-newcwv-10 as Experimental on behalf of the TCPM working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tcpm-newcwv/ --089e013c6b341a60c00514d91878 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have sent a publicatio= n request for newcwv draft.

Thanks,
--
Yoshi

---------- Forwarded= message ----------
From: Yoshifumi Nishid= a <nishida@sfc.wide.ad.jp>
Date: Wed, Apr 29, 20= 15 at 12:47 AM
Subject: Publication has been requested for draft-ietf-tc= pm-newcwv-10
To: mls.ietf@gmail.com
Cc: tcpm-chairs@tools.ietf.org, iesg-secretary@ietf.org, tcpm-chairs@ietf.org= , draf= t-ietf-tcpm-newcwv@ietf.org, Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
<= br>
Yoshifumi Nishida has requested publication of draft-ietf-tcpm-newcw= v-10 as Experimental on behalf of the TCPM working group.

Please verify the document's state at https://datatracker.i= etf.org/doc/draft-ietf-tcpm-newcwv/


--089e013c6b341a60c00514d91878-- From nobody Wed Apr 29 05:32: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 A70F51A8AE9 for ; Wed, 29 Apr 2015 05:32:58 -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 E0ilUu49qgtf for ; Wed, 29 Apr 2015 05:32:51 -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 67FA51A8BB4 for ; Wed, 29 Apr 2015 05:32:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,671,1422950400"; d="scan'208";a="39973993" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx141-out.netapp.com with ESMTP; 29 Apr 2015 05:32:21 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 29 Apr 2015 05:32:20 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::29f7:3e3f:78c5:a0bc%21]) with mapi id 15.00.0995.031; Wed, 29 Apr 2015 05:32:21 -0700 From: "Scheffenegger, Richard" To: "Scharf, Michael (Michael)" , "tcpm@ietf.org" Thread-Topic: Feedback on WG acceptance of draft-zimmermann-tcpm-cubic-01 Thread-Index: AdB82dct7bOB/OJdSd689asNJWANrgFnlOVg Date: Wed, 29 Apr 2015 12:32:20 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D16C939DA@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D16C939DA@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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-zimmermann-tcpm-cubic-01 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, 29 Apr 2015 12:32:58 -0000 Hi, I'm still in support, on standards track.. From my point of view, the defin= itions in [4] don't quite match here (but I would probably be content with = informational, if something really limits submission as standards track). Best regards, Richard > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael > (Michael) > Sent: Mittwoch, 22. April 2015 10:54 > To: tcpm@ietf.org > Subject: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic- > 01 >=20 > Dear all, >=20 > During IETF 91 [1] and on the list there has been strong support for WG > adoption of draft-zimmermann-tcpm-cubic [2]. It seems consensus in TCPM t= o > adopt this document. >=20 > In order to move forward, the chairs seek for additional community > guidance regarding the intended status: >=20 > a) Proposed standard >=20 > b) Experimental >=20 > c) Informational >=20 > During IETF 91, there was strong support for Proposed Standard [1]. Yet, > given the running code and the potential evolution of congestion control > algorithms in future, the chairs want to ensure that there is strong > consensus in TCPM on the intended status. Also, we would like to handle > this question consistently among potential other alternative congestion > control algorithms. >=20 > Additional information regarding the RFC status can be found in [3], and > there is also an IESG statement on the difference between Experimental an= d > Informational [4]. >=20 > Please let us know any feedback on the WG acceptance of draft-zimmermann- > tcpm-cubic-01 and specifically the intended status until May 8. >=20 > Thanks! >=20 > Michael, Pasi, Yoshifumi >=20 >=20 > [1] http://www.ietf.org/proceedings/91/minutes/minutes-91-tcpm >=20 > [2] https://tools.ietf.org/html/draft-zimmermann-tcpm-cubic-01 >=20 > [2] RFC 2026, Section 4.1.1, 4.2.1, 4.2.2 >=20 > [3] https://www.ietf.org/iesg/informational-vs-experimental.html >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Apr 29 05:44:40 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 B672B1B2C82 for ; Wed, 29 Apr 2015 05:44:38 -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 lFQBifHge3DG for ; Wed, 29 Apr 2015 05:44:35 -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 1BD441B2C81 for ; Wed, 29 Apr 2015 05:44:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,671,1422950400"; d="scan'208";a="38686120" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx143-out.netapp.com with ESMTP; 29 Apr 2015 05:43:33 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 29 Apr 2015 05:43:33 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::29f7:3e3f:78c5:a0bc%21]) with mapi id 15.00.0995.031; Wed, 29 Apr 2015 05:43:33 -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/DQQ7w2TuSWSxKiXj5XLgFnxocg Date: Wed, 29 Apr 2015 12:43:33 +0000 Message-ID: <9758e066d7c542c2a99cbf366df7cc7d@hioexcmbx05-prd.hq.netapp.com> References: <655C07320163294895BBADA28372AF5D16C939E2@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D16C939E2@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: Wed, 29 Apr 2015 12:44:38 -0000 Hi, I think this draft, if the intention as I understood it so far, is to docum= ents a specific, defined and deployed use case, would warrant informational= status; Personally (disclaimer - as one of the co-authors of AccECN-reqs a= nd the AccECN draft) I'm not very happy with the mangling of the ECN feedba= ck mechanism described herein, but I do like the modulated CC reaction, whi= ch I believe has merit to develop further. I tend to agree with Gorry, that the proper expertise to review the draft w= ould be in TCPM, but it probably should be submitted as AD sponsored inform= ational document. We have precedent for this - in TSVWG, the rtmfp spec was= dealt with similarily (disclaimer, I served as doc shepard for that). A st= andards-track document should resolve the ECN signaling issue (ie. by requi= ring AccECN on both ends) at the very least. Best regards, Richard > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael > (Michael) > Sent: Mittwoch, 22. April 2015 10:54 > To: tcpm@ietf.org > Subject: [tcpm] Feedback on WG acceptance of draft-bensley-tcpm-dctcp-03 >=20 > Dear all, >=20 > 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. >=20 > In order to move forward, the chairs seek for community guidance regardin= g > the following options to handle this draft: >=20 > a) Adopt in TCPM as Informational >=20 > b) Adopt in TCPM as Experimental >=20 > c) Do not adopt in TCPM now >=20 > Option c) does not prevent publication outside TCPM, such as publication > by another working group (e.g., TSVWG), publication on Independent Stream= , > etc. >=20 > 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. >=20 > Please let us know any feedback on a potential WG acceptance of draft- > bensley-tcpm-dctcp-03 until May 8. >=20 > Thanks! >=20 > Michael, Pasi, Yoshifumi >=20 >=20 > [1] http://www.ietf.org/proceedings/89/minutes/minutes-89-tcpm >=20 > [2] https://tools.ietf.org/html/draft-bensley-tcpm-dctcp-03 >=20 > [3] RFC 2026, Section 4.2.1, 4.2.2 >=20 > [4] https://www.ietf.org/iesg/informational-vs-experimental.html >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Apr 29 08:41:34 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 22B071A2119 for ; Wed, 29 Apr 2015 08:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 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, 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 WCLwm2egGSOT for ; Wed, 29 Apr 2015 08:41:26 -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 269291A6EF4 for ; Wed, 29 Apr 2015 08:41:20 -0700 (PDT) Received: by iecrt8 with SMTP id rt8so45381996iec.0 for ; Wed, 29 Apr 2015 08:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zDozdqYv9NgtiyBwQh0zzqjcacAE8Ayf/M3S9Z15kDg=; b=MUbwSgnqLmFddG90qlvR/9qj/mGXuxLLP4vbxV+6MsqJ1F6Teo+wi6774CifvEBA5L fP1ZlOosnQdqZ1smlzfGtGbmVDQJOaHBiaCA9hI791IUGLCqNqjq5la2AgeP+kV9AMWr P+9bVVSe2ZanOoZdqgrJZuVUnPcC11iFrc8EixkOGwYALCTCi1aYZu/Bsg0ADZxQhedV ZoqfMSoCePso+5M2n38TfTyjqBt0ekJ0964QY4ERTYDfLAmWXynSyaPsLr4K0LY3CYG6 lLDLvjFAtlI7bIihYgjENV3UQYrRLPm6MEc0y1Zrl7C9jWuj1phgMTkKZv1V1QmA2zRp 5Hgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zDozdqYv9NgtiyBwQh0zzqjcacAE8Ayf/M3S9Z15kDg=; b=Nrt1AnITz3vv6F6bHwQtvkdVyiXH+sVu/j34jbz/71s1ijuZoB3VECDrQV1ZvM6wyG Nw8Zllwoz3kICuom5Z5lD9JWqTjEaL/787Q68bW5VdDZPrUQ3JO6JXZdGzQH8ucDGR8T 53nHNOOyK8ODXiBS6pMpFiyynTaEOUPv4u4u94QGt5h4erIHV1OD26ushxBsheHa3f3R oCQ/ti9aJlardbWx/UuA+JH1fq3Lc+3zemh/H4DHNHtpbvCMkcTia8e2+yDqXXDLLNCT udIUapRTLP0VKTg0TwuqVnJZLZEZ1vLM4W75H0R/9fPRtYiWhj32IiCiDHFxDxa+IN1+ 0IMQ== X-Gm-Message-State: ALoCoQlxrsQkIzwNkk3tZrXKAwY5vG8EDpyl0puWmCTvolA3TzkuQ5y7CWbK6l9cmbGGrdVVtkox X-Received: by 10.50.114.9 with SMTP id jc9mr21478217igb.49.1430322079319; Wed, 29 Apr 2015 08:41:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.24.44 with HTTP; Wed, 29 Apr 2015 08:40:38 -0700 (PDT) In-Reply-To: References: <655C07320163294895BBADA28372AF5D16C939DA@FR712WXCHMBA15.zeu.alcatel-lucent.com> From: Yuchung Cheng Date: Wed, 29 Apr 2015 08:40:38 -0700 Message-ID: To: "Scheffenegger, Richard" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic-01 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, 29 Apr 2015 15:41:28 -0000 I vote for informational, unless the WG consensus recommends cubic as standard congestion control. On Wed, Apr 29, 2015 at 5:32 AM, Scheffenegger, Richard wrote: > Hi, > > I'm still in support, on standards track.. From my point of view, the definitions in [4] don't quite match here (but I would probably be content with informational, if something really limits submission as standards track). > > Best regards, > Richard > > > >> -----Original Message----- >> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael >> (Michael) >> Sent: Mittwoch, 22. April 2015 10:54 >> To: tcpm@ietf.org >> Subject: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic- >> 01 >> >> Dear all, >> >> During IETF 91 [1] and on the list there has been strong support for WG >> adoption of draft-zimmermann-tcpm-cubic [2]. It seems consensus in TCPM to >> adopt this document. >> >> In order to move forward, the chairs seek for additional community >> guidance regarding the intended status: >> >> a) Proposed standard >> >> b) Experimental >> >> c) Informational >> >> During IETF 91, there was strong support for Proposed Standard [1]. Yet, >> given the running code and the potential evolution of congestion control >> algorithms in future, the chairs want to ensure that there is strong >> consensus in TCPM on the intended status. Also, we would like to handle >> this question consistently among potential other alternative congestion >> control algorithms. >> >> Additional information regarding the RFC status can be found in [3], and >> there is also an IESG statement on the difference between Experimental and >> Informational [4]. >> >> Please let us know any feedback on the WG acceptance of draft-zimmermann- >> tcpm-cubic-01 and specifically the intended status until May 8. >> >> Thanks! >> >> Michael, Pasi, Yoshifumi >> >> >> [1] http://www.ietf.org/proceedings/91/minutes/minutes-91-tcpm >> >> [2] https://tools.ietf.org/html/draft-zimmermann-tcpm-cubic-01 >> >> [2] RFC 2026, Section 4.1.1, 4.2.1, 4.2.2 >> >> [3] https://www.ietf.org/iesg/informational-vs-experimental.html >> >> _______________________________________________ >> 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 Wed Apr 29 08:52: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 E36861A854D for ; Wed, 29 Apr 2015 08:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 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, 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 cnqc__ZeExA6 for ; Wed, 29 Apr 2015 08:52:09 -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 649AC1A8769 for ; Wed, 29 Apr 2015 08:52:02 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so110230496igb.0 for ; Wed, 29 Apr 2015 08:52:01 -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=3752ZtaVYcz+mVJrYjgW0KBK0pueRXDv8CXce/vhuNg=; b=T2BXFhAEkmblGwpPz9cmQL0ckveDASu6CzIN2tTIZsQxfho2Fgg1/8vCzF8aWElhcq fY85o5oDQNroMZcUpmu3Ag+wdLs1s1GTbO/WXn3Q2v8Q+f9Unm12dzx7GiOtH+IXCTZ5 bNBBSFIyZuAqnvPntWXRqXYPOcefRYiEO/WNPH+CFSC2SkqyrI3s444m8OgBGKjPeRub mnZdtqG6OixqRvp1OndjBBC5+DLQY+4u4TSHm7FlCW+AuvQmu1+1s7ZLFsmmPODJXyFT uRAop8G3DeG6Qh+tXcNVzAVTuSo5IP8WMJXvpR1fbtnHb94nVpFiO7AefVfhdUMZs57f iDdQ== 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=3752ZtaVYcz+mVJrYjgW0KBK0pueRXDv8CXce/vhuNg=; b=B3mEJ6k1iwKYMc8jomc4UJCxcWrXntX8XOLATRV8H0f7d3G3x0SCpiZ2vIKlNIlQ1F 0XrtqLVA0X/H9paL3wF5+/j7oo7xWAaOJ3SNQUTwFmSvXAfg1i9chb5UHZqV4PgreCJ+ +ja+vOMi57FfFWmTSG3nErn3r4OqbPDPTvdrnaL6KYy+/y5quoLL+nQ3p1pjwe6jlCg0 VwzLLuf/LCBWZSxUtroHYqhmGLwYqFeh7PodjzaPNallJw1+eOh27SiYLrzq2Su7v9pz YLiC2hI6gGBBRBt/Um0xjoFz0Wdb66X1Emkl3HGmxeULDmwmCABYcNW5gOD08enfNH4N S+EA== X-Gm-Message-State: ALoCoQk+rX/jGm4nKeC6b0b7lutHEzho0MkJEJzSJoIkxasd3yWIBku762I2NlYrnWX+Brpj0/DV MIME-Version: 1.0 X-Received: by 10.43.63.76 with SMTP id xd12mr4348185icb.11.1430322721704; Wed, 29 Apr 2015 08:52:01 -0700 (PDT) Received: by 10.107.132.95 with HTTP; Wed, 29 Apr 2015 08:52:01 -0700 (PDT) In-Reply-To: References: <655C07320163294895BBADA28372AF5D16C939DA@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Wed, 29 Apr 2015 11:52:01 -0400 Message-ID: From: Neal Cardwell To: Yuchung Cheng Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic-01 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, 29 Apr 2015 15:52:11 -0000 +1 for informational. neal On Wed, Apr 29, 2015 at 11:40 AM, Yuchung Cheng wrote: > I vote for informational, unless the WG consensus recommends cubic as > standard congestion control. > > On Wed, Apr 29, 2015 at 5:32 AM, Scheffenegger, Richard wrote: >> Hi, >> >> I'm still in support, on standards track.. From my point of view, the definitions in [4] don't quite match here (but I would probably be content with informational, if something really limits submission as standards track). >> >> Best regards, >> Richard >> >> >> >>> -----Original Message----- >>> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael >>> (Michael) >>> Sent: Mittwoch, 22. April 2015 10:54 >>> To: tcpm@ietf.org >>> Subject: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic- >>> 01 >>> >>> Dear all, >>> >>> During IETF 91 [1] and on the list there has been strong support for WG >>> adoption of draft-zimmermann-tcpm-cubic [2]. It seems consensus in TCPM to >>> adopt this document. >>> >>> In order to move forward, the chairs seek for additional community >>> guidance regarding the intended status: >>> >>> a) Proposed standard >>> >>> b) Experimental >>> >>> c) Informational >>> >>> During IETF 91, there was strong support for Proposed Standard [1]. Yet, >>> given the running code and the potential evolution of congestion control >>> algorithms in future, the chairs want to ensure that there is strong >>> consensus in TCPM on the intended status. Also, we would like to handle >>> this question consistently among potential other alternative congestion >>> control algorithms. >>> >>> Additional information regarding the RFC status can be found in [3], and >>> there is also an IESG statement on the difference between Experimental and >>> Informational [4]. >>> >>> Please let us know any feedback on the WG acceptance of draft-zimmermann- >>> tcpm-cubic-01 and specifically the intended status until May 8. >>> >>> Thanks! >>> >>> Michael, Pasi, Yoshifumi >>> >>> >>> [1] http://www.ietf.org/proceedings/91/minutes/minutes-91-tcpm >>> >>> [2] https://tools.ietf.org/html/draft-zimmermann-tcpm-cubic-01 >>> >>> [2] RFC 2026, Section 4.1.1, 4.2.1, 4.2.2 >>> >>> [3] https://www.ietf.org/iesg/informational-vs-experimental.html >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Apr 29 12:39:05 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 A94A61A0053 for ; Wed, 29 Apr 2015 12:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 fexeYd-uiHSJ for ; Wed, 29 Apr 2015 12:39:02 -0700 (PDT) Received: from mail-b.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A18A1A0023 for ; Wed, 29 Apr 2015 12:39:02 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t3TJcIXe014170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Apr 2015 12:38:18 -0700 (PDT) Message-ID: <55413329.5060002@isi.edu> Date: Wed, 29 Apr 2015 12:38:17 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Neal Cardwell , Yuchung Cheng References: <655C07320163294895BBADA28372AF5D16C939DA@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic-01 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, 29 Apr 2015 19:39:03 -0000 +1 On 4/29/2015 8:52 AM, Neal Cardwell wrote: > +1 for informational. > > neal > > On Wed, Apr 29, 2015 at 11:40 AM, Yuchung Cheng wrote: >> I vote for informational, unless the WG consensus recommends cubic as >> standard congestion control. >> >> On Wed, Apr 29, 2015 at 5:32 AM, Scheffenegger, Richard wrote: >>> Hi, >>> >>> I'm still in support, on standards track.. From my point of view, the definitions in [4] don't quite match here (but I would probably be content with informational, if something really limits submission as standards track). >>> >>> Best regards, >>> Richard >>> >>> >>> >>>> -----Original Message----- >>>> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael >>>> (Michael) >>>> Sent: Mittwoch, 22. April 2015 10:54 >>>> To: tcpm@ietf.org >>>> Subject: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic- >>>> 01 >>>> >>>> Dear all, >>>> >>>> During IETF 91 [1] and on the list there has been strong support for WG >>>> adoption of draft-zimmermann-tcpm-cubic [2]. It seems consensus in TCPM to >>>> adopt this document. >>>> >>>> In order to move forward, the chairs seek for additional community >>>> guidance regarding the intended status: >>>> >>>> a) Proposed standard >>>> >>>> b) Experimental >>>> >>>> c) Informational >>>> >>>> During IETF 91, there was strong support for Proposed Standard [1]. Yet, >>>> given the running code and the potential evolution of congestion control >>>> algorithms in future, the chairs want to ensure that there is strong >>>> consensus in TCPM on the intended status. Also, we would like to handle >>>> this question consistently among potential other alternative congestion >>>> control algorithms. >>>> >>>> Additional information regarding the RFC status can be found in [3], and >>>> there is also an IESG statement on the difference between Experimental and >>>> Informational [4]. >>>> >>>> Please let us know any feedback on the WG acceptance of draft-zimmermann- >>>> tcpm-cubic-01 and specifically the intended status until May 8. >>>> >>>> Thanks! >>>> >>>> Michael, Pasi, Yoshifumi >>>> >>>> >>>> [1] http://www.ietf.org/proceedings/91/minutes/minutes-91-tcpm >>>> >>>> [2] https://tools.ietf.org/html/draft-zimmermann-tcpm-cubic-01 >>>> >>>> [2] RFC 2026, Section 4.1.1, 4.2.1, 4.2.2 >>>> >>>> [3] https://www.ietf.org/iesg/informational-vs-experimental.html >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 Wed Apr 29 13:38:50 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 32F141A039D for ; Wed, 29 Apr 2015 13:38:49 -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 JlxJv9tu36o2 for ; Wed, 29 Apr 2015 13:38:45 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 165FD1A0196 for ; Wed, 29 Apr 2015 13:38:44 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YnYkk-0005K8-Fa for tcpm@ietf.org; Wed, 29 Apr 2015 22:38:42 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.114]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1YnYkk-0003Ue-1u for tcpm@ietf.org; Wed, 29 Apr 2015 22:38:42 +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: <55413329.5060002@isi.edu> Date: Wed, 29 Apr 2015 22:38:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <655C07320163294895BBADA28372AF5D16C939DA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <55413329.5060002@isi.edu> To: "tcpm@ietf.org" X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 5 sum rcpts/h 9 sum msgs/h 5 total rcpts 28134 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 44FF4A8B3BD02F41A7A09114B546053290BA504B X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 743 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic-01 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, 29 Apr 2015 20:38:49 -0000 +1 > On 29. apr. 2015, at 21.38, Joe Touch wrote: >=20 > +1 >=20 > On 4/29/2015 8:52 AM, Neal Cardwell wrote: >> +1 for informational. >>=20 >> neal >>=20 >> On Wed, Apr 29, 2015 at 11:40 AM, Yuchung Cheng = wrote: >>> I vote for informational, unless the WG consensus recommends cubic = as >>> standard congestion control. >>>=20 >>> On Wed, Apr 29, 2015 at 5:32 AM, Scheffenegger, Richard = wrote: >>>> Hi, >>>>=20 >>>> I'm still in support, on standards track.. =46rom my point of view, = the definitions in [4] don't quite match here (but I would probably be = content with informational, if something really limits submission as = standards track). >>>>=20 >>>> Best regards, >>>> Richard >>>>=20 >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, = Michael >>>>> (Michael) >>>>> Sent: Mittwoch, 22. April 2015 10:54 >>>>> To: tcpm@ietf.org >>>>> Subject: [tcpm] Feedback on WG acceptance of = draft-zimmermann-tcpm-cubic- >>>>> 01 >>>>>=20 >>>>> Dear all, >>>>>=20 >>>>> During IETF 91 [1] and on the list there has been strong support = for WG >>>>> adoption of draft-zimmermann-tcpm-cubic [2]. It seems consensus in = TCPM to >>>>> adopt this document. >>>>>=20 >>>>> In order to move forward, the chairs seek for additional community >>>>> guidance regarding the intended status: >>>>>=20 >>>>> a) Proposed standard >>>>>=20 >>>>> b) Experimental >>>>>=20 >>>>> c) Informational >>>>>=20 >>>>> During IETF 91, there was strong support for Proposed Standard = [1]. Yet, >>>>> given the running code and the potential evolution of congestion = control >>>>> algorithms in future, the chairs want to ensure that there is = strong >>>>> consensus in TCPM on the intended status. Also, we would like to = handle >>>>> this question consistently among potential other alternative = congestion >>>>> control algorithms. >>>>>=20 >>>>> Additional information regarding the RFC status can be found in = [3], and >>>>> there is also an IESG statement on the difference between = Experimental and >>>>> Informational [4]. >>>>>=20 >>>>> Please let us know any feedback on the WG acceptance of = draft-zimmermann- >>>>> tcpm-cubic-01 and specifically the intended status until May 8. >>>>>=20 >>>>> Thanks! >>>>>=20 >>>>> Michael, Pasi, Yoshifumi >>>>>=20 >>>>>=20 >>>>> [1] http://www.ietf.org/proceedings/91/minutes/minutes-91-tcpm >>>>>=20 >>>>> [2] https://tools.ietf.org/html/draft-zimmermann-tcpm-cubic-01 >>>>>=20 >>>>> [2] RFC 2026, Section 4.1.1, 4.2.1, 4.2.2 >>>>>=20 >>>>> [3] https://www.ietf.org/iesg/informational-vs-experimental.html >>>>>=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 >>>=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 >>=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Apr 29 14:25: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 33F191A079D for ; Wed, 29 Apr 2015 14:25:16 -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 ell_qHYWoHPQ for ; Wed, 29 Apr 2015 14:25:14 -0700 (PDT) Received: from mail-vn0-x229.google.com (mail-vn0-x229.google.com [IPv6:2607:f8b0:400c:c0f::229]) (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 E16AE1A1AD3 for ; Wed, 29 Apr 2015 14:25:13 -0700 (PDT) Received: by vnbf1 with SMTP id f1so5063034vnb.5 for ; Wed, 29 Apr 2015 14:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=Hsn6Iq2GZdSOuUaL1RUpwevpetbwbDmhrkSVhKTfDrI=; b=qml7FzbZ6atKhle531tUeger4FmhHAzMBBm1zQa7rd1pnZ3k+q99QFWxoZ18D1WnHm L76Ak2jo6gyE1T2KsdNOVQ3SMdddRmJQOqxt4ZCBrnYD/4sZOty8KQ/mxu2oyjg/zV40 WdYn7eP/cg7A+YnadZvPwsqsos8XkpogB5CP97nlbeur+TdM/JCnYO1kLOIUeukPviCE PRX+azpNSlc2JlWyFJCmGkOiU1uAlXw2d6C+LBNBtVhRmLYWEZkDFkoVZR5Q/GpcEzUf o0BrAi0OLYdSVN6Dg7FDvchJeQ1ILqXBECGs1ALcpFdCx9/KTfty1C565Pl5PWv6rW1x EoLA== X-Received: by 10.52.24.113 with SMTP id t17mr1895956vdf.89.1430342713030; Wed, 29 Apr 2015 14:25:13 -0700 (PDT) Received: from still.local (184-19-93-177.drr03.clbg.wv.frontiernet.net. [184.19.93.177]) by mx.google.com with ESMTPSA id em10sm383795vdc.22.2015.04.29.14.25.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Apr 2015 14:25:12 -0700 (PDT) To: tcpm@ietf.org references: <655C07320163294895BBADA28372AF5D16C939DA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <55413329.5060002@isi.edu> From: Tim Wicinski message-id: <55414C38.4030009@gmail.com> Date: Wed, 29 Apr 2015 17:25:12 -0400 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:39.0) Gecko/20100101 Thunderbird/39.0a2 mime-version: 1.0 in-reply-to: <55413329.5060002@isi.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic-01 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, 29 Apr 2015 21:25:16 -0000 +1 on informational. tim On 4/29/15 3:38 PM, Joe Touch wrote: > +1 > > On 4/29/2015 8:52 AM, Neal Cardwell wrote: >> +1 for informational. >> >> neal >> >> On Wed, Apr 29, 2015 at 11:40 AM, Yuchung Cheng wrote: >>> I vote for informational, unless the WG consensus recommends cubic as >>> standard congestion control. >>> >>> On Wed, Apr 29, 2015 at 5:32 AM, Scheffenegger, Richard wrote: >>>> Hi, >>>> >>>> I'm still in support, on standards track.. From my point of view, the definitions in [4] don't quite match here (but I would probably be content with informational, if something really limits submission as standards track). >>>> >>>> Best regards, >>>> Richard >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael >>>>> (Michael) >>>>> Sent: Mittwoch, 22. April 2015 10:54 >>>>> To: tcpm@ietf.org >>>>> Subject: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic- >>>>> 01 >>>>> >>>>> Dear all, >>>>> >>>>> During IETF 91 [1] and on the list there has been strong support for WG >>>>> adoption of draft-zimmermann-tcpm-cubic [2]. It seems consensus in TCPM to >>>>> adopt this document. >>>>> >>>>> In order to move forward, the chairs seek for additional community >>>>> guidance regarding the intended status: >>>>> >>>>> a) Proposed standard >>>>> >>>>> b) Experimental >>>>> >>>>> c) Informational >>>>> >>>>> During IETF 91, there was strong support for Proposed Standard [1]. Yet, >>>>> given the running code and the potential evolution of congestion control >>>>> algorithms in future, the chairs want to ensure that there is strong >>>>> consensus in TCPM on the intended status. Also, we would like to handle >>>>> this question consistently among potential other alternative congestion >>>>> control algorithms. >>>>> >>>>> Additional information regarding the RFC status can be found in [3], and >>>>> there is also an IESG statement on the difference between Experimental and >>>>> Informational [4]. >>>>> >>>>> Please let us know any feedback on the WG acceptance of draft-zimmermann- >>>>> tcpm-cubic-01 and specifically the intended status until May 8. >>>>> >>>>> Thanks! >>>>> >>>>> Michael, Pasi, Yoshifumi >>>>> >>>>> >>>>> [1] http://www.ietf.org/proceedings/91/minutes/minutes-91-tcpm >>>>> >>>>> [2] https://tools.ietf.org/html/draft-zimmermann-tcpm-cubic-01 >>>>> >>>>> [2] RFC 2026, Section 4.1.1, 4.2.1, 4.2.2 >>>>> >>>>> [3] https://www.ietf.org/iesg/informational-vs-experimental.html >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Thu Apr 30 00:06:42 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 CC94B1ACDB8 for ; Thu, 30 Apr 2015 00:06:40 -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 DyAVWDT1gilX for ; Thu, 30 Apr 2015 00:06:39 -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 C595F1ACE5B for ; Thu, 30 Apr 2015 00:06:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,675,1422950400"; d="scan'208";a="38876627" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx143-out.netapp.com with ESMTP; 30 Apr 2015 00:06:20 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 30 Apr 2015 00:06:20 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::f07f:691d:89d:53b7%21]) with mapi id 15.00.0995.031; Thu, 30 Apr 2015 00:06:20 -0700 From: "Eggert, Lars" To: "Scheffenegger, Richard" Thread-Topic: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic-01 Thread-Index: AQHQgniiqREnpx5A60G89rjx0bjeqZ1lmLqA Date: Thu, 30 Apr 2015 07:06:20 +0000 Message-ID: <33E3613D-55E0-4213-BADD-0DFE7B5F8C17@netapp.com> References: <655C07320163294895BBADA28372AF5D16C939DA@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic-01 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, 30 Apr 2015 07:06:41 -0000 On 2015-4-29, at 14:32, Scheffenegger, Richard wrote: > I'm still in support, on standards track. Me too, given that this has been the default CC on Linux for years now. Wha= t's the reason for Informational; that this was done outside of the IETF an= d therefore doesn't deserve PS? That seems a bit dogmatic given the amount = of real world experience. But: I'd rather see it published as Informational that not at all. Lars= From nobody Thu Apr 30 02:33: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 6B1E81A90B0 for ; Thu, 30 Apr 2015 02:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 eZ5Nv5oOjxkA for ; Thu, 30 Apr 2015 02:33:35 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 A023B1A8F4A for ; Thu, 30 Apr 2015 02:33:35 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id A99BC8C9C62F7; Thu, 30 Apr 2015 09:33:31 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t3U9XWa9020387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Apr 2015 11:33:33 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 30 Apr 2015 11:33:33 +0200 From: "Scharf, Michael (Michael)" To: "Eggert, Lars" , "Scheffenegger, Richard" Thread-Topic: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic-01 Thread-Index: AQHQgxQ/N9XmkWoYjEWmlI1mablVN51lQH/Q Date: Thu, 30 Apr 2015 09:33:32 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C9B525@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D16C939DA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <33E3613D-55E0-4213-BADD-0DFE7B5F8C17@netapp.com> In-Reply-To: <33E3613D-55E0-4213-BADD-0DFE7B5F8C17@netapp.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic-01 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, 30 Apr 2015 09:33:37 -0000 > On 2015-4-29, at 14:32, Scheffenegger, Richard wrote: > > I'm still in support, on standards track. >=20 > Me too, given that this has been the default CC on Linux for years now. > What's the reason for Informational; that this was done outside of the > IETF and therefore doesn't deserve PS? That seems a bit dogmatic given > the amount of real world experience. In my view, there is sufficient real world experience, and we had quite a n= umber of TCPM and ICCRG discussions on CUBIC in the past. I actually care more about another aspect: The CUBIC algorithm have evolved= in the past, at least regarding details, and it would be a surprise if thi= s evolution would stop.=20 I think the key question is whether we can come up with one "standardized" = version of CUBIC that will hopefully be stable for some time, or whether th= e best we can do in TCPM is to document some snapshot of the algorithm. Bot= h options seem possible to me in principle, but the former one requires mor= e community effort to ensure that the document will not be outdated soon. > But: I'd rather see it published as Informational that not at all. In any case, there seems to be unanimous consensus that we will publish a d= ocument draft-ietf-tcpm-cubic. Maybe a related follow-up question should be: What is the expected time-fra= me for the milestone of submitting draft-ietf-tcpm-cubic to the IESG? 2015?= 2016? 2017? Any thoughts? Michael PS: Bob raised a similar question on the AQM list: http://www.ietf.org/mail= -archive/web/aqm/current/msg01159.html From nobody Thu Apr 30 07:30: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 31AFA1B2B74 for ; Thu, 30 Apr 2015 07:30:38 -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 9HOm4mMLK6ID for ; Thu, 30 Apr 2015 07:30:37 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78DBC1B2B83 for ; Thu, 30 Apr 2015 07:30:19 -0700 (PDT) Received: from [192.168.1.11] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t3UETxow004764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Apr 2015 07:30:09 -0700 (PDT) Message-ID: <55423C67.8020506@isi.edu> Date: Thu, 30 Apr 2015 07:29:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Eggert, Lars" , "Scheffenegger, Richard" References: <655C07320163294895BBADA28372AF5D16C939DA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <33E3613D-55E0-4213-BADD-0DFE7B5F8C17@netapp.com> In-Reply-To: <33E3613D-55E0-4213-BADD-0DFE7B5F8C17@netapp.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t3UETxow004764 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic-01 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, 30 Apr 2015 14:30:38 -0000 On 4/30/2015 12:06 AM, Eggert, Lars wrote: > On 2015-4-29, at 14:32, Scheffenegger, Richard wrote: >> I'm still in support, on standards track. > > Me too, given that this has been the default CC on Linux for years > now. What's the reason for Informational; that this was done outside of > the IETF and therefore doesn't deserve PS? That seems a bit dogmatic > given the amount of real world experience. PS would imply that the CUBIC community was coming to the IETF and willing to accept "rough consensus", which might result in changes. Informational is appropriate for de-facto standards that are NOT being taken to the IETF for that consensus process. Given the history of this alg, Information is the best that can happen unless we're opening it up for changes. Joe From nobody Thu Apr 30 07:34:41 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 497411B2BD0 for ; Thu, 30 Apr 2015 07:34:40 -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 hzV6VlQL9cuK for ; Thu, 30 Apr 2015 07:34:38 -0700 (PDT) Received: from mail-vn0-x231.google.com (mail-vn0-x231.google.com [IPv6:2607:f8b0:400c:c0f::231]) (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 77BDC1B2BCA for ; Thu, 30 Apr 2015 07:34:38 -0700 (PDT) Received: by vnbg7 with SMTP id g7so7390797vnb.10 for ; Thu, 30 Apr 2015 07:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=N8Xeifwu8/IZrKxpY25mny4O5mHlh+k+GYqs0aBfcRQ=; b=uLXUiEKv8vLa/hVp96rSTIJ3mCj3hVmaROzV+hhasD0BIQPBCIQfef/uAQz28kMRMk ZwwWqBG96cEJcO6TPJBgF7dIzsK22NCMD0d/jOPA28VI1DZWgPWxd0nczteEoCJa/b/B r6nOlPpaFOf0VYpaiRgeaOp87OuN0JK0A/WfKf6H0FIPPiIKqw7JhgtpmYYS6/5KKxyy hII+JN/8Em6h3S7J1yr+aBuQ8CybpaPmwDRYJQm2S5VFwYvzo/88l9dfbtWHMXA7o8zK 1Tl2WirYkJOhPzaK3IyptO2J7ZzTy2X3BmQ3jKxneQti2FheNFuOA42/Rh5+FqRYw4/s UwTA== X-Received: by 10.52.176.103 with SMTP id ch7mr8142716vdc.68.1430404477621; Thu, 30 Apr 2015 07:34:37 -0700 (PDT) Received: from still.local (184-19-93-177.drr03.clbg.wv.frontiernet.net. [184.19.93.177]) by mx.google.com with ESMTPSA id ms8sm3608662vdb.21.2015.04.30.07.34.36 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Apr 2015 07:34:36 -0700 (PDT) To: tcpm@ietf.org references: <655C07320163294895BBADA28372AF5D16C939DA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <33E3613D-55E0-4213-BADD-0DFE7B5F8C17@netapp.com> <55423C67.8020506@isi.edu> From: Tim Wicinski message-id: <55423D7C.8010302@gmail.com> Date: Thu, 30 Apr 2015 10:34:36 -0400 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:39.0) Gecko/20100101 Thunderbird/39.0a2 mime-version: 1.0 in-reply-to: <55423C67.8020506@isi.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic-01 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, 30 Apr 2015 14:34:40 -0000 Experimental is also an option, if the WG is not sure on deployment. tim On 4/30/15 10:29 AM, Joe Touch wrote: > > > On 4/30/2015 12:06 AM, Eggert, Lars wrote: >> On 2015-4-29, at 14:32, Scheffenegger, Richard wrote: >>> I'm still in support, on standards track. >> >> Me too, given that this has been the default CC on Linux for years >> now. What's the reason for Informational; that this was done outside of >> the IETF and therefore doesn't deserve PS? That seems a bit dogmatic >> given the amount of real world experience. > > PS would imply that the CUBIC community was coming to the IETF and > willing to accept "rough consensus", which might result in changes. > > Informational is appropriate for de-facto standards that are NOT being > taken to the IETF for that consensus process. > > Given the history of this alg, Information is the best that can happen > unless we're opening it up for changes. > > Joe > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Thu Apr 30 07:51:21 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 8DC611B2C7D for ; Thu, 30 Apr 2015 07:51:20 -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 0xdTp9e581ou for ; Thu, 30 Apr 2015 07:51:19 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C19B1B2C83 for ; Thu, 30 Apr 2015 07:51:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,677,1422950400"; d="scan'208";a="39520180" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx144-out.netapp.com with ESMTP; 30 Apr 2015 07:46:17 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 30 Apr 2015 07:46:17 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com ([::1]) by hioexcmbx05-prd.hq.netapp.com ([fe80::29f7:3e3f:78c5:a0bc%21]) with mapi id 15.00.0995.031; Thu, 30 Apr 2015 07:46:17 -0700 From: "Scheffenegger, Richard" To: "Eggert, Lars" Thread-Topic: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic-01 Thread-Index: AQHQgxQp01Djqlpmhk+8oiC1GTHuN51locaQ Date: Thu, 30 Apr 2015 14:46:16 +0000 Message-ID: <9dc614eb40cd416185a8f5cb1cd0f3ce@hioexcmbx05-prd.hq.netapp.com> References: <655C07320163294895BBADA28372AF5D16C939DA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <33E3613D-55E0-4213-BADD-0DFE7B5F8C17@netapp.com> In-Reply-To: <33E3613D-55E0-4213-BADD-0DFE7B5F8C17@netapp.com> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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" Subject: Re: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic-01 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, 30 Apr 2015 14:51:20 -0000 Lars, Alex, correct me if I'm wrong, but my understanding was that the draft has been r= eleased by the original authors for community discussion and feedback, righ= t? So if the mechanism can be improved, any feedback to that effect could b= e added even if it means that the draft does no longer match what is in Lin= ux (iOS, BSD)... At least that was the basis for me to support PS status... Best regards, Richard > -----Original Message----- > From: Eggert, Lars > Sent: Donnerstag, 30. April 2015 09:06 > To: Scheffenegger, Richard > Cc: Scharf, Michael (Michael); tcpm@ietf.org > Subject: Re: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm- > cubic-01 >=20 > On 2015-4-29, at 14:32, Scheffenegger, Richard wrote: > > I'm still in support, on standards track. >=20 > Me too, given that this has been the default CC on Linux for years now. > What's the reason for Informational; that this was done outside of the > IETF and therefore doesn't deserve PS? That seems a bit dogmatic given th= e > amount of real world experience. >=20 > But: I'd rather see it published as Informational that not at all. >=20 > Lars From nobody Thu Apr 30 07:57:30 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 70F931A1BB8 for ; Thu, 30 Apr 2015 07:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 fUOUmNA02vb0 for ; Thu, 30 Apr 2015 07:57:23 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 3372D1B2C8A for ; Thu, 30 Apr 2015 07:57:18 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 28401754B83EA for ; Thu, 30 Apr 2015 14:57:14 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t3UEuwkG018753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Apr 2015 16:57:13 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.102]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 30 Apr 2015 16:57:04 +0200 From: "Scharf, Michael (Michael)" To: Tim Wicinski , "tcpm@ietf.org" Thread-Topic: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic-01 Thread-Index: AQHQgxQ/N9XmkWoYjEWmlI1mablVN51lfJaAgAABSgCAACSucA== Date: Thu, 30 Apr 2015 14:57:03 +0000 Message-ID: <655C07320163294895BBADA28372AF5D16C9BAD2@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D16C939DA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <33E3613D-55E0-4213-BADD-0DFE7B5F8C17@netapp.com> <55423C67.8020506@isi.edu> <55423D7C.8010302@gmail.com> In-Reply-To: <55423D7C.8010302@gmail.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] 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-zimmermann-tcpm-cubic-01 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, 30 Apr 2015 14:57:25 -0000 Yes, experimental is another option. RFC 3649 (Highspeed TCP) is Experiment= al. But I'd assume there is much more operational deployment experience with CU= BIC than with RFC 3649, i.e., it is actually not an apply-to-apple comparis= on. Michael > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Tim Wicinski > Sent: Thursday, April 30, 2015 4:35 PM > To: tcpm@ietf.org > Subject: Re: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm- > cubic-01 >=20 >=20 > Experimental is also an option, if the WG is not sure on deployment. >=20 > tim >=20 >=20 > On 4/30/15 10:29 AM, Joe Touch wrote: > > > > > > On 4/30/2015 12:06 AM, Eggert, Lars wrote: > >> On 2015-4-29, at 14:32, Scheffenegger, Richard > wrote: > >>> I'm still in support, on standards track. > >> > >> Me too, given that this has been the default CC on Linux for years > >> now. What's the reason for Informational; that this was done outside > of > >> the IETF and therefore doesn't deserve PS? That seems a bit dogmatic > >> given the amount of real world experience. > > > > PS would imply that the CUBIC community was coming to the IETF and > > willing to accept "rough consensus", which might result in changes. > > > > Informational is appropriate for de-facto standards that are NOT > being > > taken to the IETF for that consensus process. > > > > Given the history of this alg, Information is the best that can > happen > > unless we're opening it up for changes. > > > > Joe > > > > _______________________________________________ > > 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 Apr 30 08:03: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 AE5F61B2CE5 for ; Thu, 30 Apr 2015 08:03:12 -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 VZACbPVyx6Dw for ; Thu, 30 Apr 2015 08:03:08 -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 D0B841B2D04 for ; Thu, 30 Apr 2015 08:01:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.11,677,1422950400"; d="asc'?scan'208";a="38219138" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx142-out.netapp.com with ESMTP; 30 Apr 2015 07:56:00 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 30 Apr 2015 07:56:00 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::f07f:691d:89d:53b7%21]) with mapi id 15.00.0995.031; Thu, 30 Apr 2015 07:55:59 -0700 From: "Eggert, Lars" To: "Scheffenegger, Richard" Thread-Topic: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic-01 Thread-Index: AQHQgniiqREnpx5A60G89rjx0bjeqZ1lmLqAgACAfwCAAAK2AA== Date: Thu, 30 Apr 2015 14:55:59 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D16C939DA@FR712WXCHMBA15.zeu.alcatel-lucent.com> <33E3613D-55E0-4213-BADD-0DFE7B5F8C17@netapp.com> <9dc614eb40cd416185a8f5cb1cd0f3ce@hioexcmbx05-prd.hq.netapp.com> In-Reply-To: <9dc614eb40cd416185a8f5cb1cd0f3ce@hioexcmbx05-prd.hq.netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_6C25BF77-8E6E-4CE0-AD5A-D8DADEF6AA91"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic-01 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, 30 Apr 2015 15:03:12 -0000 --Apple-Mail=_6C25BF77-8E6E-4CE0-AD5A-D8DADEF6AA91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2015-4-30, at 16:46, Scheffenegger, Richard wrote: > correct me if I'm wrong, but my understanding was that the draft has = been released by the original authors for community discussion and = feedback, right? It is submitted with the regular ID boilerplate, and if adopted, I guess = the WG could do whatever it wanted with the content. > So if the mechanism can be improved, any feedback to that effect could = be added even if it means that the draft does no longer match what is in = Linux (iOS, BSD)... That would be one outcome, but I'm not sure how useful it would be, = because then we'd again have a document that documents something, but = that something is not what the actual code does. There are a bunch of Linux committers on this list, so I guess if TCPM = had good improvements to make, there is a chance they would make it back = into the code, but it's not automatic. Do we think that the WG can make substantial improvements to the = algorithm? (Not the ID text, the algorithm.) I don't know. I guess we = are in a better position to answer this once the document has captured = what the current code is actually doing, which at the moment it doesn't = yet. So maybe we table this discussion for a while? Lars --Apple-Mail=_6C25BF77-8E6E-4CE0-AD5A-D8DADEF6AA91 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----- iEYEARECAAYFAlVCQn4ACgkQIWcjmsUTWRr3NgCgqfbcg6PXNIBU7N7HPNAdGxZD 31wAnixsB2XI58ZejL4lOalsvab3/UhW =rMvk -----END PGP SIGNATURE----- --Apple-Mail=_6C25BF77-8E6E-4CE0-AD5A-D8DADEF6AA91-- From nobody Thu Apr 30 23:03:01 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 2F9F41B2F7B for ; Thu, 30 Apr 2015 23:03:00 -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 8G9IPh7oblbM for ; Thu, 30 Apr 2015 23:02:59 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (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 06BD41B2F79 for ; Thu, 30 Apr 2015 23:02:59 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so94437219ied.1 for ; Thu, 30 Apr 2015 23:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gPIdP51NzEmPA7FyQvEblaTe+84CmvBukkcp8eH+yvY=; b=k2eJSZXXTWA0dEJgXRfJ3ABZFoVrO3NswREX/eRJYa77yP+yNTtleFZy0WWeFjo6kZ D4QOFGbgDtO8C1MTHlrQBHj7SRdpt+mmXbGrYKYUNTOuQlGJmHJNdLyQPk1KPJRRDDUk 2PEJ/eXSwNqrOqN9v1MXWmHzipGIVYZZXpo3WwKUaT3bZ4Qlfj7o5vgj3mU8kalIkk/7 TB72sCfNQcfycudbBSTKF+4Hrhucl1dwJAT1HzTEkI18BlBNm1EQJoTHhcoMrg8FWEh5 82rVvJQKrVQS2fWwd6VlLINS8lfjMHSQXu7qoJTGYy+/N6Q+fxvnzG1b5gx6flQOaQmi +HxA== MIME-Version: 1.0 X-Received: by 10.107.160.202 with SMTP id j193mr10369627ioe.43.1430460178546; Thu, 30 Apr 2015 23:02:58 -0700 (PDT) Received: by 10.50.25.231 with HTTP; Thu, 30 Apr 2015 23:02:58 -0700 (PDT) In-Reply-To: <655C07320163294895BBADA28372AF5D16C939DA@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D16C939DA@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Fri, 1 May 2015 10:02:58 +0400 Message-ID: From: Loganaden Velvindron To: "Scharf, Michael (Michael)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Feedback on WG acceptance of draft-zimmermann-tcpm-cubic-01 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, 01 May 2015 06:03:00 -0000 On Wed, Apr 22, 2015 at 12:53 PM, Scharf, Michael (Michael) wrote: > Dear all, > > During IETF 91 [1] and on the list there has been strong support for WG adoption of draft-zimmermann-tcpm-cubic [2]. It seems consensus in TCPM to adopt this document. > > In order to move forward, the chairs seek for additional community guidance regarding the intended status: > > a) Proposed standard > > b) Experimental > > c) Informational > Informational seems like a good choice for now.