From nobody Sat Mar  1 11:56:48 2014
Return-Path: <gorry@erg.abdn.ac.uk>
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 2D5EA1A0165 for <tcpm@ietfa.amsl.com>; Sat,  1 Mar 2014 11:56:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.048
X-Spam-Level: 
X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 iblZAF621RtJ for <tcpm@ietfa.amsl.com>; Sat,  1 Mar 2014 11:56:44 -0800 (PST)
Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF961A026A for <tcpm@ietf.org>; Sat,  1 Mar 2014 11:56:44 -0800 (PST)
Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 264B32B40C5; Sat,  1 Mar 2014 19:56:41 +0000 (GMT)
Received: from 88.96.136.84 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Sat, 1 Mar 2014 19:56:41 -0000
Message-ID: <12cbda88bf79e1f39e9bd3013e0bf3cf.squirrel@www.erg.abdn.ac.uk>
In-Reply-To: <20140227172145.2D9F2376E288@lawyers.icir.org>
References: <20140227172145.2D9F2376E288@lawyers.icir.org>
Date: Sat, 1 Mar 2014 19:56:41 -0000
From: gorry@erg.abdn.ac.uk
To: mallman@icir.org
User-Agent: SquirrelMail/1.4.22
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/SLIik49Pa9jKYNOFdTpQvgfrQyM
Cc: raffaello@erg.abdn.ac.uk, tcpm@ietf.org
Subject: Re: [tcpm] thoughts on newcwv-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Mar 2014 19:56:47 -0000

See below for a first-answer,

Gorry

>
>> : Actually this is more difficult that it seems, the terminology in
>> : RFC 2861 referred to something different, and for quite some time
>> : the WG have used the new terminology.
>> : We can and will note this in the intro.
>
> It seems this is more than a quick note.  If 'rate limited' is different
> From what RFC 2681 addresses then does that document still hold when a
> sender is idle or application limited?  Or, do you somehow subsume those
> periods, too?  I am not taking a position on any of this.  I am just
> asking that the document be clear and precise on what problem it is
> going after and where it sits relative to other documents in the space.
>
I was thinking that we actually had to add some text, on this specific
point I was thinking along the lines of the text below - does this help
explain why the old terminology is different?:

<?xml version="1.0"?>
<ns:clipboard
xmlns:ns="http://www.xmlmind.com/xmleditor/namespace/clipboard">
<t>
RFC2681 proposed two set of responses, one after an
"application-limited" and one after an "idle period". Although this
distinction was argued, in practice differentiating the two behaviours
was problematic in actual networks. This resulted in
a performance for a busty application that depended both upon the RTO and
the pattern of application traffic relative to the RTO interval.
This lead to unpredictable performance for application designers who
are unaware of the network path RTT.

We argue that RFC2861's attempt to identify 2 application
behaviours is problematic and inappropriate, and this document therefore
explicitly avoids trying to differentiate these two behaviours.
Instead new-CWV uses single method for all rate-limited traffic that
seeks to provide predictable performance by preserving the cwnd.
</t>
</ns:clipboard>

>> : We will look at the possibility of reorganising the order of sections.
>
> (Or collapsing them might work, too.)
>
>>   + I think this:
>>
>>       Reception of congestion feedback while in the non-validated phase
>>       is interpreted as an indication that it was inappropriate for the
>>       sender to use the preserved cwnd.  The sender is therefore
>>       required to quickly reduce the rate to avoid further congestion.
>>       Since the cwnd does not have a validated value, a new cwnd value
>>       must be selected based on the utilised rate.
>>
>>     is exactly what RFC 5681 says.  I.e., it is why we changed things to
>>     be based on FlightSize.  I.e., it doesn't matter what is poked into
>>     "cwnd" at a given time, FlightSize is the load being imposed on the
>>     network and so that is the basis for the reaction to congestion.
>>
>>     So, my reading of things is that RFC 5681 **already does** what you
>>     say you want in the above blurb.
>>
>> : Except that Eqtn 4 in RFC 5681 does not consider the amount of losses
>> : during a congestion episode.
>> : If it was not validated, we argue that FS may be much
>> : larger than actual capacity and hence the "-R" reduction is important.
>
> OK, but you do not argue for the -R.  And, if -R is important here is it
> not important everywhere?  You should explain your choices here.
>
We will add text on the -R choice.

>> : Now, your argument isn't quite true. Two things to recall:
>> : First, in the NVP pipeACK is by definition less than (cwnd/2).
>
> OK, fair enough point ... this point was (is) lost on me.  Perhaps the
> document, perhaps my sloppy reading.
>
>> : Fair enough, at this time we didn't see any specific changes to the
>> : algorithm, but a need for clearer rationale and a set of corrections.
>> : We plan to include these in the next revision.
>
> Just to be clear it seems to me this document needs "clearer rationale"
> in a bunch of places (some of which may well overlap) ...
>
> (1) The document should include a discussion of why the current
>     standards (here I am thinking of RFCs 5681 & 2681) are not well
>     suited to modern application behavior.
>
Sure, we'll look to this.

> (2) Since you're proposing something more aggressive I'd think a
>     discussion of not only why an application would want to be more
>     aggressive, but also why it is reasonable to loosen the congestion
>     controller to accommodate such applications.  (E.g., we would agree
>     that an application that wants CBR = 1Gbps with no reduction ever is
>     unreasonable.

:-) I think we can agree that I would argue against that in any draft!

>     So, applications don't always get what they want.
>     What you are trying to do---it seems to me---is give the
>     applications something that helps them out, but that is also
>     reasonable congestion control-wise.)
>
We are indeed trying to give applications something that helps them out,
but is also  reasonable for congestion control. We will look again
how to make the text clearer about this.

> (3) If you're going to strive to meet requirements then we should know
>     what those requirements actually are.  (I am not sure you really
>     need to do either.  But, if you're going to do one, do both.)
>
> (4) The above is big picture stuff.  But, you should justify the
>     mechanism, as well.  Don't just use magic constants without
>     justification (or via fuzzy and ambiguous reasoning).  Don't just
>     add aspects of the response (like the "- R" notion) by claiming they
>     are crucial without explaining.  Etc.  The specifics of the
>     mechanism should be rooted in the overall goals and TCP's standard
>     behavior, it seems to me.  And, you should be able to spell that
>     out.
>
> allman
>
We'll post a new draft when we can finish the text,

Gorry



From nobody Sun Mar  2 23:36:17 2014
Return-Path: <martin.winbjork@ericsson.com>
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 CEB991A0CA5 for <tcpm@ietfa.amsl.com>; Sun,  2 Mar 2014 23:36:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.551
X-Spam-Level: 
X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyTLMQnjWWq5 for <tcpm@ietfa.amsl.com>; Sun,  2 Mar 2014 23:36:12 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E562F1A0BF8 for <tcpm@ietf.org>; Sun,  2 Mar 2014 23:36:11 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-c0-531430e81a3e
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 8E.F7.23809.8E034135; Mon,  3 Mar 2014 08:36:08 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.128]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0387.000; Mon, 3 Mar 2014 08:36:07 +0100
From: =?utf-8?B?TWFydGluIFdpbmJqw7Zyaw==?= <martin.winbjork@ericsson.com>
To: Yuchung Cheng <ycheng@google.com>
Thread-Topic: TCP Tail Loss Probe
Thread-Index: Ac80kCQu6lpocKtXSlyq1O7Kw8QrmAAG0N0AAIHMc2A=
Date: Mon, 3 Mar 2014 07:36:07 +0000
Message-ID: <7FD625EF1E1B1D4586EEAB7471ECDC0A200512@ESESSMB109.ericsson.se>
References: <7FD625EF1E1B1D4586EEAB7471ECDC0A200469@ESESSMB109.ericsson.se> <CAK6E8=d1+5OFvHUX2xPZaS1zuEnfZQSYbEuWc18K05S3MJ_W=A@mail.gmail.com>
In-Reply-To: <CAK6E8=d1+5OFvHUX2xPZaS1zuEnfZQSYbEuWc18K05S3MJ_W=A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+Jvje4LA5Fgg4a1Khbnz11itdj3YSuT RcedvSwW207OZ7L48vgqmwOrx4JNpR5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4uPkxW8E7oYqJ 768wNTBuEOpi5OSQEDCR2HBkJiOELSZx4d56ti5GLg4hgUOMEst3HWeBcBYzSnz/8oUZpIpN wFNiyrNVTCC2iICqROuF7UwgRcwC7xgl/m16DlYkLKAg8fnONUaIIkWJJ/s2QjVYSfTOnsMO YrMIqEhsejmBDcTmFfCWmLJhEyPEtkmMErNn/AVr4BQIlGjt2Ac2iBHovu+n1oDFmQXEJW49 mc8EcbeAxJI955khbFGJl4//sULYihI7z7YDxTmA6jUl1u/Sh2hVlJjS/ZAdYq+gxMmZT1gm MIrNQjJ1FkLHLCQds5B0LGBkWcXInpuYmZNebrSJERhBB7f8Vt3BeOecyCFGaQ4WJXHeD2+d g4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw6qerPHkz1Wme7JtLO2V/8L/6emXJtuT9so/4 tm7TNLEw0bzKUyd1xGJN2Mf2vn1xXrMK/72JNo81iJny8JhV+uztWWturj+sLNt5Tf/fn/PX 9v7LkT1krtKxwvh9Rwf3NqVV07g5N0yx83gclDXtV3tFhXt7w8yJEZNEP6tv3Ma3JPjPiwr3 RiWW4oxEQy3mouJEAEffu/BuAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/0DIF5Sf7-K-pj396xUC7zxZe8NE
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "mattmathis@google.com" <mattmathis@google.com>
Subject: Re: [tcpm] TCP Tail Loss Probe
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Mar 2014 07:36:15 -0000

SGkNCg0KVGhhbmsgeW91IGZvciB0aGUgYW5zd2VyDQoNClJlZ2FyZHMNCk1hcnRpbiBXaW5iasO2
cmsNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFl1Y2h1bmcgQ2hlbmcgW21h
aWx0bzp5Y2hlbmdAZ29vZ2xlLmNvbV0gDQpTZW50OiBkZW4gMjggZmVicnVhcmkgMjAxNCAxOToz
NQ0KVG86IE1hcnRpbiBXaW5iasO2cmsNCkNjOiB0Y3BtQGlldGYub3JnOyBuYW5kaXRhZEBnb29n
bGUuY29tOyBuY2FyZHdlbGxAZ29vZ2xlLmNvbTsgbWF0dG1hdGhpc0Bnb29nbGUuY29tOyBJbmdl
bWFyIEpvaGFuc3NvbiBTDQpTdWJqZWN0OiBSZTogVENQIFRhaWwgTG9zcyBQcm9iZQ0KDQpPbiBG
cmksIEZlYiAyOCwgMjAxNCBhdCA2OjI1IEFNLCBNYXJ0aW4gV2luYmrDtnJrIDxtYXJ0aW4ud2lu
YmpvcmtAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gSGkNCj4NCj4NCj4NCj4gSSBoYXZlIGEgcXVl
c3Rpb24gcmVnYXJkaW5nIHRoZSBkcmFmdCBmb3IgVGFpbCBMb3NzIFByb2JlIGZvdW5kIG9uIHRo
ZSANCj4gZm9sbG93aW5nIGxpbmsNCj4NCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh
ZnQtZHVra2lwYXRpLXRjcG0tdGNwLWxvc3MtcHJvYmUtMDENCj4NCj4NCj4NCj4gV2hhdCBpcyB0
aGUgc3RhdHVzIG9mIHRoZSBkcmFmdD8gSXQgaGFzIGV4cGlyZWQgb24gQXVndXN0IDI5IDIwMTMu
IElzIA0KPiBpdCBzdGlsbCByZWxldmFudCBhbmQgdXBkYXRlZCBvciBoYXMgaXQgYmVlbiBhYmFu
ZG9uZWQgb3IgY29udGludWVkIGVsc2V3aGVyZT8NCkhpIE1hcnRpbiwNCg0KVGhlIGZlZWRiYWNr
IG9uIHRjcG0gYWZ0ZXIgc2V2ZXJhbCBtZWV0aW5ncyB3YXMgYWx0aG91Z2ggaXQgaXMgc29sdmlu
ZyBhbiBpbXBvcnRhbnQgcHJvYmxlbSwgMSkgaXQgaXMgZmFpcmx5IGNvbXBsaWNhdGVkIGFuZCAy
KSBpdCByZWxpZXMgb24gRkFDSyB3aGljaCBpcyBub3Qgc3RhbmRhcmRpemVkLg0KDQpUaGVyZWZv
cmUgSSBhbmQgdGhlIG90aGVyIGNvLWF1dGhvcnMgYXJlIHdvcmtpbmcgb24gYSBzaW1wbGVyIHNv
bHV0aW9uIHdpdGggbXVjaCB3aWRlciBzY29wZTogYSBuZXcgZnJhbWV3b3JrIHRvIGVuY29tcGFz
cyBhIGRvemVuIG9mIGhldXJpc3RpY3MgZGV2ZWxvcGVkIGluIHRoZSBsYXN0IHR3byBkZWNhZGVz
OiBSRkMzNTE3LCBGQUNLLCBUTFAsIEYtUlRPLCB0cmFkaXRpb25hbCBSVE8sIGxvc3QgcmV0cmFu
c21pdCwgZHluYW1pYyBkdXB0aHJlc2ggZm9yIHJlb3JkZXJpbmcsIGVhcmx5IHJldHJhbnNtaXQg
ZXRjLiBUaGUgdW5kZXJseWluZyBpZGVhIGlzIHRvIHJlcGxhY2UgcGFja2V0IGNvdW50ZXIgbm90
aW9uIChlLmcuIDMgZHVwYWNrcykgd2l0aCB0aW1lLiBBbGxvdyBmYXN0IHRpbWVvdXQgJiByZWNv
dmVyeSBpZiBuZXR3b3JrIGlzIHN0aWxsIHJlc3BvbnNpdmUsIGFuZCBvbmx5IHJlc2V0IGN3bmQg
dG8gMSB1bmRlciBleHRlbmRlZCBzaWxlbmNlLiBJIHdhcyBvcmlnaW5hbGx5IGdvaW5nIHRvIHRh
bGsgYWJvdXQgdGhpcyBpZGVhIGluIHRoaXMgdGNwbSBidXQgaGF2ZSB0byBjYW5jZWwgdGhlIHRy
aXAgIGluIHRoZSBsYXN0IG1pbnV0ZS4NCg0KQW55d2F5cywgd2UgYXJlIGhvcGVmdWwgdG8gY29t
ZSB1cCBhIG5ld2VyIGRyYWZ0IHRoYXQgc3Vic3VtZXMgVExQIChhbmQgbWFueSBvdGhlciBoZXVy
aXN0aWNzKSBhbmQgYW4gaW1wbGVtZW50YXRpb24gYWxsIHRvZ2V0aGVyIGxhdHRlciB0aGlzIHll
YXIuDQoNCg0KPg0KPg0KPg0KPiBSZWdhcmRzDQo+DQo+IE1hcnRpbiBXaW5iasO2cmsNCg==


From nobody Sun Mar  2 23:36:37 2014
Return-Path: <martin.winbjork@ericsson.com>
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 97F751A0D5D for <tcpm@ietfa.amsl.com>; Sun,  2 Mar 2014 23:36:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.939
X-Spam-Level: 
X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 95J4D37PqCNQ for <tcpm@ietfa.amsl.com>; Sun,  2 Mar 2014 23:36:33 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5F11A0D50 for <tcpm@ietf.org>; Sun,  2 Mar 2014 23:36:32 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-90-531430fc68c0
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id ED.EC.04853.CF034135; Mon,  3 Mar 2014 08:36:28 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.128]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Mon, 3 Mar 2014 08:36:28 +0100
From: =?iso-8859-1?Q?Martin_Winbj=F6rk?= <martin.winbjork@ericsson.com>
To: "Scheffenegger, Richard" <rs@netapp.com>, "tcpm@ietf.org" <tcpm@ietf.org>,  "nanditad@google.com" <nanditad@google.com>, "ncardwell@google.com" <ncardwell@google.com>, "ycheng@google.com" <ycheng@google.com>, "mattmathis@google.com" <mattmathis@google.com>
Thread-Topic: TCP Tail Loss Probe
Thread-Index: Ac80kCQu6lpocKtXSlyq1O7Kw8QrmAAHXD5gAIFq/4A=
Date: Mon, 3 Mar 2014 07:36:26 +0000
Message-ID: <7FD625EF1E1B1D4586EEAB7471ECDC0A200519@ESESSMB109.ericsson.se>
References: <7FD625EF1E1B1D4586EEAB7471ECDC0A200469@ESESSMB109.ericsson.se> <012C3117EDDB3C4781FD802A8C27DD4F260A5E48@SACEXCMBX02-PRD.hq.netapp.com>
In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F260A5E48@SACEXCMBX02-PRD.hq.netapp.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.16]
Content-Type: multipart/alternative; boundary="_000_7FD625EF1E1B1D4586EEAB7471ECDC0A200519ESESSMB109ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM+Jvje4fA5Fgg+YJlhbnz11itdj3YSuT RcedvSwWK/+dYbfYdnI+k8WXx1fZHNg8Fmwq9Viy5CeTx4xPX9gCmKO4bFJSczLLUov07RK4 Mm7f3c5SsCm84un/uUwNjNt8uxg5OSQETCSOLbvOBGGLSVy4t56ti5GLQ0jgBKPEu5v/WCCc xYwSWw/OZwSpYhNwl9iyoo8RJCEi0Mkk0dDxmx0kwSxgJfHl+F9mEFtYQEHi851rYA0iAooS T/ZtZIKwrSS2nYCwWQRUJG627gPr5RXwllj09yMrxLZpjBIPD3xjA0lwCoRKbNi+E8xmBLrv +6k1TBDLxCVuPZkPdbeAxJI955khbFGJl4//sULYihI7z7YzQ9TnS9yechRqmaDEyZlPWCYw is5CMmoWkrJZSMog4noSN6ZOYYOwtSWWLXzNDGHrSsz4d4gFWXwBI/sqRsni1OLi3HQjA73c 9NwSvdSizOTi4vw8veLUTYzAaD245bfRDsaTe+wPMUpzsCiJ815nrQkSEkhPLEnNTk0tSC2K LyrNSS0+xMjEwSnVwMh24JRN1SHloHr5uryVrv+euExSlLBuFlXhTO3y/7TgkIHTg4J/Z95o GP1zMK4s6l5pE6N37dq5/qzj7gyV3d7nfVfFnRQ5z6aleDxX197Jqvrgo9PTFuVIvjmm/Z/r Ce//sy+qfulU2r/W2ScyM1ufMV7xbOt8fQe5hRetuWe8rtk7iX1jjRJLcUaioRZzUXEiAOk+ Wx2kAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/_tpgFjuBoS8EW1ilhSGyH9SPxts
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Subject: Re: [tcpm] TCP Tail Loss Probe
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Mar 2014 07:36:35 -0000

--_000_7FD625EF1E1B1D4586EEAB7471ECDC0A200519ESESSMB109ericsso_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi



Thank you for the answer



Regards

Martin Winbj=F6rk


From: Scheffenegger, Richard [mailto:rs@netapp.com]
Sent: den 28 februari 2014 19:05
To: Martin Winbj=F6rk; tcpm@ietf.org; nanditad@google.com; ncardwell@google=
.com; ycheng@google.com; mattmathis@google.com
Cc: Ingemar Johansson S
Subject: RE: TCP Tail Loss Probe

Hi Martin,

I hope that work hasn't been abandoned.

For one, I would like this work being formally adopted as a TCPM item and d=
iscussed, as this mechanism would address some of the problems that I wante=
d addressed, which can be summarized as TCP HOL blocking latency.

Now that 1323bis is asymptotically nearing publication, I also want to revi=
ve some work that got me started with Timestamps. That work was also relate=
d to loss-related latency in TCP, but dealing with lost retransmissions (an=
d the non-ambiguous detection that a retransmission was lost).

If time permits, I want to give a short overview of that work, even though =
the current (expired) drafts don't include things learned during the discus=
sions of 1323bis:

http://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiation-0=
5
http://tools.ietf.org/html/draft-trammell-tcpm-timestamp-interval-01

And ideally also the way Linux currently recovers from lost retransmissions=
 (even though the scheme making use of a modified TS sematic does not incur=
 unnecessary latency, or fails at the end-of-stream).

Best regards,

Richard Scheffenegger

From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Martin Winbj=F6rk
Sent: Freitag, 28. Februar 2014 15:26
To: tcpm@ietf.org<mailto:tcpm@ietf.org>; nanditad@google.com<mailto:nandita=
d@google.com>; ncardwell@google.com<mailto:ncardwell@google.com>; ycheng@go=
ogle.com<mailto:ycheng@google.com>; mattmathis@google.com<mailto:mattmathis=
@google.com>
Cc: Ingemar Johansson S
Subject: [tcpm] TCP Tail Loss Probe

Hi

I have a question regarding the draft for Tail Loss Probe found on the foll=
owing link
http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01

What is the status of the draft? It has expired on August 29 2013. Is it st=
ill relevant and updated or has it been abandoned or continued elsewhere?

Regards
Martin Winbj=F6rk

--_000_7FD625EF1E1B1D4586EEAB7471ECDC0A200519ESESSMB109ericsso_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText">Hi<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Thank you for the answer<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Regards<o:p></o:p></p>
<p class=3D"MsoPlainText">Martin Winbj=F6rk<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Scheffen=
egger, Richard [mailto:rs@netapp.com]
<br>
<b>Sent:</b> den 28 februari 2014 19:05<br>
<b>To:</b> Martin Winbj=F6rk; tcpm@ietf.org; nanditad@google.com; ncardwell=
@google.com; ycheng@google.com; mattmathis@google.com<br>
<b>Cc:</b> Ingemar Johansson S<br>
<b>Subject:</b> RE: TCP Tail Loss Probe<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Hi Martin,<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">I hope that work hasn&=
#8217;t been abandoned.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">For one, I would like =
this work being formally adopted as a TCPM item and discussed, as this mech=
anism would address some of the problems that I wanted addressed, which can=
 be summarized as TCP HOL blocking latency.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Now that 1323bis is as=
ymptotically nearing publication, I also want to revive some work that got =
me started with Timestamps. That work was also related to loss-related late=
ncy in TCP, but dealing with lost retransmissions
 (and the non-ambiguous detection that a retransmission was lost). <o:p></o=
:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">If time permits, I wan=
t to give a short overview of that work, even though the current (expired) =
drafts don&#8217;t include things learned during the discussions of 1323bis=
:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><a href=3D"http://tool=
s.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiation-05">http://t=
ools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiation-05</a><o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><a href=3D"http://tool=
s.ietf.org/html/draft-trammell-tcpm-timestamp-interval-01">http://tools.iet=
f.org/html/draft-trammell-tcpm-timestamp-interval-01</a><o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">And ideally also the w=
ay Linux currently recovers from lost retransmissions (even though the sche=
me making use of a modified TS sematic does not incur unnecessary latency, =
or fails at the end-of-stream).<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D">Best regards,<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span style=3D"color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span lang=3D"DE-AT" =
style=3D"color:#1F497D">Richard Scheffenegger</span><span lang=3D"DE-AT" st=
yle=3D"font-size:10.0pt;color:#1F497D"><o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal"><span lang=3D"DE-AT" style=3D"color:#1F497D"><o:p>&n=
bsp;</o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> tcpm [<a=
 href=3D"mailto:tcpm-bounces@ietf.org">mailto:tcpm-bounces@ietf.org</a>]
<b>On Behalf Of </b>Martin Winbj=F6rk<br>
<b>Sent:</b> Freitag, 28. Februar 2014 15:26<br>
<b>To:</b> <a href=3D"mailto:tcpm@ietf.org">tcpm@ietf.org</a>; <a href=3D"m=
ailto:nanditad@google.com">
nanditad@google.com</a>; <a href=3D"mailto:ncardwell@google.com">ncardwell@=
google.com</a>;
<a href=3D"mailto:ycheng@google.com">ycheng@google.com</a>; <a href=3D"mail=
to:mattmathis@google.com">
mattmathis@google.com</a><br>
<b>Cc:</b> Ingemar Johansson S<br>
<b>Subject:</b> [tcpm] TCP Tail Loss Probe<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"DE-AT"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal">Hi<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I have a question regarding the draft for Tail Loss =
Probe found on the following link
<o:p></o:p></p>
<p class=3D"MsoNormal"><a href=3D"http://tools.ietf.org/html/draft-dukkipat=
i-tcpm-tcp-loss-probe-01">http://tools.ietf.org/html/draft-dukkipati-tcpm-t=
cp-loss-probe-01</a><o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">What is the status of the draft? It has expired on A=
ugust 29 2013. Is it still relevant and updated or has it been abandoned or=
 continued elsewhere?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Regards<o:p></o:p></p>
<p class=3D"MsoNormal">Martin Winbj=F6rk<o:p></o:p></p>
</div>
</div>
</body>
</html>

--_000_7FD625EF1E1B1D4586EEAB7471ECDC0A200519ESESSMB109ericsso_--


From nobody Mon Mar  3 15:35:00 2014
Return-Path: <internet-drafts@ietf.org>
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 263071A016C; Mon,  3 Mar 2014 15:34:54 -0800 (PST)
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 PFIzJQtbLJ5Q; Mon,  3 Mar 2014 15:34:52 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAEB1A0111; Mon,  3 Mar 2014 15:34:52 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140303233452.9327.70486.idtracker@ietfa.amsl.com>
Date: Mon, 03 Mar 2014 15:34:52 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/wnAYnib6H0PLErt1CzLQ8ObLp64
Cc: tcpm@ietf.org
Subject: [tcpm] I-D Action: draft-ietf-tcpm-1323bis-20.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Mar 2014 23:34: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 Extensions for High Performance
        Authors         : David Borman
                          Bob Braden
                          Van Jacobson
                          Richard Scheffenegger
	Filename        : draft-ietf-tcpm-1323bis-20.txt
	Pages           : 49
	Date            : 2014-03-03

Abstract:
   This document specifies a set of TCP extensions to improve
   performance over paths with a large bandwidth * delay product and to
   provide reliable operation over very high-speed paths.  It defines
   the TCP Window Scale (WS) option and the TCP Timestamps (TS) option
   and their semantics.  The Window Scale option is used to support
   larger receive windows, while the Timestamps option can be used for
   at least two distinct mechanisms, PAWS (Protection Against Wrapped
   Sequences) and RTTM (Round Trip Time Measurement), that are also
   described herein.

   This document obsoletes RFC1323 and describes changes from it.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-1323bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tcpm-1323bis-20

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-1323bis-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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Mar  3 15:39:54 2014
Return-Path: <rs@netapp.com>
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 8B5021A01BC for <tcpm@ietfa.amsl.com>; Mon,  3 Mar 2014 15:39:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-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 hMP95WbebksC for <tcpm@ietfa.amsl.com>; Mon,  3 Mar 2014 15:39:49 -0800 (PST)
Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC951A0147 for <tcpm@ietf.org>; Mon,  3 Mar 2014 15:39:49 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.97,581,1389772800"; d="scan'208";a="106310871"
Received: from vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) by mx11-out.netapp.com with ESMTP; 03 Mar 2014 15:39:46 -0800
Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 15:39:46 -0800
From: "Scheffenegger, Richard" <rs@netapp.com>
To: "tcpm (tcpm@ietf.org)" <tcpm@ietf.org>
Thread-Topic: New Version Notification for draft-ietf-tcpm-1323bis-20.txt
Thread-Index: AQHPNzkvjtUmL8sirkKYqq/p/6wrOZrQBAnQ
Date: Mon, 3 Mar 2014 23:39:45 +0000
Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F260B3BAD@SACEXCMBX02-PRD.hq.netapp.com>
References: <20140303233452.9327.98908.idtracker@ietfa.amsl.com>
In-Reply-To: <20140303233452.9327.98908.idtracker@ietfa.amsl.com>
Accept-Language: de-AT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.122.105.20]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/UOEW8QBbLxrwGNc-6FMSveWn0b4
Subject: [tcpm] FW: New Version Notification for draft-ietf-tcpm-1323bis-20.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Mar 2014 23:39:51 -0000

SGksDQoNCmR1cmluZyB0aGUgU2VjRGlyIHJldmlldywgYSBtaW5vciBvbWlzc2lvbiB3YXMgZm91
bmQgaW4gdGhlIHNlY3VyaXR5IHNlY3Rpb24uIEFzIHRoZSBhY3R1YWwgY29uY2VybiBoYXMgYmVl
biBkZXNjcmliZWQgc3VmZmljaWVudGx5IGluIG90aGVyIHNlY3Rpb25zIG9mIHRoZSBkcmFmdCwg
dGhlIGNoYW5nZSBpcyByZWZlcmVuY2luZyB0aGUgcmVsZXZhbnQgc2VjdGlvbiwgYW5kIGFkZHJl
c3NpbmcgdGhlIGluYWNjdXJhY2llcyBpbiB0aGUgd29yZGluZy4NCg0KVGhlIG5ldyBzZWN1cml0
eSBzZWN0aW9uIG5vdyByZWFkcyBhcyBmb2xsb3dzIChpbml0aWFsIHBhcmFncmFwaHMgb25seSwg
Y2hhbmdlZCBsaW5lcyBtYXJrZWQgd2l0aCAiKyIpOg0KDQoNCj4gNy4gIFNlY3VyaXR5IENvbnNp
ZGVyYXRpb25zDQo+IA0KPiAgIFRoZSBUQ1Agc2VxdWVuY2Ugc3BhY2UgaXMgYSBmaXhlZCBzaXpl
LCBhbmQgYXMgdGhlIHdpbmRvdyBiZWNvbWVzDQo+ICAgbGFyZ2VyIGl0IGJlY29tZXMgZWFzaWVy
IGZvciBhbiBhdHRhY2tlciB0byBnZW5lcmF0ZSBmb3JnZWQgcGFja2V0cw0KPiAgIHRoYXQgY2Fu
IGZhbGwgd2l0aGluIHRoZSBUQ1Agd2luZG93LCBhbmQgYmUgYWNjZXB0ZWQgYXMgdmFsaWQNCj4g
ICBzZWdtZW50cy4gIFdoaWxlIHVzZSBvZiB0aW1lc3RhbXBzIGFuZCBQQVdTIGNhbiBoZWxwIHRv
IG1pdGlnYXRlDQo+ICAgdGhpcywgd2hlbiB1c2luZyBQQVdTLCBpZiBhbiBhdHRhY2tlciBpcyBh
YmxlIHRvIGZvcmdlIGEgcGFja2V0IHRoYXQNCj4gICBpcyBhY2NlcHRhYmxlIHRvIHRoZSBUQ1Ag
Y29ubmVjdGlvbiwgYSB0aW1lc3RhbXAgdGhhdCBpcyBpbiB0aGUNCj4gICBmdXR1cmUgd291bGQg
Y2F1c2UgdmFsaWQgc2VnbWVudHMgdG8gYmUgZHJvcHBlZCBkdWUgdG8gUEFXUyBjaGVja3MuDQo+
ICAgSGVuY2UsIGltcGxlbWVudGVycyBzaG91bGQgdGFrZSBjYXJlIHRvIG5vdCBvcGVuIHRoZSBU
Q1Agd2luZG93DQo+ICAgZHJhc3RpY2FsbHkgYmV5b25kIHRoZSByZXF1aXJlbWVudHMgb2YgdGhl
IGNvbm5lY3Rpb24uDQo+IA0KPiArICBTZWUgW1JGQzU5NjFdIGZvciBtaXRpZ2F0aW9uIHN0cmF0
ZWdpZXMgdG8gYmxpbmQgaW4td2luZG93IGF0dGFja3MuDQo+IA0KPiAgIEEgbmFpdmUgaW1wbGVt
ZW50YXRpb24gdGhhdCBkZXJpdmVzIHRoZSB0aW1lc3RhbXAgY2xvY2sgdmFsdWUNCj4gICBkaXJl
Y3RseSBmcm9tIGEgc3lzdGVtIHVwdGltZSBjbG9jayBtYXkgdW5pbnRlbnRpb25hbGx5IGxlYWsg
dGhpcw0KPiAgIGluZm9ybWF0aW9uIHRvIGFuIGF0dGFja2VyLiAgVGhpcyBkb2VzIG5vdCBkaXJl
Y3RseSBjb21wcm9taXNlIGFueSBvZg0KPiAgIHRoZSBtZWNoYW5pc21zIGRlc2NyaWJlZCBpbiB0
aGlzIGRvY3VtZW50LiAgSG93ZXZlciwgdGhpcyBtYXkgYmUNCj4gKyAgdmFsdWFibGUgaW5mb3Jt
YXRpb24gdG8gYSBwb3RlbnRpYWwgYXR0YWNrZXIuICBJdCBpcyB0aGVyZWZvcmUgIA0KPiArIFJF
Q09NTUVOREVEIHRvIGdlbmVyYXRlIGEgcmFuZG9tLCBwZXItY29ubmVjdGlvbiBvZmZzZXQgdG8g
YmUgdXNlZCAgDQo+ICsgd2l0aCB0aGUgY2xvY2sgc291cmNlIHdoZW4gZ2VuZXJhdGluZyB0aGUg
VGltZXN0YW1wcyBvcHRpb24gdmFsdWUgIA0KPiArIChzZWUgU2VjdGlvbiA1LjQpLg0KPiANCj4g
Wy4uLl0NCg0KUmljaGFyZCBTY2hlZmZlbmVnZ2VyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm
dHNAaWV0Zi5vcmddIA0KU2VudDogTW9udGFnLCAwMy4gTcOkcnogMjAxNCAyMzozNQ0KVG86IERh
dmlkIEJvcm1hbjsgU2NoZWZmZW5lZ2dlciwgUmljaGFyZDsgU2NoZWZmZW5lZ2dlciwgUmljaGFy
ZDsgRGF2aWQgQm9ybWFuOyBWYW4gSmFjb2Jzb247IFZhbiBKYWNvYnNvbjsgQm9iIEJyYWRlbjsg
Um9iZXJ0IFQuIEJyYWRlbg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk
cmFmdC1pZXRmLXRjcG0tMTMyM2Jpcy0yMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwg
ZHJhZnQtaWV0Zi10Y3BtLTEzMjNiaXMtMjAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt
aXR0ZWQgYnkgUmljaGFyZCBTY2hlZmZlbmVnZ2VyIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVw
b3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWlldGYtdGNwbS0xMzIzYmlzDQpSZXZpc2lvbjoJMjAN
ClRpdGxlOgkJVENQIEV4dGVuc2lvbnMgZm9yIEhpZ2ggUGVyZm9ybWFuY2UNCkRvY3VtZW50IGRh
dGU6CTIwMTQtMDMtMDQNCkdyb3VwOgkJdGNwbQ0KUGFnZXM6CQk0OQ0KVVJMOiAgICAgICAgICAg
IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtdGNwbS0xMzIz
YmlzLTIwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv
ZG9jL2RyYWZ0LWlldGYtdGNwbS0xMzIzYmlzLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS0xMzIzYmlzLTIwDQpEaWZmOiAgICAgICAg
ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10Y3BtLTEzMjNi
aXMtMjANCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIHNldCBvZiBU
Q1AgZXh0ZW5zaW9ucyB0byBpbXByb3ZlDQogICBwZXJmb3JtYW5jZSBvdmVyIHBhdGhzIHdpdGgg
YSBsYXJnZSBiYW5kd2lkdGggKiBkZWxheSBwcm9kdWN0IGFuZCB0bw0KICAgcHJvdmlkZSByZWxp
YWJsZSBvcGVyYXRpb24gb3ZlciB2ZXJ5IGhpZ2gtc3BlZWQgcGF0aHMuICBJdCBkZWZpbmVzDQog
ICB0aGUgVENQIFdpbmRvdyBTY2FsZSAoV1MpIG9wdGlvbiBhbmQgdGhlIFRDUCBUaW1lc3RhbXBz
IChUUykgb3B0aW9uDQogICBhbmQgdGhlaXIgc2VtYW50aWNzLiAgVGhlIFdpbmRvdyBTY2FsZSBv
cHRpb24gaXMgdXNlZCB0byBzdXBwb3J0DQogICBsYXJnZXIgcmVjZWl2ZSB3aW5kb3dzLCB3aGls
ZSB0aGUgVGltZXN0YW1wcyBvcHRpb24gY2FuIGJlIHVzZWQgZm9yDQogICBhdCBsZWFzdCB0d28g
ZGlzdGluY3QgbWVjaGFuaXNtcywgUEFXUyAoUHJvdGVjdGlvbiBBZ2FpbnN0IFdyYXBwZWQNCiAg
IFNlcXVlbmNlcykgYW5kIFJUVE0gKFJvdW5kIFRyaXAgVGltZSBNZWFzdXJlbWVudCksIHRoYXQg
YXJlIGFsc28NCiAgIGRlc2NyaWJlZCBoZXJlaW4uDQoNCiAgIFRoaXMgZG9jdW1lbnQgb2Jzb2xl
dGVzIFJGQzEzMjMgYW5kIGRlc2NyaWJlcyBjaGFuZ2VzIGZyb20gaXQuDQoNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl
IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXpl
ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRo
ZSBJRVRGIFNlY3JldGFyaWF0DQoNCg==


From nobody Tue Mar  4 03:29:50 2014
Return-Path: <michael.scharf@alcatel-lucent.com>
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 EB3C61A0745 for <tcpm@ietfa.amsl.com>; Tue,  4 Mar 2014 03:29:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RotRYC3EuqPe for <tcpm@ietfa.amsl.com>; Tue,  4 Mar 2014 03:29:43 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 12C331A06B9 for <tcpm@ietf.org>; Tue,  4 Mar 2014 03:29:43 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s24BTbnl021305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Mar 2014 05:29:38 -0600 (CST)
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 s24BTbmt014648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 12:29:37 +0100
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 4 Mar 2014 12:29:37 +0100
From: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
To: Yuchung Cheng <ycheng@google.com>
Thread-Topic: draft-ietf-tcpm-fastopen-07
Thread-Index: Ac83nQQFuo3BNsg8QoGH/DfDmISoDQ==
Date: Tue, 4 Mar 2014 11:29:35 +0000
Message-ID: <655C07320163294895BBADA28372AF5D20D6F5@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: http://mailarchive.ietf.org/arch/msg/tcpm/1YgxtPc3RLlwVCba5GJLkMWJ7Lw
Cc: tcpm IETF list <tcpm@ietf.org>, "draft-ietf-tcpm-fastopen@tools.ietf.org" <draft-ietf-tcpm-fastopen@tools.ietf.org>
Subject: [tcpm] draft-ietf-tcpm-fastopen-07
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Mar 2014 11:29:47 -0000

Hi Yuchung,

In preparation of the write-up, I read draft-ietf-tcpm-fastopen-07 once aga=
in and I run into some (mostly editorial) issues. I probably should have ra=
ised such issues ealier - sorry for the late feedback. Also, sorry if I got=
 something wrong - I am obviously busy during the IETF week ;)

Still, I'd appreciate if this would be fixed before moving forward the docu=
ment - otherwise this could be raised in the IETF LC or by the IESG.


Suggestions regarding the technical content:

- Section 4.1.3:

  draft-07:

   Without this information,
   the data size in the SYN packet is limited to the default MSS of 536
   bytes [RFC1122].

  Wouldn't it make sense to allow for a larger MSS for IPv6, which has a mi=
nimum MTU of 1280 byte? For instance:

   Without this information,
   the data size in the SYN packet is limited to the default MSS of 536
   bytes for IPv4 [RFC1122] and 1240 bytes for IPv6 [RFC2460].

  Otherwise, it could make sense to explain why the smaller value makes sen=
se for IPv6 as well.

- Section 4.1.3 and Section 4.2:

  Basically, a lot of the client handling procedures are heuristics. This i=
s mentioned later in Section 4.2.2, but I think it could be worthwhile to s=
tate in the earlier sections that some of the guidance consists of heuristi=
cs - albeit reasonable ones.


- Section 4.1.3.1:

  draft-07:

   For any negative responses, the client SHOULD disable Fast Open on
   the specific path and port, at least temporarily.

  The term "path" seems a bit problematic to me. TCP only knows endpoints. =
Do you mean the following?

   For any negative responses, the client SHOULD disable Fast Open on
   the specific combination of source and destination IP address and the re=
mote port, at least temporarily.

  Potentially, some additional heuristic can try to guess paths (e.g., by l=
ooking at the local routing table in the endpoint). If that is meant, I'd s=
uggest to call such a "path detection heuristic" more explicitly.   =20


- Section 4.2:

  Would it make sense to state more explicitly that other TCP events or sta=
te transition (e.g., reception of a RST) are not affected by fast open?


- Section 7.2:

  If cookie-less operation allows a cookie length of 0 bytes, couldn't ther=
e be issues with distinguishing the Fast Open Cookie Option and the Fast Op=
en Cookie Request option? According to Section 4.1.1, they are distinguishe=
d by their length. I haven't fully thought through all details, e.g., for s=
imultaneous open. If it is not an issue, a short sentence that explains why=
 the options are still unique in the cookie-less operation could still be u=
seful, imho.



Phrasing suggestions (I am not a native speaker):

- Abstract:

  draft-07:

   However TFO deviates from the
   standard TCP semantics the data in the SYN could be replayed to an
   application in some rare circumstances.

  Maybe better:

   However TFO deviates from the
   standard TCP semantics since the data in the SYN could be replayed to an
   application in some rare circumstances.


- Section 4.1.1:

  This section could more explicitly state that the cookie size MUST be an =
even number. This follows implicitly from the fact that the Fast Open Cooki=
e Option length MUST be even.


- Section 4.1.2:

  The implementation example mentions AES_128. In a similar case in past do=
cuments, we got LC comments whether the crypto algorithm was save enough. M=
aybe a statement that crypto algorithms other than AES_128 could obviously =
be used as well, without any impact on the protocol, could make sense.


- Section 4.1.3:

  draft-07:
=20
   In particular it's known IPv4 receiver advertised
   MSS less than 536 bytes would result in transmission of an unexpected
   large segment.=20

  I can't fully parse this. Is this meant?

   In particular it's known that an IPv4 receiver advertised
   MSS less than 536 bytes would result in transmission of an unexpected
   large segment.=20

  Similar like for the previous sentence (see above), IPv6 could be conside=
red here separately, IMHO.


- Section 5.1:

  draft-07:

   With DHCP, it's possible to obtain
   cookies of past IP addresses without compromising any host.

  I have difficulties to understand that attack based on this sentence. Cou=
ld it make sense to rephrase it?


- Section 6:

  draft-07:

   Applications here refer
   specifically to the process that writes data into the socket, i.e., a
   java script process that sends data to the server.

  Suggestion:

   Applications here refer
   specifically to the process that writes data into the socket, e.g., a
   JavaScript process that sends data to the server.

  I think "java script" (=3D JavaScript?) is only one example for an applic=
ation.


Editorial nits:

- In many other documents, the terminology section comes after the introduc=
tion, so having it before the Table of Contents seems a little bit unusual =
to me. I don't have a strong preference on this, though.

- The document contains a couple of acronyms that are well-known in the IET=
F ("TCP", "NAT", "DoS", "ICMP", "CPU"). In general, I think acronyms like "=
TCB" (TCP Control Block) should really be expanded on first use. For some a=
cronyms like "TCP" there may be some gray area whether they may be well-kno=
wn to a reader ;)

- Section 2: s/to be delivered to application/to be delivered to the applic=
ation/ ?

- Section 3: s/max amount/maximum amount/ ?

- Section 4.2: s/i.e.,not/i.e., not/

- Section 6.1: s/host(Section/host (Section/

- Section 6.3.3: s/1-RTT/one RTT/

- Section 8.2: s/data ./data./

- Section 8.3: "the latency benefit as TFO": Is this correct English?

- Section 11: Please check the references again. At least reference [BRISCO=
E12] seems broken.


As far as I recall, I haven't formally concluded the WGLC. This message thu=
s completes the WGLC.

Thanks

Michael


From nobody Tue Mar  4 09:29:34 2014
Return-Path: <mallman@icir.org>
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 87AC71A00F6 for <tcpm@ietfa.amsl.com>; Tue,  4 Mar 2014 09:29:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mEviU3TW4awu for <tcpm@ietfa.amsl.com>; Tue,  4 Mar 2014 09:29:32 -0800 (PST)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3F81A01F1 for <tcpm@ietf.org>; Tue,  4 Mar 2014 09:29:32 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id A07CC2C402B; Tue,  4 Mar 2014 09:29:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nZ9V+3WrzKhW; Tue,  4 Mar 2014 09:29:29 -0800 (PST)
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 29C852C400A; Tue,  4 Mar 2014 09:29:29 -0800 (PST)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id A804221BD069; Tue,  4 Mar 2014 12:29:28 -0500 (EST)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 9BC843815563; Tue,  4 Mar 2014 12:29:28 -0500 (EST)
To: gorry@erg.abdn.ac.uk
From: Mark Allman <mallman@icir.org>
In-Reply-To: <12cbda88bf79e1f39e9bd3013e0bf3cf.squirrel@www.erg.abdn.ac.uk> 
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Pretending
X-URL-0: http://www.icir.org/mallman-files/Document88211.doc
X-URL-1: http://www.icir.org/mallman-files/Document43997.html
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma3448-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Tue, 04 Mar 2014 12:29:28 -0500
Sender: mallman@icir.org
Message-Id: <20140304172928.9BC843815563@lawyers.icir.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Ue1qMLvsgP8iXoydr49z69Vw3W0
Cc: raffaello@erg.abdn.ac.uk, tcpm@ietf.org
Subject: Re: [tcpm] thoughts on newcwv-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mallman@icir.org
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Mar 2014 17:29:33 -0000

----------ma3448-1
Content-Type: text/plain
Content-Disposition: inline


> I was thinking that we actually had to add some text, on this specific
> point I was thinking along the lines of the text below - does this help
> explain why the old terminology is different?:

This text is a start.  Perhaps you need an example to show something
obviously bogus with CWV.

allman




----------ma3448-1
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (Darwin)

iEYEARECAAYFAlMWDXgACgkQWyrrWs4yIs6E3ACfS1EF3dGVzjdL7IHV/lLBs9Jl
YrwAn31ukVUlhWlodBqWZgKYXoRJpi0s
=tTjt
-----END PGP SIGNATURE-----
----------ma3448-1--


From nobody Tue Mar  4 23:40:54 2014
Return-Path: <ingemar.s.johansson@ericsson.com>
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 7DF341A0338 for <tcpm@ietfa.amsl.com>; Tue,  4 Mar 2014 23:40:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.551
X-Spam-Level: 
X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPqRWD-FUQX2 for <tcpm@ietfa.amsl.com>; Tue,  4 Mar 2014 23:40:50 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A13531A0348 for <tcpm@ietf.org>; Tue,  4 Mar 2014 23:40:49 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-e8-5316d4fc8e4d
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E2.67.10875.CF4D6135; Wed,  5 Mar 2014 08:40:45 +0100 (CET)
Received: from ESESSMB205.ericsson.se ([169.254.5.210]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Wed, 5 Mar 2014 08:40:44 +0100
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Yuchung Cheng <ycheng@google.com>, =?utf-8?B?TWFydGluIFdpbmJqw7Zyaw==?= <martin.winbjork@ericsson.com>
Thread-Topic: TCP Tail Loss Probe
Thread-Index: Ac80kCQu6lpocKtXSlyq1O7Kw8QrmAAG0N0AAOZVJyA=
Date: Wed, 5 Mar 2014 07:40:44 +0000
Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA31EF8B52@ESESSMB205.ericsson.se>
References: <7FD625EF1E1B1D4586EEAB7471ECDC0A200469@ESESSMB109.ericsson.se> <CAK6E8=d1+5OFvHUX2xPZaS1zuEnfZQSYbEuWc18K05S3MJ_W=A@mail.gmail.com>
In-Reply-To: <CAK6E8=d1+5OFvHUX2xPZaS1zuEnfZQSYbEuWc18K05S3MJ_W=A@mail.gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+Jvje7fK2LBBg+281icP3eJ1WLfh61M Fh139rJYbDs5n8niy+OrbA6sHgs2lXosWfKTKYApissmJTUnsyy1SN8ugStjyu2b7AXfJCse nbjH2MC4QLKLkZNDQsBEYtnG+WwQtpjEhXvrgWwuDiGBQ4wSn9/9hnIWM0r8e/CfGaSKTcBG YuWh74wgtohAjsTeA1fZQYqYBbYwSmz8uYwVJCEsoCDx+c41qCJFiSf7NjJB2FYSK2fdBLNZ BFQkPvc8BavhFfCVWPxwNRPEtkmMErNn/AUr4hQIlGjt2AdWxCggK3H/+z0WEJtZQFzi1pP5 TBB3C0gs2XOeGcIWlXj5+B8rhK0o8fEVSC8HUL2mxPpd+hCtihJTuh+yQ+wVlDg58wnLBEax WUimzkLomIWkYxaSjgWMLKsY2XMTM3PSyw03MQIj6OCW37o7GE+dEznEKM3BoiTO++Gtc5CQ QHpiSWp2ampBalF8UWlOavEhRiYOTqkGxtQFdo2M90MbOH5wxcntKpybGVO6KF+t8jXb/xiB 7FZP/0UfQudWnDvhqXc0P+XwNDVuIeurR3d5Lzoi7SVaKNlq9pQvUv469227jxIup15U+Dic XCo4mYv3+5c1wrLXbVbHhL/wKNl+PkSJde+RNdutzuurPv/sd/yCQ8SX7Ff8SdEZk5fFKbEU ZyQaajEXFScCAGeTSQpuAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/S4VsoVLwC3amrpyi6peWFPEc3Wo
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, "mattmathis@google.com" <mattmathis@google.com>
Subject: Re: [tcpm] TCP Tail Loss Probe
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Mar 2014 07:40:52 -0000

VGhhbmtzIGFsbCBmb3IgdGhlIHByb21wdCByZXNwb25zZS4gDQoNClNob3J0IGZvbGxvd3VwIHF1
ZXN0aW9uLCBkb2VzIHRoZSBsYXRlc3QgZHJhZnQgcmVmbGVjdCB0aGUgTGludXggVENQIGltcGxl
bWVudGF0aW9uIG9yIGFyZSB0aGVyZSBsYXRlciBjaGFuZ2VzIGRvbmUgaW4gdGhlIExpbnV4IGNv
ZGUgPy4NCk1hcnRpbiBpcyBkb2luZyBhIG1hc3RlciB0aGVzaXMgKEkgYW0gb25lIG9mIHRoZSBz
dXBlcnZpc29ycykuIFRoZSBvYmplY3RpdmUgaXMgdG8gaW1wbGVtZW50IG5ldyBzdWdnZXN0ZWQg
YWRkaXRpb25zIHRvIFRDUCBpbiBvdXIgSmF2YSBiYXNlZCBMVEUgc3lzdGVtIHNpbXVsYXRvciAg
YW5kIHN0dWR5IHRoZSBpbXBhY3Qgb24gcGVyZm9ybWFuY2UgaW4gdmFyaW91cyBzaW11bGF0ZWQg
dHJhZmZpYyBjYXNlcy4gSGUgcmVjZW50bHkgc3R1ZGllZCBDV1YgYW5kIG5vdyB0aGUgdGltZSBo
YXMgY29tZSB0byBsb29rIGNsb3NlciBhdCBUTFAsIGFuZCBldmVuIHRob3VnaCB0aGUgZHJhZnQg
aXMgZXhwcmlyZWQsIGl0IGlzIHN0aWxsIG9mIGludGVyZXN0IGFzIGl0IGlzIGVuYWJsZWQgYnkg
ZGVmYXVsdCBpbiB0aGUgTGludXggVENQIHN0YWNrLg0KDQovSW5nZW1hcg0KDQo+IC0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFl1Y2h1bmcgQ2hlbmcgW21haWx0bzp5Y2hlbmdA
Z29vZ2xlLmNvbV0NCj4gU2VudDogZGVuIDI4IGZlYnJ1YXJpIDIwMTQgMTk6MzUNCj4gVG86IE1h
cnRpbiBXaW5iasO2cmsNCj4gQ2M6IHRjcG1AaWV0Zi5vcmc7IG5hbmRpdGFkQGdvb2dsZS5jb207
IG5jYXJkd2VsbEBnb29nbGUuY29tOw0KPiBtYXR0bWF0aGlzQGdvb2dsZS5jb207IEluZ2VtYXIg
Sm9oYW5zc29uIFMNCj4gU3ViamVjdDogUmU6IFRDUCBUYWlsIExvc3MgUHJvYmUNCj4gDQo+IE9u
IEZyaSwgRmViIDI4LCAyMDE0IGF0IDY6MjUgQU0sIE1hcnRpbiBXaW5iasO2cmsNCj4gPG1hcnRp
bi53aW5iam9ya0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPiA+IEhpDQo+ID4NCj4gPg0KPiA+DQo+
ID4gSSBoYXZlIGEgcXVlc3Rpb24gcmVnYXJkaW5nIHRoZSBkcmFmdCBmb3IgVGFpbCBMb3NzIFBy
b2JlIGZvdW5kIG9uIHRoZQ0KPiA+IGZvbGxvd2luZyBsaW5rDQo+ID4NCj4gPiBodHRwOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kdWtraXBhdGktdGNwbS10Y3AtbG9zcy1wcm9iZS0wMQ0K
PiA+DQo+ID4NCj4gPg0KPiA+IFdoYXQgaXMgdGhlIHN0YXR1cyBvZiB0aGUgZHJhZnQ/IEl0IGhh
cyBleHBpcmVkIG9uIEF1Z3VzdCAyOSAyMDEzLiBJcw0KPiA+IGl0IHN0aWxsIHJlbGV2YW50IGFu
ZCB1cGRhdGVkIG9yIGhhcyBpdCBiZWVuIGFiYW5kb25lZCBvciBjb250aW51ZWQNCj4gZWxzZXdo
ZXJlPw0KPiBIaSBNYXJ0aW4sDQo+IA0KPiBUaGUgZmVlZGJhY2sgb24gdGNwbSBhZnRlciBzZXZl
cmFsIG1lZXRpbmdzIHdhcyBhbHRob3VnaCBpdCBpcyBzb2x2aW5nIGFuDQo+IGltcG9ydGFudCBw
cm9ibGVtLCAxKSBpdCBpcyBmYWlybHkgY29tcGxpY2F0ZWQgYW5kIDIpIGl0IHJlbGllcyBvbiBG
QUNLIHdoaWNoIGlzDQo+IG5vdCBzdGFuZGFyZGl6ZWQuDQo+IA0KPiBUaGVyZWZvcmUgSSBhbmQg
dGhlIG90aGVyIGNvLWF1dGhvcnMgYXJlIHdvcmtpbmcgb24gYSBzaW1wbGVyIHNvbHV0aW9uIHdp
dGgNCj4gbXVjaCB3aWRlciBzY29wZTogYSBuZXcgZnJhbWV3b3JrIHRvIGVuY29tcGFzcyBhIGRv
emVuIG9mIGhldXJpc3RpY3MNCj4gZGV2ZWxvcGVkIGluIHRoZSBsYXN0IHR3byBkZWNhZGVzOiBS
RkMzNTE3LCBGQUNLLCBUTFAsIEYtUlRPLCB0cmFkaXRpb25hbA0KPiBSVE8sIGxvc3QgcmV0cmFu
c21pdCwgZHluYW1pYyBkdXB0aHJlc2ggZm9yIHJlb3JkZXJpbmcsIGVhcmx5IHJldHJhbnNtaXQg
ZXRjLg0KPiBUaGUgdW5kZXJseWluZyBpZGVhIGlzIHRvIHJlcGxhY2UgcGFja2V0IGNvdW50ZXIg
bm90aW9uIChlLmcuIDMgZHVwYWNrcykgd2l0aA0KPiB0aW1lLiBBbGxvdyBmYXN0IHRpbWVvdXQg
JiByZWNvdmVyeSBpZiBuZXR3b3JrIGlzIHN0aWxsIHJlc3BvbnNpdmUsIGFuZCBvbmx5DQo+IHJl
c2V0IGN3bmQgdG8gMSB1bmRlciBleHRlbmRlZCBzaWxlbmNlLiBJIHdhcyBvcmlnaW5hbGx5IGdv
aW5nIHRvIHRhbGsgYWJvdXQNCj4gdGhpcyBpZGVhIGluIHRoaXMgdGNwbSBidXQgaGF2ZSB0byBj
YW5jZWwgdGhlIHRyaXAgIGluIHRoZSBsYXN0IG1pbnV0ZS4NCj4gDQo+IEFueXdheXMsIHdlIGFy
ZSBob3BlZnVsIHRvIGNvbWUgdXAgYSBuZXdlciBkcmFmdCB0aGF0IHN1YnN1bWVzIFRMUCAoYW5k
DQo+IG1hbnkgb3RoZXIgaGV1cmlzdGljcykgYW5kIGFuIGltcGxlbWVudGF0aW9uIGFsbCB0b2dl
dGhlciBsYXR0ZXIgdGhpcyB5ZWFyLg0KPiANCj4gDQo+ID4NCj4gPg0KPiA+DQo+ID4gUmVnYXJk
cw0KPiA+DQo+ID4gTWFydGluIFdpbmJqw7Zyaw0K


From nobody Wed Mar  5 05:57:53 2014
Return-Path: <michael.scharf@alcatel-lucent.com>
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 3C3A51A010A for <tcpm@ietfa.amsl.com>; Wed,  5 Mar 2014 05:57:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzuSZ0EF8a7F for <tcpm@ietfa.amsl.com>; Wed,  5 Mar 2014 05:57:50 -0800 (PST)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id A881F1A0100 for <tcpm@ietf.org>; Wed,  5 Mar 2014 05:57:50 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s25Dvj6I016658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Mar 2014 07:57:46 -0600 (CST)
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 s25DviAV011625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Mar 2014 14:57:44 +0100
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 5 Mar 2014 14:57:44 +0100
From: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
To: tcpm IETF list <tcpm@ietf.org>
Thread-Topic: Feedback on use of Meetecho?
Thread-Index: Ac84et7K8uBFK4MISyq3VgovmA5DDQ==
Date: Wed, 5 Mar 2014 13:57:40 +0000
Message-ID: <655C07320163294895BBADA28372AF5D20FA78@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: http://mailarchive.ietf.org/arch/msg/tcpm/RG_LEEago4ZLVX2W4qQe4ICNZOc
Cc: "tcpm-chairs@tools.ietf.org" <tcpm-chairs@tools.ietf.org>
Subject: [tcpm] Feedback on use of Meetecho?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Mar 2014 13:57:52 -0000

Hi all,

As already mentioned on the mic on Monday: The chairs would appreciate feed=
back (in particular) from remote participants regarding the use of Meetecho=
. We requested for this the first time.

In general, it seems like a good technology, but if there are specific thou=
ghts in the TCPM community, please let us know.

Thanks

Michael


From nobody Wed Mar  5 23:57:20 2014
Return-Path: <nanditad@google.com>
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 A249E1A010B for <tcpm@ietfa.amsl.com>; Wed,  5 Mar 2014 23:57:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.925
X-Spam-Level: 
X-Spam-Status: No, score=-1.925 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 5Ie89eTYfPvT for <tcpm@ietfa.amsl.com>; Wed,  5 Mar 2014 23:57:16 -0800 (PST)
Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 41C1B1A012B for <tcpm@ietf.org>; Wed,  5 Mar 2014 23:57:16 -0800 (PST)
Received: by mail-oa0-f43.google.com with SMTP id g12so2253085oah.30 for <tcpm@ietf.org>; Wed, 05 Mar 2014 23:57:12 -0800 (PST)
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=8HjvgtEp2KX4/bMwRTo44mRneAGrTzQztFMtJEl6jtc=; b=Iv1Tu0uy4pjq2v+r+n+UOXLxwvpuFHF1NH8efgZhon0ZVQhZBaC3354QKXjQQGJm60 X/al/4q+SfFs3ZLISh09lPidTPMo0H08bik4UOT+9PpaPFU0TNViVAo2N7C1OMc46UZa CkdGFmS1VNnXOcQlvaNgeK2McVoQNqe9adFX5VMIIZchZDfMRBFTeVe4e861oToH4EaN /FowP1uw7EFJpWFVhUeFuNjF3ToYjEIrHiIuTs2rFQ2echzPHZB2Iji8W0I691hXlgsn tkpn7JhP8i7hba6+WC5Gaypl7z5K3qYCIY/CPWpNn5l6s/3wrwSyTC3dmwyK8DMOKnOb zBwQ==
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=8HjvgtEp2KX4/bMwRTo44mRneAGrTzQztFMtJEl6jtc=; b=CJkmfwwTAm6wEw2SK1jfez1wZr3zf8jrJLKkhxKj0fk6IlrS9oNG26MYV6NlXdLTWt +tDu/mbiudW/WeBBC6TbI0X7+wf27vtyL0QW3BCrCDSU/EUxBBPf76wZdGrUFwzwsOoR 9TfcgLpTVopAHHKG+rCNkVMYiANPA7NZnrRHr0ahvUe0tW5MlM17ONef1DX3Yf46gzMJ Cw7VHuAH/PZe26XKStOy093TOGPr9YIQqp3I/+7SaBxpdvQvx7ww6EqwpGUnhrz4hQLo ueHoLH0SVDqYyDerRx1zqQxBHDsNF8HBLyEqSDGOMfgjLal0cE3n6y7hz+BNt/6R0HsP c/SA==
X-Gm-Message-State: ALoCoQlybSMu7iOlmOU4QGFIttTlmmT/UbLJY06DoIYRkcHNXldAdl27pSBLmNFwX0VKzxr3wy+5wA1IOOe8qlFUQ3K/1a3IJzXgfNN7T1u9Q9JtGyIr2cZgR4VGNDPyHE+QaNao/1h1EwlB4vRBNN6981hD2wtd622nc45VpxlJ1Ud+tUEkdeeGJy+AfDCAXvCyM/wfYYd5
MIME-Version: 1.0
X-Received: by 10.60.15.131 with SMTP id x3mr4431145oec.15.1394092632269; Wed, 05 Mar 2014 23:57:12 -0800 (PST)
Received: by 10.182.113.167 with HTTP; Wed, 5 Mar 2014 23:57:12 -0800 (PST)
In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA31EF8B52@ESESSMB205.ericsson.se>
References: <7FD625EF1E1B1D4586EEAB7471ECDC0A200469@ESESSMB109.ericsson.se> <CAK6E8=d1+5OFvHUX2xPZaS1zuEnfZQSYbEuWc18K05S3MJ_W=A@mail.gmail.com> <81564C0D7D4D2A4B9A86C8C7404A13DA31EF8B52@ESESSMB205.ericsson.se>
Date: Wed, 5 Mar 2014 23:57:12 -0800
Message-ID: <CAB_+Fg5DSR_p5CtCWoKkKw0hbRNbyCSwpxtKf5E+o+u5cp7XwQ@mail.gmail.com>
From: Nandita Dukkipati <nanditad@google.com>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Content-Type: multipart/alternative; boundary=089e015365e6217fdb04f3eb7cd8
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/jGPAOQxcduxATR4c7mNCsczoAxM
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, =?UTF-8?Q?Martin_Winbj=C3=B6rk?= <martin.winbjork@ericsson.com>, "mattmathis@google.com" <mattmathis@google.com>
Subject: Re: [tcpm] TCP Tail Loss Probe
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Mar 2014 07:57:18 -0000

--089e015365e6217fdb04f3eb7cd8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Ingemar,

AFAIR the code does follow the draft closely. The draft allows for one or
two probes per tail loss episode - the implementation just sends one probe
before yielding to an RTO. You can quickly double check from these two
commits here-

Basic TLP algorithm (Section 2 of draft)
Commit:
http:///git/linux/kernel/cgit/torvalds/linux.git/commit/?id=3D6ba8a3b19e764=
b6a65e4030ab0999be50c291e6c<http://git.kernel.org/cgit/linux/kernel/git/tor=
valds/linux.git/commit/?id=3D6ba8a3b19e764b6a65e4030ab0999be50c291e6c>

Detecting recovered losses in TLP (Section 3 of draft)
Commit:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=
=3D9b717a8d245075ffb8e95a2dfb4ee97ce4747457

There have been a couple of bug fixes thereafter but it doesn't change the
basic algorithm.

Nandita

On Tue, Mar 4, 2014 at 11:40 PM, Ingemar Johansson S <
ingemar.s.johansson@ericsson.com> wrote:
> Thanks all for the prompt response.
>
> Short followup question, does the latest draft reflect the Linux TCP
implementation or are there later changes done in the Linux code ?.
> Martin is doing a master thesis (I am one of the supervisors). The
objective is to implement new suggested additions to TCP in our Java based
LTE system simulator  and study the impact on performance in various
simulated traffic cases. He recently studied CWV and now the time has come
to look closer at TLP, and even though the draft is exprired, it is still
of interest as it is enabled by default in the Linux TCP stack.
>
> /Ingemar
>
>> -----Original Message-----
>> From: Yuchung Cheng [mailto:ycheng@google.com]
>> Sent: den 28 februari 2014 19:35
>> To: Martin Winbj=C3=B6rk
>> Cc: tcpm@ietf.org; nanditad@google.com; ncardwell@google.com;
>> mattmathis@google.com; Ingemar Johansson S
>> Subject: Re: TCP Tail Loss Probe
>>
>> On Fri, Feb 28, 2014 at 6:25 AM, Martin Winbj=C3=B6rk
>> <martin.winbjork@ericsson.com> wrote:
>> > Hi
>> >
>> >
>> >
>> > I have a question regarding the draft for Tail Loss Probe found on the
>> > following link
>> >
>> > http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01
>> >
>> >
>> >
>> > What is the status of the draft? It has expired on August 29 2013. Is
>> > it still relevant and updated or has it been abandoned or continued
>> elsewhere?
>> Hi Martin,
>>
>> The feedback on tcpm after several meetings was although it is solving a=
n
>> important problem, 1) it is fairly complicated and 2) it relies on FACK
which is
>> not standardized.
>>
>> Therefore I and the other co-authors are working on a simpler solution
with
>> much wider scope: a new framework to encompass a dozen of heuristics
>> developed in the last two decades: RFC3517, FACK, TLP, F-RTO, traditiona=
l
>> RTO, lost retransmit, dynamic dupthresh for reordering, early retransmit
etc.
>> The underlying idea is to replace packet counter notion (e.g. 3 dupacks)
with
>> time. Allow fast timeout & recovery if network is still responsive, and
only
>> reset cwnd to 1 under extended silence. I was originally going to talk
about
>> this idea in this tcpm but have to cancel the trip  in the last minute.
>>
>> Anyways, we are hopeful to come up a newer draft that subsumes TLP (and
>> many other heuristics) and an implementation all together latter this
year.
>>
>>
>> >
>> >
>> >
>> > Regards
>> >
>> > Martin Winbj=C3=B6rk

--089e015365e6217fdb04f3eb7cd8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Ingemar,<br><br>AFAIR the code does follow the draft cl=
osely. The draft allows for one or two probes per tail loss episode - the i=
mplementation just sends one probe before yielding to an RTO. You can quick=
ly double check from these two commits here-<div>
<div><br><div>Basic TLP algorithm (Section 2 of draft)<br>Commit: <a href=
=3D"http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?=
id=3D6ba8a3b19e764b6a65e4030ab0999be50c291e6c">http:///git/linux/kernel/cgi=
t/torvalds/linux.git/commit/?id=3D6ba8a3b19e764b6a65e4030ab0999be50c291e6c<=
/a><br>
<br>Detecting recovered losses in TLP (Section 3 of draft)<br>Commit: <a hr=
ef=3D"http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit=
/?id=3D9b717a8d245075ffb8e95a2dfb4ee97ce4747457">http://git.kernel.org/cgit=
/linux/kernel/git/torvalds/linux.git/commit/?id=3D9b717a8d245075ffb8e95a2df=
b4ee97ce4747457</a></div>
<div><br></div><div>There have been a couple of bug fixes thereafter but it=
 doesn&#39;t change the basic algorithm.</div><div><br></div><div>Nandita<b=
r><br>On Tue, Mar 4, 2014 at 11:40 PM, Ingemar Johansson S &lt;<a href=3D"m=
ailto:ingemar.s.johansson@ericsson.com">ingemar.s.johansson@ericsson.com</a=
>&gt; wrote:<br>
&gt; Thanks all for the prompt response.<br>&gt;<br>&gt; Short followup que=
stion, does the latest draft reflect the Linux TCP implementation or are th=
ere later changes done in the Linux code ?.<br>&gt; Martin is doing a maste=
r thesis (I am one of the supervisors). The objective is to implement new s=
uggested additions to TCP in our Java based LTE system simulator =C2=A0and =
study the impact on performance in various simulated traffic cases. He rece=
ntly studied CWV and now the time has come to look closer at TLP, and even =
though the draft is exprired, it is still of interest as it is enabled by d=
efault in the Linux TCP stack.<br>
&gt;<br>&gt; /Ingemar<br>&gt;<br>&gt;&gt; -----Original Message-----<br>&gt=
;&gt; From: Yuchung Cheng [mailto:<a href=3D"mailto:ycheng@google.com">yche=
ng@google.com</a>]<br>&gt;&gt; Sent: den 28 februari 2014 19:35<br>&gt;&gt;=
 To: Martin Winbj=C3=B6rk<br>
&gt;&gt; Cc: <a href=3D"mailto:tcpm@ietf.org">tcpm@ietf.org</a>; <a href=3D=
"mailto:nanditad@google.com">nanditad@google.com</a>; <a href=3D"mailto:nca=
rdwell@google.com">ncardwell@google.com</a>;<br>&gt;&gt; <a href=3D"mailto:=
mattmathis@google.com">mattmathis@google.com</a>; Ingemar Johansson S<br>
&gt;&gt; Subject: Re: TCP Tail Loss Probe<br>&gt;&gt;<br>&gt;&gt; On Fri, F=
eb 28, 2014 at 6:25 AM, Martin Winbj=C3=B6rk<br>&gt;&gt; &lt;<a href=3D"mai=
lto:martin.winbjork@ericsson.com">martin.winbjork@ericsson.com</a>&gt; wrot=
e:<br>
&gt;&gt; &gt; Hi<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;=
&gt; &gt; I have a question regarding the draft for Tail Loss Probe found o=
n the<br>&gt;&gt; &gt; following link<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; <a =
href=3D"http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01">=
http://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01</a><br>
&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; What is th=
e status of the draft? It has expired on August 29 2013. Is<br>&gt;&gt; &gt=
; it still relevant and updated or has it been abandoned or continued<br>
&gt;&gt; elsewhere?<br>&gt;&gt; Hi Martin,<br>&gt;&gt;<br>&gt;&gt; The feed=
back on tcpm after several meetings was although it is solving an<br>&gt;&g=
t; important problem, 1) it is fairly complicated and 2) it relies on FACK =
which is<br>
&gt;&gt; not standardized.<br>&gt;&gt;<br>&gt;&gt; Therefore I and the othe=
r co-authors are working on a simpler solution with<br>&gt;&gt; much wider =
scope: a new framework to encompass a dozen of heuristics<br>&gt;&gt; devel=
oped in the last two decades: RFC3517, FACK, TLP, F-RTO, traditional<br>
&gt;&gt; RTO, lost retransmit, dynamic dupthresh for reordering, early retr=
ansmit etc.<br>&gt;&gt; The underlying idea is to replace packet counter no=
tion (e.g. 3 dupacks) with<br>&gt;&gt; time. Allow fast timeout &amp; recov=
ery if network is still responsive, and only<br>
&gt;&gt; reset cwnd to 1 under extended silence. I was originally going to =
talk about<br>&gt;&gt; this idea in this tcpm but have to cancel the trip =
=C2=A0in the last minute.<br>&gt;&gt;<br>&gt;&gt; Anyways, we are hopeful t=
o come up a newer draft that subsumes TLP (and<br>
&gt;&gt; many other heuristics) and an implementation all together latter t=
his year.<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;<br>&gt;=
&gt; &gt;<br>&gt;&gt; &gt; Regards<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; Martin=
 Winbj=C3=B6rk<br>
</div></div></div></div>

--089e015365e6217fdb04f3eb7cd8--


From nobody Thu Mar  6 03:01:28 2014
Return-Path: <pasi.sarolahti@iki.fi>
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 3A83F1A02A1 for <tcpm@ietfa.amsl.com>; Thu,  6 Mar 2014 03:01:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 toUkA7ctNLrv for <tcpm@ietfa.amsl.com>; Thu,  6 Mar 2014 03:01:24 -0800 (PST)
Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 028B51A0295 for <tcpm@ietf.org>; Thu,  6 Mar 2014 03:01:23 -0800 (PST)
Received: from dhcp-b35b.meeting.ietf.org (31.133.179.91) by kirsi1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 529734CF082E035B for tcpm@ietf.org; Thu, 6 Mar 2014 13:01:19 +0200
From: Pasi Sarolahti <pasi.sarolahti@iki.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <1CE69B7A-6F95-47AE-8DC1-2A37AA3DE362@iki.fi>
Date: Thu, 6 Mar 2014 11:01:13 +0000
To: "tcpm@ietf.org (tcpm@ietf.org)" <tcpm@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/-QmMIhs1eP5gt1bewdZSRkLK8d0
Subject: [tcpm] Minutes from TCPM monday session
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Mar 2014 11:01:26 -0000

Hi,

Draft minutes from Monday TCPM session are available at =
http://www.ietf.org/proceedings/89/minutes/minutes-89-tcpm . Please let =
me know about any corrections that need to be made.

Many thanks to Gorry and Richard for taking the notes!

- Pasi


From nobody Thu Mar  6 06:07:03 2014
Return-Path: <apetlund@ifi.uio.no>
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 5937F1A032A for <tcpm@ietfa.amsl.com>; Thu,  6 Mar 2014 06:07:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 MOEibjA9xuna for <tcpm@ietfa.amsl.com>; Thu,  6 Mar 2014 06:06:56 -0800 (PST)
Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id AF7281A032E for <tcpm@ietf.org>; Thu,  6 Mar 2014 06:06:54 -0800 (PST)
Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from <apetlund@ifi.uio.no>) id 1WLYwk-0003jW-4j for tcpm@ietf.org; Thu, 06 Mar 2014 15:06:50 +0100
Received: from dhcp-9fd3.meeting.ietf.org ([31.133.159.211]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user apetlund (Exim 4.80.1) (envelope-from <apetlund@ifi.uio.no>) id 1WLYwj-0006AZ-Ie for tcpm@ietf.org; Thu, 06 Mar 2014 15:06:50 +0100
From: Andreas Petlund <apetlund@ifi.uio.no>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <0E57C98E-D98A-4CE0-AC91-B55C453AC0F2@ifi.uio.no>
Date: Thu, 6 Mar 2014 14:06:48 +0000
To: tcpm@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
X-Mailer: Apple Mail (2.1874)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 3 sum msgs/h 2 total rcpts 4914 max rcpts/h 26 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: F30BB5BD99C242C5C9BAF48099FBCBF4F19BF512
X-UiO-SPAM-Test: remote_host: 31.133.159.211 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 21 max/h 4 blacklist 0 greylist 0 ratelimit 0
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/pJc23jfiDsh0nUySmQTrNvi-UYE
Subject: [tcpm] thoughts on RTO restart and TSO
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Mar 2014 14:07:00 -0000

Hi

I think the issue of TSO might warrant a discussion in the document, but =
unless the initial segments are huge, the _actual_ flight_size will not =
be much different from the observed flight_size. Also, segmentation / =
fragmentation may happen on the network path (for instance if the =
traffic passes through a node doing TSO or the MTU changes) and that =
should not stop the deployment of such an algorithm. Besides, as was =
mentioned, EFR already uses this metric.

Cheers,
Andreas Petlund=


From nobody Thu Mar  6 06:21:15 2014
Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 7268C1A03B7 for <tcpm@ietfa.amsl.com>; Thu,  6 Mar 2014 06:21:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_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 bpp_HzZs-MMd for <tcpm@ietfa.amsl.com>; Thu,  6 Mar 2014 06:21:04 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id C68261A03B5 for <tcpm@ietf.org>; Thu,  6 Mar 2014 06:20:55 -0800 (PST)
Received: from dhcp-9a05.meeting.ietf.org (dhcp-9a05.meeting.ietf.org [31.133.154.5]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 844EE1C104316; Thu,  6 Mar 2014 15:20:50 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <0E57C98E-D98A-4CE0-AC91-B55C453AC0F2@ifi.uio.no>
Date: Thu, 6 Mar 2014 14:20:48 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E90FBDC-E36E-4DED-9B7F-FFE5870F8302@lurchi.franken.de>
References: <0E57C98E-D98A-4CE0-AC91-B55C453AC0F2@ifi.uio.no>
To: Andreas Petlund <apetlund@ifi.uio.no>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/inQij6NsBuBp6XMNEUBRq2g4fJM
Cc: tcpm@ietf.org
Subject: Re: [tcpm] thoughts on RTO restart and TSO
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Mar 2014 14:21:13 -0000

On 06 Mar 2014, at 14:06, Andreas Petlund <apetlund@ifi.uio.no> wrote:

> Hi
>=20
> I think the issue of TSO might warrant a discussion in the document, =
but unless the initial segments are huge, the _actual_ flight_size will =
not be much different from the observed flight_size. Also, segmentation =
/ fragmentation may happen on the network path (for instance if the =
traffic passes through a node doing TSO or the MTU changes) and that =
should not stop the deployment of such an algorithm. Besides, as was =
mentioned, EFR already uses this metric.
Hi Andreas,

I just wanted to know how difficult it is to keep a correct counter of
outstanding segments. And how bad is it just to ignore the counter?
That would definitely be simpler...

Best regards
Michael
>=20
> Cheers,
> Andreas Petlund
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>=20


From nobody Thu Mar  6 06:38:06 2014
Return-Path: <apetlund@ifi.uio.no>
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 C6B731A041E for <tcpm@ietfa.amsl.com>; Thu,  6 Mar 2014 06:38:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 EebFILEHrRHu for <tcpm@ietfa.amsl.com>; Thu,  6 Mar 2014 06:37:59 -0800 (PST)
Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 57AA21A0137 for <tcpm@ietf.org>; Thu,  6 Mar 2014 06:37:59 -0800 (PST)
Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from <apetlund@ifi.uio.no>) id 1WLZQp-0004Bs-4U; Thu, 06 Mar 2014 15:37:55 +0100
Received: from dhcp-9fd3.meeting.ietf.org ([31.133.159.211]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user apetlund (Exim 4.80.1) (envelope-from <apetlund@ifi.uio.no>) id 1WLZQo-0005SW-Fm; Thu, 06 Mar 2014 15:37:55 +0100
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Andreas Petlund <apetlund@ifi.uio.no>
In-Reply-To: <6E90FBDC-E36E-4DED-9B7F-FFE5870F8302@lurchi.franken.de>
Date: Thu, 6 Mar 2014 14:37:53 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <12FA438E-F75E-498B-AF76-F7BCA7A1A6AA@ifi.uio.no>
References: <0E57C98E-D98A-4CE0-AC91-B55C453AC0F2@ifi.uio.no> <6E90FBDC-E36E-4DED-9B7F-FFE5870F8302@lurchi.franken.de>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
X-Mailer: Apple Mail (2.1874)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 4 sum rcpts/h 10 sum msgs/h 5 total rcpts 4921 max rcpts/h 26 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 8ED963423449EB93D82DB8CB2A04D94913CD4CCB
X-UiO-SPAM-Test: remote_host: 31.133.159.211 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 24 max/h 4 blacklist 0 greylist 0 ratelimit 0
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/6HQQgBSNK0-VkLGfZa7OH0n2F5Q
Cc: tcpm@ietf.org
Subject: Re: [tcpm] thoughts on RTO restart and TSO
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Mar 2014 14:38:04 -0000

On 06 Mar 2014, at 14:20, Michael Tuexen =
<Michael.Tuexen@lurchi.franken.de> wrote:

> On 06 Mar 2014, at 14:06, Andreas Petlund <apetlund@ifi.uio.no> wrote:
>=20
>> Hi
>>=20
>> I think the issue of TSO might warrant a discussion in the document, =
but unless the initial segments are huge, the _actual_ flight_size will =
not be much different from the observed flight_size. Also, segmentation =
/ fragmentation may happen on the network path (for instance if the =
traffic passes through a node doing TSO or the MTU changes) and that =
should not stop the deployment of such an algorithm. Besides, as was =
mentioned, EFR already uses this metric.
> Hi Andreas,
>=20
> I just wanted to know how difficult it is to keep a correct counter of
> outstanding segments. And how bad is it just to ignore the counter?
> That would definitely be simpler=85
>=20

There=92s been some discussion on this earlier. Keeping the flight_size =
score is pretty simple. For discussion, see this thread: =
http://www.ietf.org/mail-archive/web/tcpm/current/msg08496.html

Cheers,
Andreas

> Best regards
> Michael
>>=20
>> Cheers,
>> Andreas Petlund
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>=20
>=20


From nobody Thu Mar  6 06:52:16 2014
Return-Path: <bob.briscoe@bt.com>
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 6EE901A0086 for <tcpm@ietfa.amsl.com>; Thu,  6 Mar 2014 06:52:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 xvUEOy3g33qf for <tcpm@ietfa.amsl.com>; Thu,  6 Mar 2014 06:52:06 -0800 (PST)
Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) by ietfa.amsl.com (Postfix) with ESMTP id 832871A0079 for <tcpm@ietf.org>; Thu,  6 Mar 2014 06:52:06 -0800 (PST)
Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Mar 2014 14:52:01 +0000
Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 6 Mar 2014 14:52:00 +0000
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.347.0; Thu, 6 Mar 2014 14:52:00 +0000
Received: from BTP075694.jungle.bt.co.uk ([10.109.136.133])	by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s26Epwcq006941; Thu, 6 Mar 2014 14:51:59 GMT
Message-ID: <201403061451.s26Epwcq006941@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 6 Mar 2014 14:51:57 +0000
To: "EGGERT, Lars" <lars@netapp.com>, Martin Stiemerling <mls.ietf@gmail.com>
From: Bob Briscoe <bob.briscoe@bt.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/m3GcXWz9wP7MYEWIGKdzMF0SoHc
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Mar 2014 14:52:10 -0000

Lars,

Everyone seems to agree this should be independent stream. That 
leaves the question of intended status...

Imagine Microsoft now updates DCTCP to fix the feedback flaw. Then do 
you want to update this draft? I doubt it.

So, IMO if you wanted to only document what Microsoft did, even tho 
it was  broken, then this should be HISTORIC, not INFORMATIONAL.

If it's INFORMATIONAL it should at least fix known major problems 
before it is published.



Bob



________________________________________________________________
Bob Briscoe,                                                  BT 


From nobody Thu Mar  6 07:23:13 2014
Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 27DD01A00E2 for <tcpm@ietfa.amsl.com>; Thu,  6 Mar 2014 07:23:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_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 reoAXpaUVhrj for <tcpm@ietfa.amsl.com>; Thu,  6 Mar 2014 07:23:09 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 6C87D1A00CD for <tcpm@ietf.org>; Thu,  6 Mar 2014 07:23:09 -0800 (PST)
Received: from dhcp-9a05.meeting.ietf.org (dhcp-9a05.meeting.ietf.org [31.133.154.5]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 18A571C1042E0; Thu,  6 Mar 2014 16:23:04 +0100 (CET)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <12FA438E-F75E-498B-AF76-F7BCA7A1A6AA@ifi.uio.no>
Date: Thu, 6 Mar 2014 15:23:02 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <824A8171-3CB6-4C58-BB06-A18590043CB9@lurchi.franken.de>
References: <0E57C98E-D98A-4CE0-AC91-B55C453AC0F2@ifi.uio.no> <6E90FBDC-E36E-4DED-9B7F-FFE5870F8302@lurchi.franken.de> <12FA438E-F75E-498B-AF76-F7BCA7A1A6AA@ifi.uio.no>
To: Andreas Petlund <apetlund@ifi.uio.no>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/uHTis3bNOuVn3nRpuTCf6prUYzo
Cc: tcpm@ietf.org
Subject: Re: [tcpm] thoughts on RTO restart and TSO
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Mar 2014 15:23:11 -0000

On 06 Mar 2014, at 14:37, Andreas Petlund <apetlund@ifi.uio.no> wrote:

>=20
> On 06 Mar 2014, at 14:20, Michael Tuexen =
<Michael.Tuexen@lurchi.franken.de> wrote:
>=20
>> On 06 Mar 2014, at 14:06, Andreas Petlund <apetlund@ifi.uio.no> =
wrote:
>>=20
>>> Hi
>>>=20
>>> I think the issue of TSO might warrant a discussion in the document, =
but unless the initial segments are huge, the _actual_ flight_size will =
not be much different from the observed flight_size. Also, segmentation =
/ fragmentation may happen on the network path (for instance if the =
traffic passes through a node doing TSO or the MTU changes) and that =
should not stop the deployment of such an algorithm. Besides, as was =
mentioned, EFR already uses this metric.
>> Hi Andreas,
>>=20
>> I just wanted to know how difficult it is to keep a correct counter =
of
>> outstanding segments. And how bad is it just to ignore the counter?
>> That would definitely be simpler=85
>>=20
>=20
> There=92s been some discussion on this earlier. Keeping the =
flight_size score is pretty simple. For discussion, see this thread: =
http://www.ietf.org/mail-archive/web/tcpm/current/msg08496.html
OK, so the statement seems to be that it is easy for TCP. For SCTP some =
logic
has to be implemented to manage this information...

Best regards
Michael
>=20
> Cheers,
> Andreas
>=20
>> Best regards
>> Michael
>>>=20
>>> Cheers,
>>> Andreas Petlund
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>=20
>>=20
>=20
>=20


From nobody Thu Mar  6 07:38:07 2014
Return-Path: <apetlund@ifi.uio.no>
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 AB7BE1A00A2 for <tcpm@ietfa.amsl.com>; Thu,  6 Mar 2014 07:38:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 b2zDrGt7WjHC for <tcpm@ietfa.amsl.com>; Thu,  6 Mar 2014 07:38:02 -0800 (PST)
Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id 12C431A0064 for <tcpm@ietf.org>; Thu,  6 Mar 2014 07:38:02 -0800 (PST)
Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from <apetlund@ifi.uio.no>) id 1WLaMv-0006Rf-9B; Thu, 06 Mar 2014 16:37:57 +0100
Received: from [88.96.136.84] (helo=[172.17.1.127]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user apetlund (Exim 4.80.1) (envelope-from <apetlund@ifi.uio.no>) id 1WLaMu-0000OV-Ey; Thu, 06 Mar 2014 16:37:57 +0100
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Andreas Petlund <apetlund@ifi.uio.no>
In-Reply-To: <824A8171-3CB6-4C58-BB06-A18590043CB9@lurchi.franken.de>
Date: Thu, 6 Mar 2014 15:37:54 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <DC65C245-CF34-4201-954C-336801A665CD@ifi.uio.no>
References: <0E57C98E-D98A-4CE0-AC91-B55C453AC0F2@ifi.uio.no> <6E90FBDC-E36E-4DED-9B7F-FFE5870F8302@lurchi.franken.de> <12FA438E-F75E-498B-AF76-F7BCA7A1A6AA@ifi.uio.no> <824A8171-3CB6-4C58-BB06-A18590043CB9@lurchi.franken.de>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
X-Mailer: Apple Mail (2.1874)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 12 sum msgs/h 3 total rcpts 4934 max rcpts/h 26 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 32375D2387B40F6266BD28945642759221572427
X-UiO-SPAM-Test: remote_host: 88.96.136.84 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 12 max/h 3 blacklist 0 greylist 0 ratelimit 0
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/cxQ7286T2yg_KumDTilUq9y2AHU
Cc: tcpm@ietf.org
Subject: Re: [tcpm] thoughts on RTO restart and TSO
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Mar 2014 15:38:05 -0000

On 06 Mar 2014, at 15:23, Michael Tuexen =
<Michael.Tuexen@lurchi.franken.de> wrote:

> On 06 Mar 2014, at 14:37, Andreas Petlund <apetlund@ifi.uio.no> wrote:
>=20
>>=20
>> On 06 Mar 2014, at 14:20, Michael Tuexen =
<Michael.Tuexen@lurchi.franken.de> wrote:
>>=20
>>> On 06 Mar 2014, at 14:06, Andreas Petlund <apetlund@ifi.uio.no> =
wrote:
>>>=20
>>>> Hi
>>>>=20
>>>> I think the issue of TSO might warrant a discussion in the =
document, but unless the initial segments are huge, the _actual_ =
flight_size will not be much different from the observed flight_size. =
Also, segmentation / fragmentation may happen on the network path (for =
instance if the traffic passes through a node doing TSO or the MTU =
changes) and that should not stop the deployment of such an algorithm. =
Besides, as was mentioned, EFR already uses this metric.
>>> Hi Andreas,
>>>=20
>>> I just wanted to know how difficult it is to keep a correct counter =
of
>>> outstanding segments. And how bad is it just to ignore the counter?
>>> That would definitely be simpler=85
>>>=20
>>=20
>> There=92s been some discussion on this earlier. Keeping the =
flight_size score is pretty simple. For discussion, see this thread: =
http://www.ietf.org/mail-archive/web/tcpm/current/msg08496.html
> OK, so the statement seems to be that it is easy for TCP. For SCTP =
some logic
> has to be implemented to manage this information=85
>=20

That=92s true. I don=92t know the SCTP stack of Linux well enough to =
estimate the complexity of such score-boarding though. But by =
implementing it one will get the benefit of also enabling both RFC5827 =
and RTO restart.

Cheers,
Andreas



> Best regards
> Michael
>>=20
>> Cheers,
>> Andreas
>>=20
>>> Best regards
>>> Michael
>>>>=20
>>>> Cheers,
>>>> Andreas Petlund
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> tcpm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Thu Mar  6 16:01:52 2014
Return-Path: <rs@netapp.com>
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 413001A0160 for <tcpm@ietfa.amsl.com>; Thu,  6 Mar 2014 16:01:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.449
X-Spam-Level: 
X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-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 hHytghxWoOKl for <tcpm@ietfa.amsl.com>; Thu,  6 Mar 2014 16:01:48 -0800 (PST)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 989601A00F1 for <tcpm@ietf.org>; Thu,  6 Mar 2014 16:01:48 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.97,604,1389772800"; d="scan'208";a="75018582"
Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx2-out.netapp.com with ESMTP; 06 Mar 2014 16:01:44 -0800
Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Thu, 6 Mar 2014 16:01:45 -0800
From: "Scheffenegger, Richard" <rs@netapp.com>
To: Bob Briscoe <bob.briscoe@bt.com>, "Eggert, Lars" <lars@netapp.com>, "Martin Stiemerling" <mls.ietf@gmail.com>
Thread-Topic: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
Thread-Index: AQHPOUu64SN5EzE+1kCv6xR/oqMp2ZrUvLRg
Date: Fri, 7 Mar 2014 00:01:43 +0000
Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F260CFEA1@SACEXCMBX02-PRD.hq.netapp.com>
References: <201403061451.s26Epwcq006941@bagheera.jungle.bt.co.uk>
In-Reply-To: <201403061451.s26Epwcq006941@bagheera.jungle.bt.co.uk>
Accept-Language: de-AT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.122.105.25]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/vV2x6BH0AVscw9IXkJU8GIA2K-Y
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Mar 2014 00:01:50 -0000

Hi Bob,

I tend to disagree (but I don't have a very strong opinion about this) - at=
 least until the time that MS decides to fix the feedback issue (perhaps th=
e RTT fairness issue also?) this one being informational seems reasonable;=
=20

Also, the path for this draft sketched by Martin sounds best to me - improv=
e the draft via WG review/feedback/discussion, but then have it as an indiv=
idual, AD sponsored submission to the IESG. There is precedence for this, i=
e Adobe RTMFP / rfc7016, which became much better document that way.

Richard Scheffenegger


> -----Original Message-----
> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe
> Sent: Donnerstag, 06. M=E4rz 2014 14:52
> To: Eggert, Lars; Martin Stiemerling
> Cc: tcpm IETF list
> Subject: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
>=20
> Lars,
>=20
> Everyone seems to agree this should be independent stream. That leaves th=
e
> question of intended status...
>=20
> Imagine Microsoft now updates DCTCP to fix the feedback flaw. Then do you
> want to update this draft? I doubt it.
>=20
> So, IMO if you wanted to only document what Microsoft did, even tho it wa=
s
> broken, then this should be HISTORIC, not INFORMATIONAL.
>=20
> If it's INFORMATIONAL it should at least fix known major problems before
> it is published.
>=20
>=20
>=20
> Bob
>=20
>=20
>=20
> ________________________________________________________________
> Bob Briscoe,                                                  BT
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Sat Mar  8 02:47:33 2014
Return-Path: <gorry@erg.abdn.ac.uk>
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 C1ED81A0166 for <tcpm@ietfa.amsl.com>; Sat,  8 Mar 2014 02:47:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 ZOEdi4w2shfx for <tcpm@ietfa.amsl.com>; Sat,  8 Mar 2014 02:47:28 -0800 (PST)
Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCEE1A016A for <tcpm@ietf.org>; Sat,  8 Mar 2014 02:47:27 -0800 (PST)
Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id E1F292B4519; Sat,  8 Mar 2014 10:47:21 +0000 (GMT)
Received: from Gorrys-MacBook-Air.local (fgrpf.plus.com [212.159.18.54]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 7C3D12B44C7; Sat,  8 Mar 2014 10:47:18 +0000 (GMT)
Message-ID: <531AF534.6050209@erg.abdn.ac.uk>
Date: Sat, 08 Mar 2014 10:47:16 +0000
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: The University of Aberdeen is a charity registered in Scotland,  No SC013683. 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: draft-kuehlewind-tcpm-accecn-reqs@tools.ietf.org, tcpm@ietf.org
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/bDhKMYjIx71m282safnG754ZZQY
Subject: [tcpm] Some comments on: draft-kuehlewind-tcpm-accecn-reqs
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 <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Mar 2014 10:47:32 -0000

draft-ietf-tcpm-accecn-reqs-05

I have comments on this draft, they seem long and have a mixture of 
important and editorial-like comments. I am sorry for being late in 
returning this, I had intended to send something before the meeting in 
London.

Gorry

---

Overall - this ID  seems a valuable list of things to be considered, but 
  I am not sure the requirements are clear. Two top level comments are:

(1) I am not clear on the intended scope - is this proposing an update 
for the internet - for cones for the DC environment, all?

(2) The requirements listed in section 4  to figure out what is needed, 
desirable or just nice to have. The document could use requirements 
language if needed, but even if not, I really think it should call out 
more clearly what is required.

---

Detailed comments follow:

Scope:

(above point 1) I see the abstract says "Recent new TCP mechanisms (like 
ConEx or DCTCP) need more accurate ECN feedback in the case where more 
than one marking is received in one RTT." - which is fine, but this 
leaves open whether the methods proposed are for used in controlled 
environments, within domains such as Conex or the general Internet. 
(This seems to be a perhaps unintentional change from what I looked at 
in rev -03).

(above point 1) I really think the work should target methods that *can* 
be deployed in the general Internet. I'd suggest this actually becomes a 
requirement.

Section1:

(above point 1), I read "his document lists requirements for a robust 
and interoperable more accurate TCP/ECN feedback protocol that all 
implementations of new TCP extensions, like ConEx and/or DCTCP, can use. 
" - but from the current I-D, I read the scope as can be used by these 
two, but I think it needs to be applicable to general Internet 
deployment.  Please clarify the scope here also.

Section 2:

Disagree with text: "However, as the ECN Nonce is a separate extension 
to ECN, even if a sender tries to protect itself with the ECN Nonce, any 
receiver wishing to conceal marked packets only has to pretend not to 
support the ECN Nonce and simply does not provide any nonce sum feedback."
- To me this argument is ridiculous (and I have said so), and I think we 
should not perpetuate this argument!
[[Here is why:  if a sender were to require a NS, then a receiver would 
need to provide that or expect the sender would not continue use of ECN, 
or at least limit is trust of ECN.  So the wording could be improved, 
but RFC3540 says:  "If the receiver has never sent a non-zero nonce sum, 
the sender can infer that the receiver does not understand the nonce, 
and rate limit the connection, place it in a lower-priority queue, or 
cease setting ECT in outgoing segments."]]
- Saying the nonce sum has a second problem in that it only works if it 
is deployed and actually used seems obvious.

Other points that may help the argument: The WG should look for sound 
reasons to obsolete specs, saying the NS was not significantly (or not 
known to be) deployed however, does seem true to me. Saying there are 
equivalent methods may be true, and I think this is presented. Saying 
that the NS only validates non-congestion and hence provides much less 
useful protection for the more frequent marking of immediate-ECN is also 
true.

Section 3:

This section confuses me. I find no motivation for use beyond the two 
use-cases.

It seems to be a list of two use-cases, I assume these are *examples* of 
use, rather than required use-cases to consider?

It speaks of DTCP (which I think is currently only defined for 
controlled environments) and Conex (specified for a specific domain). 
Reiterating (point 1), I'd hoped these were examples, but that the 
actual WG goal was now to define a general purpose method for feedback. 
Or is it?

Ordering of examples: How much deployment experience do we have  of 
Conex? I'm not arguing to  remove this use-case, but wonder whether this 
is best to be placed first in the examples of use?

Is there an implied use-case of standard TCP and a possible use case of 
an updated ECN for TCP? - I think this is only hinted.

Section 4:

Usage of RFC 2119: Personally, I really do not like use of RFC2119 
keywords in this way: "This leads to the following requirements, which 
MUST be discussed for any proposed more accurate ECN feedback scheme:" - 
Mandating discussion is not helpful.

(point 2 above): If we have requirements as the title suggests, then I 
personally would encourage you to list them as requirements using RFC 
2119 language - but I don't mind seeing no RFC 2119 keywords if the WG 
wants this, as long as I can see the relative importance of each topic. 
At the moment I can't see this.

Comments on specific topics:

Resilience

"Moreover, delayed ACK are mostly used with TCP.  That means in most 
cases only every second data packets triggers an ACK."
- Isn't it one ACK for every 2 full-sized MSS of data? The ACK rate per 
segment can be much less if the sender disables the Nagle algorithm. I'd 
really like a requirement that this mechanism is robust for use with 
"thin" streams that disable Nagle - and to understand what this means, 
and if we simply require interop in this case, or whether we require Acc 
ECN to work accurately.

- Some reference is probably needed to explain the variety of TCP ACK 
mangling - e.g. RFC 3449 illustrates at the least the breadth of 
mechanisms out there.

"Also, a more accurate feedback protocol should still work if delayed 
ACKs covered more than two packets."
- In IETF understanding is this really a "should" - I see it is lower 
case, but it is best not to be ambiguous? does this mean it may not 
work, or may not be accurate or may cause the TCP receiver to reset (I 
hope not)?

- Is this resilience to loss?

- Are there implied ordering requirements for the path? - i.e. I'd 
assume we want a system that does is not impacted by reordering of ACKs, 
even when the ACK'ed sequence number does not increase, or do we assume 
an ordered path?

- I think it worth also noting a  *separate topic* for the need for 
robustness to known middle boxes as a desirable feature? … I think this 
is added in "Backward and forward compatibility" - to me such a section 
is usually expect to see as a protocol evolution issue, rather than a 
middle box issue.

Timeliness

"A CE mark can be induced by a network node on the transmission path and 
is then echoed by the receiver in the TCP ACK. "
- I think CE can also be set by the sending host, please update.

"Thus when this information arrives at the sender, it is naturally 
already about one RTT old."
- not really, it is at least 1/2 RTT old - depending on where loss was 
encountered.

"A RFC5681 TCP sender without ConEx:"
  ^^
/A/An/ - is it better

Integrity
- This starts "it should be possible" and later mentions requirements, 
is this "a sender SHOULD implement…" (required) or "senders MAY 
implement …" (can) or "a SENDER should implement and MAY enable" 
(required feature, optional deployment) - please clarify and avoid 
possible, etc.

"Whether a sender should enforce when it detects wrong feedback 
information, and what kind of enforcement it should apply, are policy 
issues that need not be specified as part of more accurate ECN feedback 
scheme."
- To me this seems like a clear recommendation not to do this - are 
these really policy decisions, are you saying that the IETF doesn't need 
to do this. I am not sure I agree, if the sender state machine can 
detect and react to bogus feedback this maybe should be considered, and 
I think it would be desirable to know that such mechanisms can be used 
with any selected approach.

- If there is policy, be clear what sort of policy - per stack, per 
socket, per interface, per provisioning domain…

Accuracy

"However, assuming the sender marks all data packets as ECN-capable and 
uses the default setting of ECT(0),"
This may just be wording: - Is use of only ECT(0) assumed somewhere in 
the RFC series, (mate in PCN?) ? RFC 4774 is a BCP specifies different 
semantics can be used for the two ECT code points for a different DSCP, 
to me this indicates that transports should at least be robust to this, 
and I'd expect that TCP could be used in this case. Is this a 
requirement? (I think it should be).

The clause  continues to say feedback of CE and ECT(1) is sufficient. 
So wouldn't this also be the case if both ECT(0) and ECT(1) were used? 
i.e. maybe it works fine for other DSCP semantics, by feeding back CE 
and ECT(1). Please clarify.

Complexity:

Maybe this is in the wrong section: "Furthermore, the receiver should 
not make assumptions about the mechanism that was used to set the 
markings nor about any interpretation or reaction to the congestion 
signal. The receiver only needs to faithfully reflect congestion 
information back to the sender."
- This does not seem like a complexity requirement to me. It seems like 
an actual requirement. I'd have expected stronger language against the 
network not interpreting the meaning of the reaction. Could this be 
"MUST NOT"? (maybe needs to be in a middle box section).

Backward and forward compatibility

/it should to be/it should be/

Middleboxes (see earlier)

"A more accurate ECN feedback extension should aim to be able to 
traverse most existing middleboxes."
- should … aim .. most … existing … This seems full of questions: Why 
not "should aim to traverse most middle boxes"? … but see note above, is 
this really backwards compatibility?

I'd love to see more here that motivates why the methods in 
"draft-kuehlewind-tcpm-ecn-fallback" need to be considered. I think this 
it is really important that any ECN method works through commonly 
deployed middle boxes and also that there are at least tools to verify 
that this working is correct, even if we do not directly mandate methods 
to probe and validate the path (which I also think we should seriously 
consider).

I have found a  separate section on middle boxes that uses the words 
"firewall and NAT" is generally helpful to ensure that people from the 
community actually find advice and know it is directed to them. If they 
don't like these requirements they should tell us before we do the work.

Section 5:

"In case of " - insert "the"

"highly vulnerable to ACK loss." - how is this different to being simply 
vulnerable? - can you explain "highly"?

"still highly ambiguous" - as above, it seems ambiguous?

"A couple of coding schemes"
- is this a couple as in a linked set or as in two, please clarify language.

"Urgent Pointer field" - please refer to the recent TCPM RFC on use of URG.

"but still not ideal." - I don't see ideal as a goal, consider rewording?

I found the last para of 5.1 is a hard read, unless the reader knows 
what is being said already.

Sect 5.2:

"Alternatively, the receiver could use bits in the Urgent Pointer field 
to signal more bits of its congestion signal counter, but only whenever 
it does not set the Urgent Flag."
- I'd urge rewording this, far too often I see sentences from RFCs 
replicated in other places. In place of this can we say that this is NOT 
permitted, but a new method could standardise use of these bits…

Sect 5.3:

"and SCTP counts the number" - probably this needs to be cited as a 
"proposal", since this draft has not to date been progressed.

"this option would need to be carried by most or all ACKs" - can you 
explain why? even in times of non-congestion?

Sect 8

I would expect to see some discussion that states that ECN feedback 
should only be used if the other information indicates the congestion 
was on-path - i.e. feedback MUST use normal TCP sequence number check 
techniques to verify the CE-marked packet was a part of the current 
flow, and similarly ECN marking feedback is only accepted on valid ACKs.

I'd really like this section to point to the mechanisms that may be used 
to validate that the remote endpoint responds appropriately to ECN. It 
is relatively easy to do sender-side changes, but knowing the receiver 
"correctly" implements a function is much harder.


I am happy to review again, this is heading in a good direction.


From nobody Sat Mar  8 15:08:35 2014
Return-Path: <rs@netapp.com>
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 E716D1A02EB for <tcpm@ietfa.amsl.com>; Sat,  8 Mar 2014 15:08:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.449
X-Spam-Level: 
X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-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 4EDh-LQcXYiK for <tcpm@ietfa.amsl.com>; Sat,  8 Mar 2014 15:08:29 -0800 (PST)
Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id E1D551A02EC for <tcpm@ietf.org>; Sat,  8 Mar 2014 15:08:28 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.97,616,1389772800"; d="scan'208";a="148485169"
Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 08 Mar 2014 15:08:23 -0800
Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Sat, 8 Mar 2014 15:08:23 -0800
From: "Scheffenegger, Richard" <rs@netapp.com>
To: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, "draft-kuehlewind-tcpm-accecn-reqs@tools.ietf.org" <draft-kuehlewind-tcpm-accecn-reqs@tools.ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: [tcpm] Some comments on: draft-kuehlewind-tcpm-accecn-reqs
Thread-Index: AQHPOrvPnnC2Yencfk2wJMba8ybB+prXXZjw
Date: Sat, 8 Mar 2014 23:08:23 +0000
Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F260D7F08@SACEXCMBX02-PRD.hq.netapp.com>
References: <531AF534.6050209@erg.abdn.ac.uk>
In-Reply-To: <531AF534.6050209@erg.abdn.ac.uk>
Accept-Language: de-AT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.106.53.53]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/vdAIpUTQm-CqzgGG-Spu67kaH0I
Cc: Brian Trammell <trammell@tik.ee.ethz.ch>
Subject: Re: [tcpm] Some comments on: draft-kuehlewind-tcpm-accecn-reqs
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Mar 2014 23:08:33 -0000

Hi Gorry,

Thanks for the review!


> (1) I am not clear on the intended scope - is this proposing an update fo=
r
> the internet - for cones for the DC environment, all?

The scope was to include all scenarios (even though I can not decipher what=
 you refer to with "cones", I assume you mean "core [internet]" vs. "the [e=
dge and core] internet"...

The requirements really are mostly a list of what we (authors) could come u=
p with, what would have some applicability somewhere. It is up to a specifi=
c mechanism that is supposed to be deployed anywhere to accommodate these r=
equirements as good as it can.

> (2) The requirements listed in section 4  to figure out what is needed,
> desirable or just nice to have. The document could use requirements
> language if needed, but even if not, I really think it should call out
> more clearly what is required.

If we use 2119 language in there, we (WG) need to agree upon a set of *mini=
mum* requirements that would be necessary at least. And yes, that list will=
 probably be much shorter or concise than what is now in section 4.





> Detailed comments follow:
>=20
> Scope:
>=20
> (above point 1) I see the abstract says "Recent new TCP mechanisms (like
> ConEx or DCTCP) need more accurate ECN feedback in the case where more
> than one marking is received in one RTT." - which is fine, but this leave=
s
> open whether the methods proposed are for used in controlled environments=
,
> within domains such as Conex or the general Internet.
> (This seems to be a perhaps unintentional change from what I looked at in
> rev -03).
>=20
> (above point 1) I really think the work should target methods that *can*
> be deployed in the general Internet. I'd suggest this actually becomes a
> requirement.

Agreed. We probably want to put something very much like that sentence in t=
he abstract.

The new scheme should work at least as good as what we have, but ideally mu=
ch better.

=20
> Section1:
>=20
> (above point 1), I read "his document lists requirements for a robust and
> interoperable more accurate TCP/ECN feedback protocol that all
> implementations of new TCP extensions, like ConEx and/or DCTCP, can use.
> " - but from the current I-D, I read the scope as can be used by these
> two, but I think it needs to be applicable to general Internet deployment=
.
> Please clarify the scope here also.
>=20
> Section 2:
>=20
> Disagree with text: "However, as the ECN Nonce is a separate extension to
> ECN, even if a sender tries to protect itself with the ECN Nonce, any
> receiver wishing to conceal marked packets only has to pretend not to
> support the ECN Nonce and simply does not provide any nonce sum feedback.=
"
>
> - To me this argument is ridiculous (and I have said so), and I think we
> should not perpetuate this argument!
>
> [[Here is why:  if a sender were to require a NS, then a receiver would
> need to provide that or expect the sender would not continue use of ECN,
> or at least limit is trust of ECN.  So the wording could be improved, but
> RFC3540 says:  "If the receiver has never sent a non-zero nonce sum, the
> sender can infer that the receiver does not understand the nonce, and rat=
e
> limit the connection, place it in a lower-priority queue, or cease settin=
g
> ECT in outgoing segments."]]
>=20
> - Saying the nonce sum has a second problem in that it only works if it i=
s
> deployed and actually used seems obvious.
>=20
> Other points that may help the argument: The WG should look for sound
> reasons to obsolete specs, saying the NS was not significantly (or not
> known to be) deployed however, does seem true to me. Saying there are
> equivalent methods may be true, and I think this is presented. Saying tha=
t
> the NS only validates non-congestion and hence provides much less useful
> protection for the more frequent marking of immediate-ECN is also true.

We try to come up with different text that essentially captures that in a f=
ew words.


> Section 3:
>=20
> This section confuses me. I find no motivation for use beyond the two use=
-
> cases.
>=20
> It seems to be a list of two use-cases, I assume these are *examples* of
> use, rather than required use-cases to consider?
>=20
> It speaks of DCTCP (which I think is currently only defined for controlle=
d
> environments) and Conex (specified for a specific domain).

As discussed during the DCTCP presentation, the mechanis could have more wi=
de spread (internet wide) applicability, if done right (sender reaction, re=
ceiver behavior, ecn semantic, network aqm settings *AND* TCP ECN feedback =
signal).=20

> Reiterating (point 1), I'd hoped these were examples, but that the actual
> WG goal was now to define a general purpose method for feedback.
> Or is it?

That was our aim, to eventually have a signaling scheme that could carter f=
or the mentioned examples (we need to describe them as that), but also enab=
ling future algorithms which we don't know about today.


=20
> Ordering of examples: How much deployment experience do we have  of Conex=
?
> I'm not arguing to  remove this use-case, but wonder whether this is best
> to be placed first in the examples of use?

The ordering was mostly based on what has been done in IETF so far; Conex r=
eceived much more formal attention than DCTCP so far; alternatively, I coul=
d claim that the list was done alphabetically to make clear that the order =
of these doesn't have any more significance... :) (but that isn't really ho=
w the order happened to end up)

=20
> Is there an implied use-case of standard TCP and a possible use case of a=
n
> updated ECN for TCP? - I think this is only hinted.

Definitely, we didn't explicitly mention it though.


=20
> Section 4:
>=20
> Usage of RFC 2119: Personally, I really do not like use of RFC2119
> keywords in this way: "This leads to the following requirements, which
> MUST be discussed for any proposed more accurate ECN feedback scheme:" -
> Mandating discussion is not helpful.

Slightly reworded.

> (point 2 above): If we have requirements as the title suggests, then I
> personally would encourage you to list them as requirements using RFC
> 2119 language - but I don't mind seeing no RFC 2119 keywords if the WG
> wants this, as long as I can see the relative importance of each topic.
> At the moment I can't see this.

We definitely need more WG discussion around this, and also around the impo=
rtance of each aspect of the various requirements. I'm trying to do somethi=
ng along those lines, in the next version to allow comparison.

=20
> Comments on specific topics:
>=20
> Resilience
>=20
> "Moreover, delayed ACK are mostly used with TCP.  That means in most case=
s
> only every second data packets triggers an ACK."
> - Isn't it one ACK for every 2 full-sized MSS of data? The ACK rate per
> segment can be much less if the sender disables the Nagle algorithm. I'd
> really like a requirement that this mechanism is robust for use with
> "thin" streams that disable Nagle - and to understand what this means, an=
d
> if we simply require interop in this case, or whether we require Acc ECN
> to work accurately.

My recollection of both Linux and BSD stacks is, that they actually operate=
 on every other data segment, not when MSS+1 bytes are received. Checking -=
 Yupp, looks that way still in freebsd :) This is more restrictive than RFC=
1122 / 4.2.3.2 though, which allows what you state.


> - Some reference is probably needed to explain the variety of TCP ACK
> mangling - e.g. RFC 3449 illustrates at the least the breadth of
> mechanisms out there.
>=20
> "Also, a more accurate feedback protocol should still work if delayed ACK=
s
> covered more than two packets."
> - In IETF understanding is this really a "should" - I see it is lower
> case, but it is best not to be ambiguous? does this mean it may not work,
> or may not be accurate or may cause the TCP receiver to reset (I hope
> not)?

I think the phrase to tighten here is "should still work" to mean "should s=
till provide more accurate feedback then classic ECN ...", right?=20


=20
> - Is this resilience to loss?

Correct. Apparently we are missing an initial sentence here.


> - Are there implied ordering requirements for the path? - i.e. I'd assume
> we want a system that does is not impacted by reordering of ACKs, even
> when the ACK'ed sequence number does not increase, or do we assume an
> ordered path?

Good catch; the (my) implied assumption was that the ECN signal is interpre=
ted *after* the segment acceptance check. For pure ACKs that means, unorder=
ed ACKs are not processed;=20

=20
> - I think it worth also noting a  *separate topic* for the need for
> robustness to known middle boxes as a desirable feature? ... I think this=
 is
> added in "Backward and forward compatibility" - to me such a section is
> usually expect to see as a protocol evolution issue, rather than a middle
> box issue.
>=20
> Timeliness
>=20
> "A CE mark can be induced by a network node on the transmission path and
> is then echoed by the receiver in the TCP ACK. "
> - I think CE can also be set by the sending host, please update.

Will do.
=20
> "Thus when this information arrives at the sender, it is naturally alread=
y
> about one RTT old."
> - not really, it is at least 1/2 RTT old - depending on where loss was
> encountered.

Well, if we want to have acute precise wording, would that sound better: "a=
bout one backward plus a fraction of the forward delay old"? The backward d=
elay can be vastly different from the forward delay (asymmetric satellite l=
inks with ground return link), thus 1/2 RTT is as skewed as saying about on=
e RTT...

=20
> "A RFC5681 TCP sender without ConEx:"
>   ^^
> /A/An/ - is it better
>=20

Thanks,


> Integrity
> - This starts "it should be possible" and later mentions requirements, is
> this "a sender SHOULD implement..." (required) or "senders MAY implement =
..."
> (can) or "a SENDER should implement and MAY enable"
> (required feature, optional deployment) - please clarify and avoid
> possible, etc.
>=20
> "Whether a sender should enforce when it detects wrong feedback
> information, and what kind of enforcement it should apply, are policy
> issues that need not be specified as part of more accurate ECN feedback
> scheme."
> - To me this seems like a clear recommendation not to do this - are these
> really policy decisions, are you saying that the IETF doesn't need to do
> this. I am not sure I agree, if the sender state machine can detect and
> react to bogus feedback this maybe should be considered, and I think it
> would be desirable to know that such mechanisms can be used with any
> selected approach.

The exact reaction was also left out of RFC3540, unfortunately. This docume=
nt focuses on the requirements of the signaling protocol, whereas the polic=
y would be enforced by e.g. a congestion control algorithm.

>=20
> - If there is policy, be clear what sort of policy - per stack, per
> socket, per interface, per provisioning domain...

I would lead to a per stack granularity, ie. limiting cwnd, reacting overly=
 conservatively to loss, etc. I think this discussion would belong in a CC-=
draft, that makes use of the signals coming out of a more accurate ECN feed=
back scheme. We could perhaps define these signals in the requirements draf=
t though.

>=20
> Accuracy
>=20
> "However, assuming the sender marks all data packets as ECN-capable and
> uses the default setting of ECT(0),"
> This may just be wording: - Is use of only ECT(0) assumed somewhere in th=
e
> RFC series, (mate in PCN?) ? RFC 4774 is a BCP specifies different
> semantics can be used for the two ECT code points for a different DSCP, t=
o
> me this indicates that transports should at least be robust to this, and
> I'd expect that TCP could be used in this case. Is this a requirement? (I
> think it should be).

RFC3168 states: "When only one ECT codepoint
   is needed by a sender for all packets sent on a TCP connection,
   ECT(0) SHOULD be used."


The point this paragraph tries to make is, that as the sender does know whi=
ch packets get sent with non-ECT, ECT(0), ECT(1) and CE, if one of ECT(0) o=
r ECT(1) is the default, the receiver needs only reflect the other two so t=
hat the sender can make accurate accounting in what state the ECT segments =
were received... So, a scheme could swap ECT(0)/ECT(1) here. However, havin=
g yet-different semantics between ECT(0) and ECT(1) would be detrimental to=
 the case of breaking the linkage of CE mark =3D=3D loss.

I added the reference to 3168 here, though.






> The clause  continues to say feedback of CE and ECT(1) is sufficient.
> So wouldn't this also be the case if both ECT(0) and ECT(1) were used?
> i.e. maybe it works fine for other DSCP semantics, by feeding back CE and
> ECT(1). Please clarify.

I try again: We have some known entities at the sender #total =3D (# ECT0 +=
 # ECT1 + # CE) segments sent; in order to deduce these three values at the=
 receiver side, the signal must convey at least two back to the sender, whi=
ch can then calculate the third of the set locally.=20

How about:

          As the sender can keep account of the transmitted segments=20
          with any of the three ECN codepoints, conveying any two=20
          of these back to the sender is sufficient for it to=20
          reconstruct the third as observed by the receiver.
         =20


> Complexity:
>=20
> Maybe this is in the wrong section: "Furthermore, the receiver should not
> make assumptions about the mechanism that was used to set the markings no=
r
> about any interpretation or reaction to the congestion signal. The
> receiver only needs to faithfully reflect congestion information back to
> the sender."
> - This does not seem like a complexity requirement to me. It seems like a=
n
> actual requirement. I'd have expected stronger language against the
> network not interpreting the meaning of the reaction. Could this be "MUST
> NOT"? (maybe needs to be in a middle box section).

Moved.

> Backward and forward compatibility
>=20
> /it should to be/it should be/
>=20
> Middleboxes (see earlier)
>=20
> "A more accurate ECN feedback extension should aim to be able to traverse
> most existing middleboxes."
> - should ... aim .. most ... existing ... This seems full of questions: W=
hy not
> "should aim to traverse most middle boxes"? ... but see note above, is th=
is
> really backwards compatibility?
>=20
> I'd love to see more here that motivates why the methods in "draft-
> kuehlewind-tcpm-ecn-fallback" need to be considered. I think this it is
> really important that any ECN method works through commonly deployed
> middle boxes and also that there are at least tools to verify that this
> working is correct, even if we do not directly mandate methods to probe
> and validate the path (which I also think we should seriously consider).
>=20
> I have found a  separate section on middle boxes that uses the words
> "firewall and NAT" is generally helpful to ensure that people from the
> community actually find advice and know it is directed to them. If they
> don't like these requirements they should tell us before we do the work.


I've places these keywords in the relevant paragraph, so that a grep spots =
them...


>=20
> Section 5:
>=20
> "In case of " - insert "the"
>=20
> "highly vulnerable to ACK loss." - how is this different to being simply
> vulnerable? - can you explain "highly"?
>=20
> "still highly ambiguous" - as above, it seems ambiguous?
>=20
> "A couple of coding schemes"
> - is this a couple as in a linked set or as in two, please clarify
> language.
>=20
> "Urgent Pointer field" - please refer to the recent TCPM RFC on use of
> URG.

Added reference to rfc6093.

> "but still not ideal." - I don't see ideal as a goal, consider rewording?
>=20
> I found the last para of 5.1 is a hard read, unless the reader knows what
> is being said already.


Which may be a good thing :) Will try to get this paragraph split and strai=
ghtened.

> Sect 5.2:
>=20
> "Alternatively, the receiver could use bits in the Urgent Pointer field t=
o
> signal more bits of its congestion signal counter, but only whenever it
> does not set the Urgent Flag."
> - I'd urge rewording this, far too often I see sentences from RFCs
> replicated in other places. In place of this can we say that this is NOT
> permitted, but a new method could standardise use of these bits...

Reworked.

=20
> Sect 5.3:
>=20
> "and SCTP counts the number" - probably this needs to be cited as a
> "proposal", since this draft has not to date been progressed.
>=20
> "this option would need to be carried by most or all ACKs" - can you
> explain why? even in times of non-congestion?
>=20
> Sect 8
>=20
> I would expect to see some discussion that states that ECN feedback shoul=
d
> only be used if the other information indicates the congestion was on-pat=
h
> - i.e. feedback MUST use normal TCP sequence number check techniques to
> verify the CE-marked packet was a part of the current flow, and similarly
> ECN marking feedback is only accepted on valid ACKs.
>=20
> I'd really like this section to point to the mechanisms that may be used
> to validate that the remote endpoint responds appropriately to ECN. It is
> relatively easy to do sender-side changes, but knowing the receiver
> "correctly" implements a function is much harder.
>=20
>=20
> I am happy to review again, this is heading in a good direction.
>=20


Lot's of good feedback, thank you very much !

Richard Scheffenegger


From nobody Sun Mar  9 00:26:45 2014
Return-Path: <gorry@erg.abdn.ac.uk>
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 A69051A017E for <tcpm@ietfa.amsl.com>; Sun,  9 Mar 2014 00:26:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 moOCEWK48u86 for <tcpm@ietfa.amsl.com>; Sun,  9 Mar 2014 00:26:40 -0800 (PST)
Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 53DCC1A0160 for <tcpm@ietf.org>; Sun,  9 Mar 2014 00:26:40 -0800 (PST)
Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id DFF532B40E7; Sun,  9 Mar 2014 08:26:34 +0000 (GMT)
Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Sun, 9 Mar 2014 08:26:35 -0000
Message-ID: <42bc59eb086542a1e28c435527a85ed5.squirrel@www.erg.abdn.ac.uk>
In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F260D7F08@SACEXCMBX02-PRD.hq.netapp.com>
References: <531AF534.6050209@erg.abdn.ac.uk> <012C3117EDDB3C4781FD802A8C27DD4F260D7F08@SACEXCMBX02-PRD.hq.netapp.com>
Date: Sun, 9 Mar 2014 08:26:35 -0000
From: gorry@erg.abdn.ac.uk
To: "Scheffenegger, Richard" <rs@netapp.com>
User-Agent: SquirrelMail/1.4.22
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/99Px8zZoOvUHg6IupTcLL9tCjlE
Cc: "draft-kuehlewind-tcpm-accecn-reqs@tools.ietf.org" <draft-kuehlewind-tcpm-accecn-reqs@tools.ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>, Brian Trammell <trammell@tik.ee.ethz.ch>
Subject: Re: [tcpm] Some comments on: draft-kuehlewind-tcpm-accecn-reqs
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Mar 2014 08:26:44 -0000

A few responses in-line. It sounds like the new revision will address
most/all of my comments,


> Hi Gorry,
>
> Thanks for the review!
>
>
>> (1) I am not clear on the intended scope - is this proposing an update
>> for
>> the internet - for cones for the DC environment, all?
>
> The scope was to include all scenarios (even though I can not decipher
> what you refer to with "cones", I assume you mean "core [internet]" vs.
> "the [edge and core] internet"...
>
Good I agree with this.
/cones/ was a typo.

> The requirements really are mostly a list of what we (authors) could come
> up with, what would have some applicability somewhere. It is up to a
> specific mechanism that is supposed to be deployed anywhere to accommodate
> these requirements as good as it can.
>
Excellent, but then the intro and examples should state this,

>> (2) The requirements listed in section 4  to figure out what is needed,
>> desirable or just nice to have. The document could use requirements
>> language if needed, but even if not, I really think it should call out
>> more clearly what is required.
>
> If we use 2119 language in there, we (WG) need to agree upon a set of
> *minimum* requirements that would be necessary at least. And yes, that
> list will probably be much shorter or concise than what is now in section
> 4.
>
I agree, the choice of using RFC 2119 requirements language is up to the WG.

>> Detailed comments follow:
>>
>> Scope:
>>
>> (above point 1) I see the abstract says "Recent new TCP mechanisms (like
>> ConEx or DCTCP) need more accurate ECN feedback in the case where more
>> than one marking is received in one RTT." - which is fine, but this
>> leaves
>> open whether the methods proposed are for used in controlled
>> environments,
>> within domains such as Conex or the general Internet.
>> (This seems to be a perhaps unintentional change from what I looked at
>> in
>> rev -03).
>>
>> (above point 1) I really think the work should target methods that *can*
>> be deployed in the general Internet. I'd suggest this actually becomes a
>> requirement.
>
> Agreed. We probably want to put something very much like that sentence in
> the abstract.
>
> The new scheme should work at least as good as what we have, but ideally
> much better.
>
OK
>
>> Section1:
>>
>> (above point 1), I read "his document lists requirements for a robust
>> and
>> interoperable more accurate TCP/ECN feedback protocol that all
>> implementations of new TCP extensions, like ConEx and/or DCTCP, can use.
>> " - but from the current I-D, I read the scope as can be used by these
>> two, but I think it needs to be applicable to general Internet
>> deployment.
>> Please clarify the scope here also.
>>
>> Section 2:
>>
>> Disagree with text: "However, as the ECN Nonce is a separate extension
>> to
>> ECN, even if a sender tries to protect itself with the ECN Nonce, any
>> receiver wishing to conceal marked packets only has to pretend not to
>> support the ECN Nonce and simply does not provide any nonce sum
>> feedback."
>>
>> - To me this argument is ridiculous (and I have said so), and I think we
>> should not perpetuate this argument!
>>
>> [[Here is why:  if a sender were to require a NS, then a receiver would
>> need to provide that or expect the sender would not continue use of ECN,
>> or at least limit is trust of ECN.  So the wording could be improved,
>> but
>> RFC3540 says:  "If the receiver has never sent a non-zero nonce sum, the
>> sender can infer that the receiver does not understand the nonce, and
>> rate
>> limit the connection, place it in a lower-priority queue, or cease
>> setting
>> ECT in outgoing segments."]]
>>
>> - Saying the nonce sum has a second problem in that it only works if it
>> is
>> deployed and actually used seems obvious.
>>
>> Other points that may help the argument: The WG should look for sound
>> reasons to obsolete specs, saying the NS was not significantly (or not
>> known to be) deployed however, does seem true to me. Saying there are
>> equivalent methods may be true, and I think this is presented. Saying
>> that
>> the NS only validates non-congestion and hence provides much less useful
>> protection for the more frequent marking of immediate-ECN is also true.
>
> We try to come up with different text that essentially captures that in a
> few words.
>
OK

>
>> Section 3:
>>
>> This section confuses me. I find no motivation for use beyond the two
>> use-
>> cases.
>>
>> It seems to be a list of two use-cases, I assume these are *examples* of
>> use, rather than required use-cases to consider?
>>
>> It speaks of DCTCP (which I think is currently only defined for
>> controlled
>> environments) and Conex (specified for a specific domain).
>
> As discussed during the DCTCP presentation, the mechanis could have more
> wide spread (internet wide) applicability, if done right (sender reaction,
> receiver behavior, ecn semantic, network aqm settings *AND* TCP ECN
> feedback signal).
>
Agree, text saying this would be good.

>> Reiterating (point 1), I'd hoped these were examples, but that the
>> actual
>> WG goal was now to define a general purpose method for feedback.
>> Or is it?
>
> That was our aim, to eventually have a signaling scheme that could carter
> for the mentioned examples (we need to describe them as that), but also
> enabling future algorithms which we don't know about today.
>
>
OK
>
>> Ordering of examples: How much deployment experience do we have  of
>> Conex?
>> I'm not arguing to  remove this use-case, but wonder whether this is
>> best
>> to be placed first in the examples of use?
>
> The ordering was mostly based on what has been done in IETF so far; Conex
> received much more formal attention than DCTCP so far; alternatively, I
> could claim that the list was done alphabetically to make clear that the
> order of these doesn't have any more significance... :) (but that isn't
> really how the order happened to end up)
>
OK - I may not have noted this if the section said here are 3 example use
cases, Conex, DTCP, and a future ti be defined IETF mechanisms for the
general Internet.

>
>> Is there an implied use-case of standard TCP and a possible use case of
>> an
>> updated ECN for TCP? - I think this is only hinted.
>
> Definitely, we didn't explicitly mention it though.
>
>
>
>> Section 4:
>>
>> Usage of RFC 2119: Personally, I really do not like use of RFC2119
>> keywords in this way: "This leads to the following requirements, which
>> MUST be discussed for any proposed more accurate ECN feedback scheme:" -
>> Mandating discussion is not helpful.
>
> Slightly reworded.
>
>> (point 2 above): If we have requirements as the title suggests, then I
>> personally would encourage you to list them as requirements using RFC
>> 2119 language - but I don't mind seeing no RFC 2119 keywords if the WG
>> wants this, as long as I can see the relative importance of each topic.
>> At the moment I can't see this.
>
> We definitely need more WG discussion around this, and also around the
> importance of each aspect of the various requirements. I'm trying to do
> something along those lines, in the next version to allow comparison.
>
>
>> Comments on specific topics:
>>
>> Resilience
>>
>> "Moreover, delayed ACK are mostly used with TCP.  That means in most
>> cases
>> only every second data packets triggers an ACK."
>> - Isn't it one ACK for every 2 full-sized MSS of data? The ACK rate per
>> segment can be much less if the sender disables the Nagle algorithm. I'd
>> really like a requirement that this mechanism is robust for use with
>> "thin" streams that disable Nagle - and to understand what this means,
>> and
>> if we simply require interop in this case, or whether we require Acc ECN
>> to work accurately.
>
> My recollection of both Linux and BSD stacks is, that they actually
> operate on every other data segment, not when MSS+1 bytes are received.
> Checking - Yupp, looks that way still in freebsd :) This is more
> restrictive than RFC1122 / 4.2.3.2 though, which allows what you state.
>
And sending one ACK every other segment may be good for this proposed
mechanism --- but then what happens if you have a receiver that uses the
definition in the RFC-series…. should this new mechanism *always* at least
ACK every other segment when using AccECN or what is required/recommended?

>
>> - Some reference is probably needed to explain the variety of TCP ACK
>> mangling - e.g. RFC 3449 illustrates at the least the breadth of
>> mechanisms out there.
>>
>> "Also, a more accurate feedback protocol should still work if delayed
>> ACKs
>> covered more than two packets."
>> - In IETF understanding is this really a "should" - I see it is lower
>> case, but it is best not to be ambiguous? does this mean it may not
>> work,
>> or may not be accurate or may cause the TCP receiver to reset (I hope
>> not)?
>
> I think the phrase to tighten here is "should still work" to mean "should
> still provide more accurate feedback then classic ECN ...", right?
>
That works or me, require a specific receiver behaviour.
>
>
>> - Is this resilience to loss?
>
> Correct. Apparently we are missing an initial sentence here.
>
OK
>
>> - Are there implied ordering requirements for the path? - i.e. I'd
>> assume
>> we want a system that does is not impacted by reordering of ACKs, even
>> when the ACK'ed sequence number does not increase, or do we assume an
>> ordered path?
>
> Good catch; the (my) implied assumption was that the ECN signal is
> interpreted *after* the segment acceptance check. For pure ACKs that
> means, unordered ACKs are not processed;
>
>
>> - I think it worth also noting a  *separate topic* for the need for
>> robustness to known middle boxes as a desirable feature? ... I think
>> this is
>> added in "Backward and forward compatibility" - to me such a section is
>> usually expect to see as a protocol evolution issue, rather than a
>> middle
>> box issue.
>>
>> Timeliness
>>
>> "A CE mark can be induced by a network node on the transmission path and
>> is then echoed by the receiver in the TCP ACK. "
>> - I think CE can also be set by the sending host, please update.
>
> Will do.
>
OK

>> "Thus when this information arrives at the sender, it is naturally
>> already
>> about one RTT old."
>> - not really, it is at least 1/2 RTT old - depending on where loss was
>> encountered.
>
> Well, if we want to have acute precise wording, would that sound better:
> "about one backward plus a fraction of the forward delay old"? The
> backward delay can be vastly different from the forward delay (asymmetric
> satellite links with ground return link), thus 1/2 RTT is as skewed as
> saying about one RTT...
>
>
Indeed, this is much better (is "return path" better then "backward").

>> "A RFC5681 TCP sender without ConEx:"
>>   ^^
>> /A/An/ - is it better
>>
>
> Thanks,
>
>
>> Integrity
>> - This starts "it should be possible" and later mentions requirements,
>> is
>> this "a sender SHOULD implement..." (required) or "senders MAY implement
>> ..."
>> (can) or "a SENDER should implement and MAY enable"
>> (required feature, optional deployment) - please clarify and avoid
>> possible, etc.
>>
>> "Whether a sender should enforce when it detects wrong feedback
>> information, and what kind of enforcement it should apply, are policy
>> issues that need not be specified as part of more accurate ECN feedback
>> scheme."
>> - To me this seems like a clear recommendation not to do this - are
>> these
>> really policy decisions, are you saying that the IETF doesn't need to do
>> this. I am not sure I agree, if the sender state machine can detect and
>> react to bogus feedback this maybe should be considered, and I think it
>> would be desirable to know that such mechanisms can be used with any
>> selected approach.
>
> The exact reaction was also left out of RFC3540, unfortunately. This
> document focuses on the requirements of the signaling protocol, whereas
> the policy would be enforced by e.g. a congestion control algorithm.
>
I wonder what we should do here?

>>
>> - If there is policy, be clear what sort of policy - per stack, per
>> socket, per interface, per provisioning domain...
>
> I would lead to a per stack granularity, ie. limiting cwnd, reacting
> overly conservatively to loss, etc. I think this discussion would belong
> in a CC-draft, that makes use of the signals coming out of a more accurate
> ECN feedback scheme. We could perhaps define these signals in the
> requirements draft though.
>
I think hetting agreement in this draft saves discussion later (if we do
happen to make a mistake, ewe can correct this - but if we have WG
agreement on this sort of thing, it can make the next step easier).
>>
>> Accuracy
>>
>> "However, assuming the sender marks all data packets as ECN-capable and
>> uses the default setting of ECT(0),"
>> This may just be wording: - Is use of only ECT(0) assumed somewhere in
>> the
>> RFC series, (mate in PCN?) ? RFC 4774 is a BCP specifies different
>> semantics can be used for the two ECT code points for a different DSCP,
>> to
>> me this indicates that transports should at least be robust to this, and
>> I'd expect that TCP could be used in this case. Is this a requirement?
>> (I
>> think it should be).
>
> RFC3168 states: "When only one ECT codepoint
>    is needed by a sender for all packets sent on a TCP connection,
>    ECT(0) SHOULD be used."
>
>
> The point this paragraph tries to make is, that as the sender does know
> which packets get sent with non-ECT, ECT(0), ECT(1) and CE, if one of
> ECT(0) or ECT(1) is the default, the receiver needs only reflect the other
> two so that the sender can make accurate accounting in what state the ECT
> segments were received... So, a scheme could swap ECT(0)/ECT(1) here.
> However, having yet-different semantics between ECT(0) and ECT(1) would be
> detrimental to the case of breaking the linkage of CE mark == loss.
>
> I added the reference to 3168 here, though.
>
>
I think you argue ECT(1) and CE feedback are sufficient, if so, I'd agree.
>
>
>
>
>> The clause  continues to say feedback of CE and ECT(1) is sufficient.
>> So wouldn't this also be the case if both ECT(0) and ECT(1) were used?
>> i.e. maybe it works fine for other DSCP semantics, by feeding back CE
>> and
>> ECT(1). Please clarify.
>
> I try again: We have some known entities at the sender #total = (# ECT0 +
> # ECT1 + # CE) segments sent; in order to deduce these three values at the
> receiver side, the signal must convey at least two back to the sender,
> which can then calculate the third of the set locally.
>
> How about:
>
>           As the sender can keep account of the transmitted segments
>           with any of the three ECN codepoints, conveying any two
>           of these back to the sender is sufficient for it to
>           reconstruct the third as observed by the receiver.
>
>
/As/Because/ and that would be very clear.
>
>> Complexity:
>>
>> Maybe this is in the wrong section: "Furthermore, the receiver should
>> not
>> make assumptions about the mechanism that was used to set the markings
>> nor
>> about any interpretation or reaction to the congestion signal. The
>> receiver only needs to faithfully reflect congestion information back to
>> the sender."
>> - This does not seem like a complexity requirement to me. It seems like
>> an
>> actual requirement. I'd have expected stronger language against the
>> network not interpreting the meaning of the reaction. Could this be
>> "MUST
>> NOT"? (maybe needs to be in a middle box section).
>
> Moved.
>
>> Backward and forward compatibility
>>
>> /it should to be/it should be/
>>
>> Middleboxes (see earlier)
>>
>> "A more accurate ECN feedback extension should aim to be able to
>> traverse
>> most existing middleboxes."
>> - should ... aim .. most ... existing ... This seems full of questions:
>> Why not
>> "should aim to traverse most middle boxes"? ... but see note above, is
>> this
>> really backwards compatibility?
>>
>> I'd love to see more here that motivates why the methods in "draft-
>> kuehlewind-tcpm-ecn-fallback" need to be considered. I think this it is
>> really important that any ECN method works through commonly deployed
>> middle boxes and also that there are at least tools to verify that this
>> working is correct, even if we do not directly mandate methods to probe
>> and validate the path (which I also think we should seriously consider).
>>
>> I have found a  separate section on middle boxes that uses the words
>> "firewall and NAT" is generally helpful to ensure that people from the
>> community actually find advice and know it is directed to them. If they
>> don't like these requirements they should tell us before we do the work.
>
>
> I've places these keywords in the relevant paragraph, so that a grep spots
> them...
>
Thanks
>
>>
>> Section 5:
>>
>> "In case of " - insert "the"
>>
>> "highly vulnerable to ACK loss." - how is this different to being simply
>> vulnerable? - can you explain "highly"?
>>
>> "still highly ambiguous" - as above, it seems ambiguous?
>>
>> "A couple of coding schemes"
>> - is this a couple as in a linked set or as in two, please clarify
>> language.
>>
>> "Urgent Pointer field" - please refer to the recent TCPM RFC on use of
>> URG.
>
> Added reference to rfc6093.
>
>> "but still not ideal." - I don't see ideal as a goal, consider
>> rewording?
>>
>> I found the last para of 5.1 is a hard read, unless the reader knows
>> what
>> is being said already.
>
>
> Which may be a good thing :) Will try to get this paragraph split and
> straightened.
>
>> Sect 5.2:
>>
>> "Alternatively, the receiver could use bits in the Urgent Pointer field
>> to
>> signal more bits of its congestion signal counter, but only whenever it
>> does not set the Urgent Flag."
>> - I'd urge rewording this, far too often I see sentences from RFCs
>> replicated in other places. In place of this can we say that this is NOT
>> permitted, but a new method could standardise use of these bits...
>
> Reworked.
>
>
>> Sect 5.3:
>>
>> "and SCTP counts the number" - probably this needs to be cited as a
>> "proposal", since this draft has not to date been progressed.
>>
>> "this option would need to be carried by most or all ACKs" - can you
>> explain why? even in times of non-congestion?
>>
>> Sect 8
>>
>> I would expect to see some discussion that states that ECN feedback
>> should
>> only be used if the other information indicates the congestion was
>> on-path
>> - i.e. feedback MUST use normal TCP sequence number check techniques to
>> verify the CE-marked packet was a part of the current flow, and
>> similarly
>> ECN marking feedback is only accepted on valid ACKs.
>>
>> I'd really like this section to point to the mechanisms that may be used
>> to validate that the remote endpoint responds appropriately to ECN. It
>> is
>> relatively easy to do sender-side changes, but knowing the receiver
>> "correctly" implements a function is much harder.
>>
>>
>> I am happy to review again, this is heading in a good direction.
>>
>
>
> Lot's of good feedback, thank you very much !
>
> Richard Scheffenegger
>

Gorry


From nobody Sun Mar  9 04:02:35 2014
Return-Path: <michael.scharf@alcatel-lucent.com>
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 80F4E1A0365 for <tcpm@ietfa.amsl.com>; Sun,  9 Mar 2014 04:02:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjAsDf1wRrge for <tcpm@ietfa.amsl.com>; Sun,  9 Mar 2014 04:02:31 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2DB1A0344 for <tcpm@ietf.org>; Sun,  9 Mar 2014 04:02:31 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s29B2Ht1017618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 9 Mar 2014 06:02:18 -0500 (CDT)
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 s29B2GIg006200 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 9 Mar 2014 12:02:16 +0100
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Sun, 9 Mar 2014 12:02:16 +0100
From: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
To: Bob Briscoe <bob.briscoe@bt.com>, "EGGERT, Lars" <lars@netapp.com>, "Martin Stiemerling" <mls.ietf@gmail.com>
Thread-Topic: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
Thread-Index: AQHPOUvqB4asL+n33EKUOkCrobK2g5rYk5GA
Date: Sun, 9 Mar 2014 11:02:15 +0000
Message-ID: <655C07320163294895BBADA28372AF5D213359@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References: <201403061451.s26Epwcq006941@bagheera.jungle.bt.co.uk>
In-Reply-To: <201403061451.s26Epwcq006941@bagheera.jungle.bt.co.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.39]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/4G4Egal0ahbzYSVvJJUfoJoTj2Y
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Mar 2014 11:02:33 -0000

Hi Bob,

I think we should encourage that implementers document widely deployed TCP =
mechanism in the RFC series, if they are willing to discuss with the IETF a=
nd improve document clarity so that the document is a good, informational d=
escription that can be used as reference. (This thought is actually indepen=
dent of DCTCP.)

If implementers are responsive to questions, such informational documentati=
on (possible as AD-sponsored document) should actually be possible rather q=
uickly. This almost likely implies that the RFC documents a mechanism that =
is still in use at the time of publication. To me, this is not "historic".

I could imagine that a Proposed Standard produced by the IETF changes the s=
tatus to "Historic" at a later stage. But even then I'd ask whether the Pro=
posed Standard indeed describes what is deployed, or will be deployed, at l=
arge scale in the Internet.

Thanks

Michael (as individual contributor)



> -----Original Message-----
> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe
> Sent: Thursday, March 06, 2014 3:52 PM
> To: EGGERT, Lars; Martin Stiemerling
> Cc: tcpm IETF list
> Subject: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
>=20
> Lars,
>=20
> Everyone seems to agree this should be independent stream. That
> leaves the question of intended status...
>=20
> Imagine Microsoft now updates DCTCP to fix the feedback flaw. Then do
> you want to update this draft? I doubt it.
>=20
> So, IMO if you wanted to only document what Microsoft did, even tho
> it was  broken, then this should be HISTORIC, not INFORMATIONAL.
>=20
> If it's INFORMATIONAL it should at least fix known major problems
> before it is published.
>=20
>=20
>=20
> Bob
>=20
>=20
>=20
> ________________________________________________________________
> Bob Briscoe,                                                  BT
>=20
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


From nobody Sun Mar  9 04:31:29 2014
Return-Path: <rs@netapp.com>
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 6BFD31A01CC for <tcpm@ietfa.amsl.com>; Sun,  9 Mar 2014 04:31:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-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 R7FvxpXo2sCq for <tcpm@ietfa.amsl.com>; Sun,  9 Mar 2014 04:31:25 -0700 (PDT)
Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8971A017B for <tcpm@ietf.org>; Sun,  9 Mar 2014 04:31:25 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.97,618,1389772800"; d="scan'208";a="107893865"
Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx11-out.netapp.com with ESMTP; 09 Mar 2014 04:31:20 -0700
Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Sun, 9 Mar 2014 04:31:19 -0700
From: "Scheffenegger, Richard" <rs@netapp.com>
To: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>
Thread-Topic: [tcpm] Some comments on: draft-kuehlewind-tcpm-accecn-reqs
Thread-Index: AQHPOrvPnnC2Yencfk2wJMba8ybB+prXXZjwgAGE2oD//7E24A==
Date: Sun, 9 Mar 2014 11:31:19 +0000
Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F260D8120@SACEXCMBX02-PRD.hq.netapp.com>
References: <531AF534.6050209@erg.abdn.ac.uk> <012C3117EDDB3C4781FD802A8C27DD4F260D7F08@SACEXCMBX02-PRD.hq.netapp.com> <42bc59eb086542a1e28c435527a85ed5.squirrel@www.erg.abdn.ac.uk>
In-Reply-To: <42bc59eb086542a1e28c435527a85ed5.squirrel@www.erg.abdn.ac.uk>
Accept-Language: de-AT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.122.105.27]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/jqVmdUDoHTBSvRhgS2gzSWlmGp0
Cc: "draft-kuehlewind-tcpm-accecn-reqs@tools.ietf.org" <draft-kuehlewind-tcpm-accecn-reqs@tools.ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>, Brian Trammell <trammell@tik.ee.ethz.ch>
Subject: Re: [tcpm] Some comments on: draft-kuehlewind-tcpm-accecn-reqs
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Mar 2014 11:31:27 -0000

Hi Gorry,

Pruning for clarity -

>>> Comments on specific topics:
>>>
>>> Resilience
>>>
>>> "Moreover, delayed ACK are mostly used with TCP.  That means in most
>>> cases only every second data packets triggers an ACK."
>>> - Isn't it one ACK for every 2 full-sized MSS of data? The ACK rate
>>> per segment can be much less if the sender disables the Nagle
>>> algorithm. I'd really like a requirement that this mechanism is
>>> robust for use with "thin" streams that disable Nagle - and to
>>> understand what this means, and if we simply require interop in this
>>> case, or whether we require Acc ECN to work accurately.
>>
>> My recollection of both Linux and BSD stacks is, that they actually
>> operate on every other data segment, not when MSS+1 bytes are received.
>> Checking - Yupp, looks that way still in freebsd :) This is more
>> restrictive than RFC1122 / 4.2.3.2 though, which allows what you state.
>>
> And sending one ACK every other segment may be good for this proposed
> mechanism --- but then what happens if you have a receiver that uses the
> definition in the RFC-series.... should this new mechanism *always* at le=
ast
> ACK every other segment when using AccECN or what is required/recommended=
?

We tried to be sufficiently vague on the extent of delayed ACKs, but to mak=
e it a requirement of the feedback mechanism to cater for theses delayed AC=
Ks under both, 1) heavy congestion marking, and 2) heavy ACK loss.

However, to the 2nd aspect there are some natural limits; if too many ACKs =
get lost, the TCP ACK clock would break down and other aspects of TCP would=
 step in (RTO, SS, [TLP]...). During our simulations done some time ago, we=
 figured that covering a worst-case stretch of around 20-40 (IIRC) lost ack=
s - each with potentially updated ECN information -  should be sufficient, =
before those mechanisms react. (We looked at this most closely with the Acc=
ECN codepoint design; the three available bits don't suffice to deal with t=
he most extreme circumstances, but are sufficient for all typical cases wit=
h mild ACK loss, and medium congestion marking. Thus the opportunistic sign=
al which may or may not be available, to cover all conceivable circumstance=
s)=20

I think my point is, that as this is a requirements document, we don't need=
 to rat-hole yet on the specifics of how one signaling mechanism carters fo=
r all that ACK mangling, as that will also depend how the signaling will be=
 done. I'd argue that the text in this space should be enough to motivate a=
 thorough look at the design choices in the feedback mechanism.




>>> Integrity
>>> - This starts "it should be possible" and later mentions
>>> requirements, is this "a sender SHOULD implement..." (required) or
>>> "senders MAY implement ..."
>>> (can) or "a SENDER should implement and MAY enable"
>>> (required feature, optional deployment) - please clarify and avoid
>>> possible, etc.
>>>
>>> "Whether a sender should enforce when it detects wrong feedback
>>> information, and what kind of enforcement it should apply, are policy
>>> issues that need not be specified as part of more accurate ECN
>>> feedback scheme."
>>> - To me this seems like a clear recommendation not to do this - are
>>> these really policy decisions, are you saying that the IETF doesn't
>>> need to do this. I am not sure I agree, if the sender state machine
>>> can detect and react to bogus feedback this maybe should be
>>> considered, and I think it would be desirable to know that such
>>> mechanisms can be used with any selected approach.
>>
>> The exact reaction was also left out of RFC3540, unfortunately. This
>> document focuses on the requirements of the signaling protocol,
>> whereas the policy would be enforced by e.g. a congestion control
>algorithm.
>
> I wonder what we should do here?

I tend to think this in black boxes; the accurate ECN feedback mechanism be=
ing one, it could have defined outputs, like "integrity of signal ok", "int=
egrity is dubious/lost"; same with the reliability - there are circumstance=
s, where the feedback signal can become ambiguous -- ie. with classic ECN, =
as soon as the window is > 1 packet, the sender will have to suspect that m=
ore than 1 CE was seen by the receiver; with any of the counter (in some fo=
rm) schemes, that counter might have overflown unnoticed. Thus the feedback=
 mechanism would provide something like "feedback reliable (since last chan=
ge)", "feedback unreliable". In the signaling scheme we could then RECOMMEN=
D what a TCP congestion control (or other aspect) SHOULD be doing when that=
 side-band signal is output from the signaling mechanism... Of course, the =
aim of a more accurate ECN feedback scheme MUST be to minimize the times wh=
en "feedback unreliable" happens.

But currently we are discussing a requirements document - so if that approa=
ch with providing not only an output of the congestion extent, but also add=
itional side-information appeals to the WG, we could put into the requireme=
nts, that a certain set of such side-channel information should be provided=
 by the feedback mechanism.


>>> - If there is policy, be clear what sort of policy - per stack, per
>>> socket, per interface, per provisioning domain...
>>
>> I would lead to a per stack granularity, ie. limiting cwnd, reacting
>> overly conservatively to loss, etc. I think this discussion would
>> belong in a CC-draft, that makes use of the signals coming out of a
>> more accurate ECN feedback scheme. We could perhaps define these
>> signals in the requirements draft though.
>
> I think getting agreement in this draft saves discussion later (if we do
> happen to make a mistake, we can correct this - but if we have WG
> agreement on this sort of thing, it can make the next step easier).


Certainly.=20


>>> Accuracy
>>>
>>
>> The point this paragraph tries to make is, that as the sender does
>> know which packets get sent with non-ECT, ECT(0), ECT(1) and CE, if
>> one of
>> ECT(0) or ECT(1) is the default, the receiver needs only reflect the
>> other two so that the sender can make accurate accounting in what
>> state the ECT segments were received... So, a scheme could swap
>> ECT(0)/ECT(1) here.
>> However, having yet-different semantics between ECT(0) and ECT(1)
>> would be detrimental to the case of breaking the linkage of CE mark =3D=
=3D
>> loss.
>>
>> I added the reference to 3168 here, though.
>
> I think you argue ECT(1) and CE feedback are sufficient, if so, I'd agree=
.
>
[..]
>> How about:
>>
>>           As the sender can keep account of the transmitted segments
>>           with any of the three ECN codepoints, conveying any two
>>           of these back to the sender is sufficient for it to
>>           reconstruct the third as observed by the receiver.
>>
>>
> /As/Because/ and that would be very clear.


Done.

Best regards,
  Richard


From nobody Sun Mar  9 08:46:11 2014
Return-Path: <gorry@erg.abdn.ac.uk>
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 59F911A0278 for <tcpm@ietfa.amsl.com>; Sun,  9 Mar 2014 08:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 exf0gAcDHBeB for <tcpm@ietfa.amsl.com>; Sun,  9 Mar 2014 08:46:07 -0700 (PDT)
Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8132C1A0268 for <tcpm@ietf.org>; Sun,  9 Mar 2014 08:46:07 -0700 (PDT)
Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 12AFC2B40E7; Sun,  9 Mar 2014 15:46:01 +0000 (GMT)
Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Sun, 9 Mar 2014 15:46:01 -0000
Message-ID: <d5b1ee4ef5a1b2c506f1c7d706ae913c.squirrel@www.erg.abdn.ac.uk>
In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F260D8120@SACEXCMBX02-PRD.hq.netapp.com>
References: <531AF534.6050209@erg.abdn.ac.uk> <012C3117EDDB3C4781FD802A8C27DD4F260D7F08@SACEXCMBX02-PRD.hq.netapp.com> <42bc59eb086542a1e28c435527a85ed5.squirrel@www.erg.abdn.ac.uk> <012C3117EDDB3C4781FD802A8C27DD4F260D8120@SACEXCMBX02-PRD.hq.netapp.com>
Date: Sun, 9 Mar 2014 15:46:01 -0000
From: gorry@erg.abdn.ac.uk
To: "Scheffenegger, Richard" <rs@netapp.com>
User-Agent: SquirrelMail/1.4.22
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/vyKyyoctZOa9FJj5uk29ffxURjc
Cc: "draft-kuehlewind-tcpm-accecn-reqs@tools.ietf.org" <draft-kuehlewind-tcpm-accecn-reqs@tools.ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>, Brian Trammell <trammell@tik.ee.ethz.ch>
Subject: Re: [tcpm] Some comments on: draft-kuehlewind-tcpm-accecn-reqs
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Mar 2014 15:46:10 -0000

> Hi Gorry,
>
> Pruning for clarity -
>
Sure, comments below.

>>>> Comments on specific topics:
>>>>
>>>> Resilience
>>>>
>>>> "Moreover, delayed ACK are mostly used with TCP.  That means in most
>>>> cases only every second data packets triggers an ACK."
>>>> - Isn't it one ACK for every 2 full-sized MSS of data? The ACK rate
>>>> per segment can be much less if the sender disables the Nagle
>>>> algorithm. I'd really like a requirement that this mechanism is
>>>> robust for use with "thin" streams that disable Nagle - and to
>>>> understand what this means, and if we simply require interop in this
>>>> case, or whether we require Acc ECN to work accurately.
>>>
>>> My recollection of both Linux and BSD stacks is, that they actually
>>> operate on every other data segment, not when MSS+1 bytes are received.
>>> Checking - Yupp, looks that way still in freebsd :) This is more
>>> restrictive than RFC1122 / 4.2.3.2 though, which allows what you state.
>>>
>> And sending one ACK every other segment may be good for this proposed
>> mechanism --- but then what happens if you have a receiver that uses the
>> definition in the RFC-series.... should this new mechanism *always* at
>> least
>> ACK every other segment when using AccECN or what is
>> required/recommended?
>
> We tried to be sufficiently vague on the extent of delayed ACKs, but to
> make it a requirement of the feedback mechanism to cater for theses
> delayed ACKs under both, 1) heavy congestion marking, and 2) heavy ACK
> loss.
>
> However, to the 2nd aspect there are some natural limits; if too many ACKs
> get lost, the TCP ACK clock would break down and other aspects of TCP
> would step in (RTO, SS, [TLP]...). During our simulations done some time
> ago, we figured that covering a worst-case stretch of around 20-40 (IIRC)
> lost acks - each with potentially updated ECN information -  should be
> sufficient, before those mechanisms react. (We looked at this most closely
> with the AccECN codepoint design; the three available bits don't suffice
> to deal with the most extreme circumstances, but are sufficient for all
> typical cases with mild ACK loss, and medium congestion marking. Thus the
> opportunistic signal which may or may not be available, to cover all
> conceivable circumstances)
>
> I think my point is, that as this is a requirements document, we don't
> need to rat-hole yet on the specifics of how one signaling mechanism
> carters for all that ACK mangling, as that will also depend how the
> signaling will be done. I'd argue that the text in this space should be
> enough to motivate a thorough look at the design choices in the feedback
> mechanism.
>
I think we need to call out the issue, and say what it is, and then what
is required… e.g. MUST (needs) to provide reliable TCP operation with
arbitrary ACK sequences, as permitted by TCP, but does not need to
optimise ECN processing in these cases. Implementors need to say how this
is addressed in any proposal -- or something along these lines.


>>>> Integrity
>>>> - This starts "it should be possible" and later mentions
>>>> requirements, is this "a sender SHOULD implement..." (required) or
>>>> "senders MAY implement ..."
>>>> (can) or "a SENDER should implement and MAY enable"
>>>> (required feature, optional deployment) - please clarify and avoid
>>>> possible, etc.
>>>>
>>>> "Whether a sender should enforce when it detects wrong feedback
>>>> information, and what kind of enforcement it should apply, are policy
>>>> issues that need not be specified as part of more accurate ECN
>>>> feedback scheme."
>>>> - To me this seems like a clear recommendation not to do this - are
>>>> these really policy decisions, are you saying that the IETF doesn't
>>>> need to do this. I am not sure I agree, if the sender state machine
>>>> can detect and react to bogus feedback this maybe should be
>>>> considered, and I think it would be desirable to know that such
>>>> mechanisms can be used with any selected approach.
>>>
>>> The exact reaction was also left out of RFC3540, unfortunately. This
>>> document focuses on the requirements of the signaling protocol,
>>> whereas the policy would be enforced by e.g. a congestion control
>>algorithm.
>>
>> I wonder what we should do here?
>
> I tend to think this in black boxes; the accurate ECN feedback mechanism
> being one, it could have defined outputs, like "integrity of signal ok",
> "integrity is dubious/lost"; same with the reliability - there are
> circumstances, where the feedback signal can become ambiguous -- ie. with
> classic ECN, as soon as the window is > 1 packet, the sender will have to
> suspect that more than 1 CE was seen by the receiver; with any of the
> counter (in some form) schemes, that counter might have overflown
> unnoticed. Thus the feedback mechanism would provide something like
> "feedback reliable (since last change)", "feedback unreliable". In the
> signaling scheme we could then RECOMMEND what a TCP congestion control (or
> other aspect) SHOULD be doing when that side-band signal is output from
> the signaling mechanism... Of course, the aim of a more accurate ECN
> feedback scheme MUST be to minimize the times when "feedback unreliable"
> happens.
>
> But currently we are discussing a requirements document - so if that
> approach with providing not only an output of the congestion extent, but
> also additional side-information appeals to the WG, we could put into the
> requirements, that a certain set of such side-channel information should
> be provided by the feedback mechanism.
>
The text could require proposals to describe how they can support
detection of reliable feedback of ECN information, e.g. by allowing a
sender to inject CE marks to perform a test.

Or it could require that they provide a method that does allows this -
which ( I favour requiring the method allows this to be done by the
corresponding CC.)

>
>>>> - If there is policy, be clear what sort of policy - per stack, per
>>>> socket, per interface, per provisioning domain...
>>>
>>> I would lead to a per stack granularity, ie. limiting cwnd, reacting
>>> overly conservatively to loss, etc. I think this discussion would
>>> belong in a CC-draft, that makes use of the signals coming out of a
>>> more accurate ECN feedback scheme. We could perhaps define these
>>> signals in the requirements draft though.
>>
>> I think getting agreement in this draft saves discussion later (if we do
>> happen to make a mistake, we can correct this - but if we have WG
>> agreement on this sort of thing, it can make the next step easier).
>
>
> Certainly.
>
>
>>>> Accuracy
>>>>
>>>
>>> The point this paragraph tries to make is, that as the sender does
>>> know which packets get sent with non-ECT, ECT(0), ECT(1) and CE, if
>>> one of
>>> ECT(0) or ECT(1) is the default, the receiver needs only reflect the
>>> other two so that the sender can make accurate accounting in what
>>> state the ECT segments were received... So, a scheme could swap
>>> ECT(0)/ECT(1) here.
>>> However, having yet-different semantics between ECT(0) and ECT(1)
>>> would be detrimental to the case of breaking the linkage of CE mark ==
>>> loss.
>>>
>>> I added the reference to 3168 here, though.
>>
>> I think you argue ECT(1) and CE feedback are sufficient, if so, I'd
>> agree.
>>
> [..]
>>> How about:
>>>
>>>           As the sender can keep account of the transmitted segments
>>>           with any of the three ECN codepoints, conveying any two
>>>           of these back to the sender is sufficient for it to
>>>           reconstruct the third as observed by the receiver.
>>>
>>>
>> /As/Because/ and that would be very clear.
>
>
> Done.
>
> Best regards,
>   Richard
>

Hope this helped.

Gorry



From nobody Mon Mar 10 02:28:23 2014
Return-Path: <gorry@erg.abdn.ac.uk>
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 C3C421A040B for <tcpm@ietfa.amsl.com>; Mon, 10 Mar 2014 02:28:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 XCU09PvBfBRT for <tcpm@ietfa.amsl.com>; Mon, 10 Mar 2014 02:28:19 -0700 (PDT)
Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 82BBD1A03FD for <tcpm@ietf.org>; Mon, 10 Mar 2014 02:28:19 -0700 (PDT)
Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id B15822B452F; Mon, 10 Mar 2014 09:28:13 +0000 (GMT)
Received: from ERG-research.local (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 1B5D82B44D1; Mon, 10 Mar 2014 09:28:11 +0000 (GMT)
Message-ID: <531D85A6.3020807@erg.abdn.ac.uk>
Date: Mon, 10 Mar 2014 09:28:06 +0000
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
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:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>,  Bob Briscoe <bob.briscoe@bt.com>, "EGGERT, Lars" <lars@netapp.com>,  Martin Stiemerling <mls.ietf@gmail.com>
References: <201403061451.s26Epwcq006941@bagheera.jungle.bt.co.uk> <655C07320163294895BBADA28372AF5D213359@FR712WXCHMBA15.zeu.alcatel-lucent.com>
In-Reply-To: <655C07320163294895BBADA28372AF5D213359@FR712WXCHMBA15.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/qd-fWP-VLLQ94gg8XhWyAyYxog4
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
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 <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Mar 2014 09:28:22 -0000

This seems sensible to me, get WG comments feedback for an individual 
submission (via AD) and propose as INFO. If there is feedback by the 
authors they want it to be HISTORIC, that would be OK also.

To me, it would need careful crafting of the abstract to explain the 
current position with respect to other work in this area.

Gorry

On 09/03/2014 11:02, Scharf, Michael (Michael) wrote:
> Hi Bob,
>
> I think we should encourage that implementers document widely deployed TCP mechanism in the RFC series, if they are willing to discuss with the IETF and improve document clarity so that the document is a good, informational description that can be used as reference. (This thought is actually independent of DCTCP.)
>
> If implementers are responsive to questions, such informational documentation (possible as AD-sponsored document) should actually be possible rather quickly. This almost likely implies that the RFC documents a mechanism that is still in use at the time of publication. To me, this is not "historic".
>
> I could imagine that a Proposed Standard produced by the IETF changes the status to "Historic" at a later stage. But even then I'd ask whether the Proposed Standard indeed describes what is deployed, or will be deployed, at large scale in the Internet.
>
> Thanks
>
> Michael (as individual contributor)
>
>
>
>> -----Original Message-----
>> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe
>> Sent: Thursday, March 06, 2014 3:52 PM
>> To: EGGERT, Lars; Martin Stiemerling
>> Cc: tcpm IETF list
>> Subject: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
>>
>> Lars,
>>
>> Everyone seems to agree this should be independent stream. That
>> leaves the question of intended status...
>>
>> Imagine Microsoft now updates DCTCP to fix the feedback flaw. Then do
>> you want to update this draft? I doubt it.
>>
>> So, IMO if you wanted to only document what Microsoft did, even tho
>> it was  broken, then this should be HISTORIC, not INFORMATIONAL.
>>
>> If it's INFORMATIONAL it should at least fix known major problems
>> before it is published.
>>
>>
>>
>> Bob
>>
>>
>>
>> ________________________________________________________________
>> Bob Briscoe,                                                  BT
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>


From nobody Mon Mar 10 03:20:11 2014
Return-Path: <rs@netapp.com>
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 794401A0424 for <tcpm@ietfa.amsl.com>; Mon, 10 Mar 2014 03:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.448
X-Spam-Level: 
X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-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 MMy2Wu7lN-gb for <tcpm@ietfa.amsl.com>; Mon, 10 Mar 2014 03:20:03 -0700 (PDT)
Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2C51A0417 for <tcpm@ietf.org>; Mon, 10 Mar 2014 03:20:03 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.97,622,1389772800";  d="scan'208,217";a="148763059"
Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx12-out.netapp.com with ESMTP; 10 Mar 2014 03:19:57 -0700
Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Mon, 10 Mar 2014 03:19:56 -0700
From: "Scheffenegger, Richard" <rs@netapp.com>
To: "tcpm (tcpm@ietf.org)" <tcpm@ietf.org>
Thread-Topic: ECN re-survey
Thread-Index: Ac88SORC5997uwUqRqC3L1AkwtJSrg==
Date: Mon, 10 Mar 2014 10:19:56 +0000
Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F260D85FA@SACEXCMBX02-PRD.hq.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.105.27]
Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F260D85FASACEXCMBX02PRDh_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Mtoi8c7TrEZqQFU9UtWtVQSQ9i8
Subject: [tcpm] ECN re-survey
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Mar 2014 10:20:08 -0000

--_000_012C3117EDDB3C4781FD802A8C27DD4F260D85FASACEXCMBX02PRDh_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

anyone interested in re-visiting and evaluating the data collection about E=
CN prevalence and support? [1]

My first go indicates, that today the server-side support of ECN is up from=
 ~30% (Aug 2012) to 40% (Mar 2014) - the top 20k alexa sites sampled so far=
.

But the more interesting aspect, which wasn't mentioned in [1] is that in p=
articular the larger sites apparently are more likely to have broken web-fr=
ont end load balancing servers / proxys / gateways...

The observed behavior matches what RFC3168 describes as broken TCP stacks, =
simply reflecting all unknown TCP options (which is why ECN TCP negotiation=
 is <SYN,ECE,CWR> / <SYN,ACK,ECE>).

My initial thought is that some large vendor of such load balancers - affor=
dable only by large scale sites, most notably one former behemoth which is =
currently struggling a bit - has a flawed TCP implementation. Perhaps someo=
ne wants to help me identify the vendor, to get that invalid TCP behavior r=
ectified?

The farther down in the alexa list the sampling (thus, ever more smaller si=
tes, with less traffic), the higher the prevalence of proper ECN support, a=
nd also fewer and fewer broken TCP stacks are observed...

(For now, I'm only samping TCP ECN on port 80, with the primary motivation =
in AccECN actually).


[1] http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Kue_PAM13_=
40160.pdf

Richard Scheffenegger

NetApp
rs@netapp.com<mailto:rs@netapp.com>
+43 1 3676811 3146 Office (2143 3146 - internal)
+43 676 654 3146 Mobile
www.netapp.com<http://www.netapp.com>

EURO PLAZA
Geb=E4ude G, Stiege 7, 3.OG
Am Euro Platz 2
A-1120 Wien





--_000_012C3117EDDB3C4781FD802A8C27DD4F260D85FASACEXCMBX02PRDh_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
 #800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Calibri" size=3D"2"><span style=3D"font-size:11pt;">
<div>Hi,</div>
<div>&nbsp;</div>
<div>anyone interested in re-visiting and evaluating the data collection ab=
out ECN prevalence and support? [1]</div>
<div>&nbsp;</div>
<div>My first go indicates, that today the server-side support of ECN is up=
 from ~30% (Aug 2012) to 40% (Mar 2014) &#8211; the top 20k alexa sites sam=
pled so far.</div>
<div>&nbsp;</div>
<div>But the more interesting aspect, which wasn&#8217;t mentioned in [1] i=
s that in particular the larger sites apparently are more likely to have br=
oken web-front end load balancing servers / proxys / gateways&#8230;</div>
<div>&nbsp;</div>
<div>The observed behavior matches what RFC3168 describes as broken TCP sta=
cks, simply reflecting all unknown TCP options (which is why ECN TCP negoti=
ation is &lt;SYN,ECE,CWR&gt; / &lt;SYN,ACK,ECE&gt;).</div>
<div>&nbsp;</div>
<div>My initial thought is that some large vendor of such load balancers &#=
8211; affordable only by large scale sites, most notably one former behemot=
h which is currently struggling a bit &#8211; has a flawed TCP implementati=
on. Perhaps someone wants to help me identify
the vendor, to get that invalid TCP behavior rectified?</div>
<div>&nbsp;</div>
<div>The farther down in the alexa list the sampling (thus, ever more small=
er sites, with less traffic), the higher the prevalence of proper ECN suppo=
rt, and also fewer and fewer broken TCP stacks are observed&#8230;</div>
<div>&nbsp;</div>
<div>(For now, I&#8217;m only samping TCP ECN on port 80, with the primary =
motivation in AccECN actually).</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>[1] <a href=3D"http://www.ikr.uni-stuttgart.de/Content/Publications/Ar=
chive/Kue_PAM13_40160.pdf">
http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Kue_PAM13_4016=
0.pdf</a></div>
<div>&nbsp;</div>
<div>Richard Scheffenegger<br>

<br>

<font size=3D"2"><span style=3D"font-size:10pt;">NetApp<br>

</span></font><a href=3D"mailto:rs@netapp.com"><font size=3D"2" color=3D"bl=
ue"><span style=3D"font-size:10pt;"><u>rs@netapp.com</u></span></font></a><=
br>

<font size=3D"2"><span style=3D"font-size:10pt;">&#43;43 1 3676811 3146 Off=
ice (2143 3146 - internal)<br>

&#43;43 676 654 3146 Mobile<br>

</span></font><a href=3D"http://www.netapp.com"><font size=3D"2" color=3D"b=
lue"><span style=3D"font-size:10pt;"><u>www.netapp.com</u></span></font></a=
><font size=3D"2"><span style=3D"font-size:10pt;">&nbsp;&nbsp;<br>

<br>

EURO PLAZA<br>

Geb=E4ude G, Stiege 7, 3.OG<br>

Am Euro Platz 2<br>

A-1120 Wien<br>

</span></font></div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
</span></font>
</body>
</html>

--_000_012C3117EDDB3C4781FD802A8C27DD4F260D85FASACEXCMBX02PRDh_--


From nobody Tue Mar 11 05:19:02 2014
Return-Path: <diego@tid.es>
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 2FE481A068D for <tcpm@ietfa.amsl.com>; Tue, 11 Mar 2014 05:19:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.048
X-Spam-Level: 
X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 D1Fj-st-0dXy for <tcpm@ietfa.amsl.com>; Tue, 11 Mar 2014 05:18:56 -0700 (PDT)
Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 220571A0715 for <tcpm@ietf.org>; Tue, 11 Mar 2014 05:18:56 -0700 (PDT)
Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N2900NM8U7D29@tid.hi.inet> for tcpm@ietf.org; Tue, 11 Mar 2014 13:18:49 +0100 (MET)
Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id B1.0D.03314.92FFE135; Tue, 11 Mar 2014 13:18:49 +0100 (CET)
Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0N2900NM4U7D29@tid.hi.inet> for tcpm@ietf.org; Tue, 11 Mar 2014 13:18:49 +0100 (MET)
Received: from EX10-MB2-MAD.hi.inet ([169.254.2.84]) by EX10-HTCAS7-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Tue, 11 Mar 2014 13:18:49 +0100
Date: Tue, 11 Mar 2014 12:18:49 +0000
From: "Diego R. Lopez" <diego@tid.es>
X-Originating-IP: [10.95.64.115]
To: "tcpm@ietf.org" <tcpm@ietf.org>
Message-id: <FDC308AD-096A-4FB7-AAA1-B6FAA1660F85@tid.es>
Content-id: <A56B848D46A1054090B733BCEA157BDC@hi.inet>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-language: en-US
Content-transfer-encoding: base64
Accept-Language: en-US, es-ES
Thread-topic: Looking for advice on a draft from the PCE working group
Thread-index: AQHPPSQOPWN7uGul1keGON95aVpVwA==
X-AuditID: 0a5f4068-b7fe58e000000cf2-d0-531eff29760c
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsXCFe/Apav5Xy7YYPVyXYttJ+czOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4/f0v2wFM/gqNk37z9LA+IK3i5GTQ0LAROLhr04WCFtM4sK9 9WxdjFwcQgIHGCW+X9/NCuF8Y5TYfP4olDONUWLWjS6wFhYBVYlPF6exg9hsQPaj5t9gtrCA o8SZ50/ZIMYqSPw59xisXkRAWWL1/Q+MIDazgL9E57plrCA2r4ClxP32BUA1HEBxM4nnLUoQ YUGJH5PvQYXVJaZMyYXoFJdobr3JAmErSkxb1AA2kVFAVuLd/PmsEJvcJP4dmc8OYetJ/Pr8 EeoaAYkle84zQ9iiEi8f/2OdwCg2C2HxLCSLZyEsnoVk8Swkixcwsq5iFCtOKspMzyjJTczM STcw1MvI1MvMSy3ZxAiJoIwdjMt3qhxiFOBgVOLhbRCSChZiTSwrrsw9xCjBwawkwnvxnlyw EG9KYmVValF+fFFpTmrxIUYmDk6pBkYDEfnGyg2szwuOXbO5mGBQaVQkuVR7dsMB1e+cdpel GX//6wr9pS/aL9i0MLit85bULzXtl31JASxZByL9JqdcFW2MajvJc0Lr48Yns56+m6TfvNjv 4j/2vfYMW8T4jTVf52XtYjo+k/mr1LOara/ddBN+3IgzVFl4bvdUE4V+XvkS038H85RYijMS DbWYi4oTAQXR71d+AgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/BFjKrds8TT_0OoSGBSywV0TyexA
Cc: "draft-ietf-pce-pceps@tools.ietf.org" <draft-ietf-pce-pceps@tools.ietf.org>
Subject: [tcpm] Looking for advice on a draft from the PCE working group
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Mar 2014 12:19:01 -0000

SGksDQoNClRoZXJlIGlzIGEgZHJhZnQsIHJlY2VudGx5IGFkb3B0ZWQgYnkgdGhlIFBDRSBXRywg
b24gcnVubmluZyB0aGUgUENFUCBwcm90b2NvbCBvbiB0b3Agb2YgVExTLiBEdXJpbmcgdGhlIGRp
c2N1c3Npb24gb2YgdGhpcyBkcmFmdCBzZXZlcmFsIGlzc3VlcyByZWdhcmRpbmcgdHJhbnNwb3J0
IGFzcGVjdHMgd2VyZSByYWlzZWQsIGVzc2VudGlhbGx5IGRlYWxpbmcgd2l0aCB0aGUgdXNhZ2Ug
b2YgVENQIHNlY3VyaXR5IG9wdGlvbnMgYW5kIHdpdGggdGhlIG5lZWQgZm9yIHJlcXVpcmluZyBh
IHNlcGFyYXRlIHBvcnQgZnJvbSB0aGUgInBsYWluIiBQQ0VQLiBUaGUgV0cgZGVjaWRlZCB0byBz
ZWVrIGZvciBhZHZpY2UgZnJvbSB0aGUgdHJhbnNwb3J0IGNvbW11bml0eSBhbmQgdGhlIEFEcyBw
b2ludGVkIG1lIHRvIHRoaXMgbGlzdCBhcyB0aGUgbW9zdCBhcHByb3ByaWF0ZSBwbGFjZSBmb3Ig
c3VjaCBhbiBhZHZpY2UuDQoNCllvdSBoYXZlIHRoZSB0ZXh0IG9mIHRoZSBkcmFmdCBhdmFpbGFi
bGUgdGhyb3VnaCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXBj
ZS1wY2Vwcy8NCg0KQW55IGZlZWRiYWNrIG9uIHRoZSBhYm92ZSBtZW50aW9uZWQgaXNzdWVzIG9y
IGFueXRoaW5nIGVsc2UgeW91IHNlZSBpbiB0aGUgZG9jdW1lbnQgd2lsbCBiZSBleHRyZW1lbHkg
d2VsY29tZS4NCg0KQmUgZ29vZGUsDQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3Rv
ciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwOi8v
cGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8NCg0KZS1tYWlsOiBkaWVnb0B0aWQuZXMNClRlbDog
ICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3Ug
ZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61v
IHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRv
IG3DoXMgYWJham8uDQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0
cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMg
b2YgdGhlIHRlcm1zIHNldCBvdXQgYXQ6DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rp
c2NsYWltZXIuYXNweA0K


From nobody Tue Mar 11 06:37:30 2014
Return-Path: <rs@netapp.com>
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 D03141A0721 for <tcpm@ietfa.amsl.com>; Tue, 11 Mar 2014 06:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.448
X-Spam-Level: 
X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-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 30QstV5w5SvY for <tcpm@ietfa.amsl.com>; Tue, 11 Mar 2014 06:37:25 -0700 (PDT)
Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 73FC91A0674 for <tcpm@ietf.org>; Tue, 11 Mar 2014 06:37:24 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.97,630,1389772800";  d="scan'208,217";a="149115074"
Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 11 Mar 2014 06:37:18 -0700
Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Tue, 11 Mar 2014 06:37:19 -0700
From: "Scheffenegger, Richard" <rs@netapp.com>
To: "draft-bensley-tcpm-dctcp@tools.ietf.org" <draft-bensley-tcpm-dctcp@tools.ietf.org>
Thread-Topic: CWD flag use in DCTCP
Thread-Index: Ac89LGvu60jvlEzrTUC2Lbm6I8rcmQ==
Date: Tue, 11 Mar 2014 13:37:18 +0000
Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F260DD086@SACEXCMBX02-PRD.hq.netapp.com>
Accept-Language: de-AT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.106.53.53]
Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F260DD086SACEXCMBX02PRDh_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/MGXVByQXjGxBfn6r1L3aw5HNBPM
Cc: "tcpm \(tcpm@ietf.org\)" <tcpm@ietf.org>
Subject: [tcpm] CWD flag use in DCTCP
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Mar 2014 13:37:28 -0000

--_000_012C3117EDDB3C4781FD802A8C27DD4F260DD086SACEXCMBX02PRDh_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

Section 2.3 misses out a small, but crucial detail.

When I discussed DCTCP deployments and interoperability with Murari in Prag=
ue (IETF80), he indicated that a DCTCP sender will still send (at least?) o=
ne CWD flag in each window where cwnd was reduced.

However, none of the DCTCP papers mention the handling of the CWD flag, lea=
ving open three potential variants:

a)      CWD is not set when DCTCP is in use
     There is no need towards a DCTCP client, as ECE doesn't need to be res=
et, ever. However, this badly breaks comparibility with any existing classi=
c ECN TCP stack. I haven't investigated, but I think this is most unlike to=
 be in the code.
b)      CWD is set once per window
     This is similar to the behavior of classic ECN TCP, and provides conse=
rvative interoperability. I suspect that this is what DCTCP code currently =
does - but again, haven't measured it yet.
c)      CWD is set whenever cwnd is reduced (which could be nearly every pa=
cket for a few windows time). Working towards a classic ECN TCP receiver, t=
his could provide slightly more CE signals, when the RTT increases signific=
antly during a congestion episode. However, the exact behavior of the inter=
action between DCTCP sender and classic receiver would be much more complex=
, with potentially unexpected outcomes. Nevertheless, this also may have go=
ne into the code.

Furthermore, the draft is a bit vague how and when cwnd is updated. From th=
e formula used, this appears to be the initial DCTCP update algorithm, reac=
ting  once per window only; According to [1], dynamically updating cwnd on =
every receipt of ECE:

cwnd =3D cwnd + (1/cwnd - alpha/2)*MSS

would also address the RTT unfairness problem of the initial DCTCP algorith=
m. However, I understand that this draft is to document the deployed mechan=
ism, thus that latter point would be something for a different document.


I think it would not only be me and Midori who would appreciate filling out=
 these details in the draft.

Richard Scheffenegger

[1] Alizadeh, Mohammad, Adel Javanmard, and Balaji Prabhakar. "Analysis of =
DCTCP: stability, convergence, and fairness." Proceedings of the ACM SIGMET=
RICS joint international conference on Measurement and modeling of computer=
 systems. ACM, 2011.



--_000_012C3117EDDB3C4781FD802A8C27DD4F260DD086SACEXCMBX02PRDh_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
 #800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Calibri" size=3D"2"><span style=3D"font-size:11pt;">
<div>Hi,</div>
<div>&nbsp;</div>
<div>Section 2.3 misses out a small, but crucial detail.</div>
<div>&nbsp;</div>
<div>When I discussed DCTCP deployments and interoperability with Murari in=
 Prague (IETF80), he indicated that a DCTCP sender will still send (at leas=
t?) one CWD flag in each window where cwnd was reduced.</div>
<div>&nbsp;</div>
<div>However, none of the DCTCP papers mention the handling of the CWD flag=
, leaving open three potential variants:</div>
<div>&nbsp;</div>
<ol type=3D"a" style=3D"margin:0;padding-left:36pt;">
<li>CWD is not set when DCTCP is in use</li></ol>
<div style=3D"padding-left:35.4pt;">There is no need towards a DCTCP client=
, as ECE doesn&#8217;t need to be reset, ever. However, this badly breaks c=
omparibility with any existing classic ECN TCP stack. I haven&#8217;t inves=
tigated, but I think this is most unlike to be
in the code.</div>
<ol type=3D"a" start=3D"2" style=3D"margin:0;padding-left:36pt;">
<li>CWD is set once per window</li></ol>
<div style=3D"padding-left:35.4pt;">This is similar to the behavior of clas=
sic ECN TCP, and provides conservative interoperability. I suspect that thi=
s is what DCTCP code currently does &#8211; but again, haven&#8217;t measur=
ed it yet.</div>
<ol type=3D"a" start=3D"3" style=3D"margin:0;padding-left:36pt;">
<li>CWD is set whenever cwnd is reduced (which could be nearly every packet=
 for a few windows time). Working towards a classic ECN TCP receiver, this =
could provide slightly more CE signals, when the RTT increases significantl=
y during a congestion episode. However,
the exact behavior of the interaction between DCTCP sender and classic rece=
iver would be much more complex, with potentially unexpected outcomes. Neve=
rtheless, this also may have gone into the code.</li></ol>
<div>&nbsp;</div>
<div>Furthermore, the draft is a bit vague how and when cwnd is updated. Fr=
om the formula used, this appears to be the initial DCTCP update algorithm,=
 reacting&nbsp; once per window only; According to [1], dynamically updatin=
g cwnd on every receipt of ECE:</div>
<div>&nbsp;</div>
<div>cwnd =3D cwnd &#43; (1/cwnd - alpha/2)*MSS</div>
<div>&nbsp;</div>
<div>would also address the RTT unfairness problem of the initial DCTCP alg=
orithm. However, I understand that this draft is to document the deployed m=
echanism, thus that latter point would be something for a different documen=
t.</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>I think it would not only be me and Midori who would appreciate fillin=
g out these details in the draft.</div>
<div>&nbsp;</div>
<div>Richard Scheffenegger<br>

</div>
<div>[1] <font face=3D"Times New Roman" size=3D"3"><span style=3D"font-size=
:12pt;">Alizadeh, Mohammad, Adel Javanmard, and Balaji Prabhakar. &quot;Ana=
lysis of DCTCP: stability, convergence, and fairness.&quot; </span></font><=
font face=3D"Times New Roman" size=3D"3"><span style=3D"font-size:12pt;"><i=
>Proceedings
of the ACM SIGMETRICS joint international conference on Measurement and mod=
eling of computer systems</i></span></font><font face=3D"Times New Roman" s=
ize=3D"3"><span style=3D"font-size:12pt;">. </span></font><font face=3D"Tim=
es New Roman" size=3D"3"><span style=3D"font-size:12pt;">ACM,
2011.</span></font></div>
<div>&nbsp;</div>
<div>&nbsp;</div>
</span></font>
</body>
</html>

--_000_012C3117EDDB3C4781FD802A8C27DD4F260DD086SACEXCMBX02PRDh_--


From nobody Tue Mar 11 07:25:53 2014
Return-Path: <bob.briscoe@bt.com>
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 5115B1A0458 for <tcpm@ietfa.amsl.com>; Tue, 11 Mar 2014 07:25:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level: 
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, 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 kCZPRUjm4jeD for <tcpm@ietfa.amsl.com>; Tue, 11 Mar 2014 07:25:49 -0700 (PDT)
Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9531A044B for <tcpm@ietf.org>; Tue, 11 Mar 2014 07:25:46 -0700 (PDT)
Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 11 Mar 2014 14:25:39 +0000
Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 11 Mar 2014 14:25:37 +0000
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Tue, 11 Mar 2014 14:25:35 +0000
Received: from BTP075694.jungle.bt.co.uk ([10.215.130.15])	by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s2BEPXxp002313;	Tue, 11 Mar 2014 14:25:34 GMT
Message-ID: <201403111425.s2BEPXxp002313@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 11 Mar 2014 14:25:34 +0000
To: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>, "Martin Stiemerling" <mls.ietf@gmail.com>, <gorry@erg.abdn.ac.uk>, "Richard Scheffenegger" <rs@netapp.com>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <531D85A6.3020807@erg.abdn.ac.uk>
References: <201403061451.s26Epwcq006941@bagheera.jungle.bt.co.uk> <655C07320163294895BBADA28372AF5D213359@FR712WXCHMBA15.zeu.alcatel-lucent.com> <531D85A6.3020807@erg.abdn.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/SXcU61LVG4QcuxyKIOuQoAptBgM
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Mar 2014 14:25:52 -0000

Gorry, Michael, Martin, Richard,

I would be happy with INF as long as the outstanding issues were 
clearly identified (feedback broken, no negotiation of alternate wire 
protocol, deployment applicability, etc)

The main reason for suggesting HISTORIC was to avoid people getting 
the impression the protocol as currently implemented is good to go on 
the public Internet.


Bob

At 09:28 10/03/2014, Gorry Fairhurst wrote:
>This seems sensible to me, get WG comments feedback for an 
>individual submission (via AD) and propose as INFO. If there is 
>feedback by the authors they want it to be HISTORIC, that would be OK also.
>
>To me, it would need careful crafting of the abstract to explain the 
>current position with respect to other work in this area.
>
>Gorry
>
>On 09/03/2014 11:02, Scharf, Michael (Michael) wrote:
>>Hi Bob,
>>
>>I think we should encourage that implementers document widely 
>>deployed TCP mechanism in the RFC series, if they are willing to 
>>discuss with the IETF and improve document clarity so that the 
>>document is a good, informational description that can be used as 
>>reference. (This thought is actually independent of DCTCP.)
>>
>>If implementers are responsive to questions, such informational 
>>documentation (possible as AD-sponsored document) should actually 
>>be possible rather quickly. This almost likely implies that the RFC 
>>documents a mechanism that is still in use at the time of 
>>publication. To me, this is not "historic".
>>
>>I could imagine that a Proposed Standard produced by the IETF 
>>changes the status to "Historic" at a later stage. But even then 
>>I'd ask whether the Proposed Standard indeed describes what is 
>>deployed, or will be deployed, at large scale in the Internet.
>>
>>Thanks
>>
>>Michael (as individual contributor)
>>
>>
>>
>>>-----Original Message-----
>>>From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe
>>>Sent: Thursday, March 06, 2014 3:52 PM
>>>To: EGGERT, Lars; Martin Stiemerling
>>>Cc: tcpm IETF list
>>>Subject: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
>>>
>>>Lars,
>>>
>>>Everyone seems to agree this should be independent stream. That
>>>leaves the question of intended status...
>>>
>>>Imagine Microsoft now updates DCTCP to fix the feedback flaw. Then do
>>>you want to update this draft? I doubt it.
>>>
>>>So, IMO if you wanted to only document what Microsoft did, even tho
>>>it was  broken, then this should be HISTORIC, not INFORMATIONAL.
>>>
>>>If it's INFORMATIONAL it should at least fix known major problems
>>>before it is published.
>>>
>>>
>>>
>>>Bob
>>>
>>>
>>>
>>>________________________________________________________________
>>>Bob Briscoe,                                                  BT
>>>
>>>_______________________________________________
>>>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
>
>________________________________________________________________
>Bob Briscoe,                                                  BT 


From nobody Tue Mar 11 15:44:33 2014
Return-Path: <touch@isi.edu>
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 4FB141A0888 for <tcpm@ietfa.amsl.com>; Tue, 11 Mar 2014 15:44:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 XOn2JrZAdvx2 for <tcpm@ietfa.amsl.com>; Tue, 11 Mar 2014 15:44:27 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3DF1A086D for <tcpm@ietf.org>; Tue, 11 Mar 2014 15:44:27 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2BMhOXk028799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Mar 2014 15:43:24 -0700 (PDT)
Message-ID: <531F918C.2080700@isi.edu>
Date: Tue, 11 Mar 2014 15:43:24 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Diego R. Lopez" <diego@tid.es>, "tcpm@ietf.org" <tcpm@ietf.org>
References: <FDC308AD-096A-4FB7-AAA1-B6FAA1660F85@tid.es>
In-Reply-To: <FDC308AD-096A-4FB7-AAA1-B6FAA1660F85@tid.es>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/DeVs0P7RXdrgjAv7oPZUv_GmCB0
Cc: "draft-ietf-pce-pceps@tools.ietf.org" <draft-ietf-pce-pceps@tools.ietf.org>
Subject: Re: [tcpm] Looking for advice on a draft from the PCE working group
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Mar 2014 22:44:29 -0000

Some comments:

- the title should be changed to focus on TLS; the term "transport 
security" means different things to different people.

- Contrary to the claim in the Introductino, RFC5440 makes very specific 
requirements on PCEP, e.g., it MUST use TCP MD5

this document appears to override that requirement with TCP-AO; while I 
support that, the change needs to be more explicit

- I disagree with the need for (yet another) port for a TLS-enabled 
PCEP; STARTTLS allows the use of TLS to be negotiated in-band, and so 
the existing port should be used

Joe


On 3/11/2014 5:18 AM, Diego R. Lopez wrote:
> Hi,
>
> There is a draft, recently adopted by the PCE WG, on running the PCEP protocol on top of TLS. During the discussion of this draft several issues regarding transport aspects were raised, essentially dealing with the usage of TCP security options and with the need for requiring a separate port from the "plain" PCEP. The WG decided to seek for advice from the transport community and the ADs pointed me to this list as the most appropriate place for such an advice.
>
> You have the text of the draft available through https://datatracker.ietf.org/doc/draft-ietf-pce-pceps/
>
> Any feedback on the above mentioned issues or anything else you see in the document will be extremely welcome.
>
> Be goode,
> --
> "Esta vez no fallaremos, Doctor Infierno"
>
> Dr Diego R. Lopez
> Telefonica I+D
> http://people.tid.es/diego.lopez/
>
> e-mail: diego@tid.es
> Tel:    +34 913 129 041
> Mobile: +34 682 051 091
> -----------------------------------------
>
>
> ________________________________
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>


From nobody Tue Mar 11 21:53:38 2014
Return-Path: <internet-drafts@ietf.org>
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 588011A08D9; Tue, 11 Mar 2014 21:53:37 -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 TYj1LgUWWaTF; Tue, 11 Mar 2014 21:53:36 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4AF1A08E8; Tue, 11 Mar 2014 21:53:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140312045310.12915.63480.idtracker@ietfa.amsl.com>
Date: Tue, 11 Mar 2014 21:53:10 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ALU6yKhUx01CH2GS09HNOqPEdrk
Cc: tcpm@ietf.org
Subject: [tcpm] I-D Action: draft-ietf-tcpm-fastopen-08.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Mar 2014 04:53:37 -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 Fast Open
        Authors         : Yuchung Cheng
                          Jerry Chu
                          Sivasankar Radhakrishnan
                          Arvind Jain
	Filename        : draft-ietf-tcpm-fastopen-08.txt
	Pages           : 24
	Date            : 2014-03-11

Abstract:
   This document describes an experimental TCP mechanism TCP Fast Open
   (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets
   and consumed by the receiving end during the initial connection
   handshake, thus saving up to one full round trip time (RTT) compared
   to the standard TCP, which requires a three-way handshake (3WHS) to
   complete before data can be exchanged. However TFO deviates from the
   standard TCP semantics since the data in the SYN could be replayed to
   an application in some rare circumstances. Applications should not
   use TFO unless they can tolerate this issue detailed in the
   Applicability section.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-fastopen-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Mar 12 14:13:23 2014
Return-Path: <sbens@microsoft.com>
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 960B31A0664 for <tcpm@ietfa.amsl.com>; Wed, 12 Mar 2014 14:13:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 XPtx-71MiWoa for <tcpm@ietfa.amsl.com>; Wed, 12 Mar 2014 14:13:15 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn14138.inbound.protection.outlook.com [207.46.163.138]) by ietfa.amsl.com (Postfix) with ESMTP id 308591A0644 for <tcpm@ietf.org>; Wed, 12 Mar 2014 14:13:14 -0700 (PDT)
Received: from BN1PR03MB021.namprd03.prod.outlook.com (10.255.224.39) by BN1PR03MB203.namprd03.prod.outlook.com (10.255.200.146) with Microsoft SMTP Server (TLS) id 15.0.898.11; Wed, 12 Mar 2014 21:13:07 +0000
Received: from BN1PR03MB023.namprd03.prod.outlook.com (10.255.224.41) by BN1PR03MB021.namprd03.prod.outlook.com (10.255.224.39) with Microsoft SMTP Server (TLS) id 15.0.898.11; Wed, 12 Mar 2014 21:13:04 +0000
Received: from BN1PR03MB023.namprd03.prod.outlook.com ([169.254.6.92]) by BN1PR03MB023.namprd03.prod.outlook.com ([169.254.6.207]) with mapi id 15.00.0898.005; Wed, 12 Mar 2014 21:13:04 +0000
From: Stephen Bensley <sbens@microsoft.com>
To: "Scheffenegger, Richard" <rs@netapp.com>, "draft-bensley-tcpm-dctcp@tools.ietf.org" <draft-bensley-tcpm-dctcp@tools.ietf.org>
Thread-Topic: CWD flag use in DCTCP
Thread-Index: Ac89LGvu60jvlEzrTUC2Lbm6I8rcmQBCz0Kg
Date: Wed, 12 Mar 2014 21:13:03 +0000
Message-ID: <b47cdff7d5264c2ba88710fed5545c37@BN1PR03MB023.namprd03.prod.outlook.com>
References: <012C3117EDDB3C4781FD802A8C27DD4F260DD086@SACEXCMBX02-PRD.hq.netapp.com>
In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F260DD086@SACEXCMBX02-PRD.hq.netapp.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ed43::2]
x-forefront-prvs: 01480965DA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(51914003)(199002)(189002)(74366001)(86362001)(92566001)(74876001)(93516002)(46102001)(50986001)(47976001)(87266001)(4396001)(56816005)(97186001)(81342001)(65816001)(47736001)(93136001)(2656002)(74706001)(49866001)(80022001)(74316001)(94316002)(80976001)(85306002)(19580405001)(76576001)(87936001)(53806001)(31966008)(95416001)(15202345003)(77096001)(97336001)(76786001)(76482001)(54316002)(81686001)(56776001)(85852003)(16236675002)(555904002)(83072002)(95666003)(54356001)(74502001)(47446002)(81542001)(77982001)(51856001)(83322001)(74662001)(15975445006)(76796001)(90146001)(19300405004)(79102001)(69226001)(94946001)(20776003)(63696002)(19580395003)(33646001)(81816001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR03MB021; H:BN1PR03MB023.namprd03.prod.outlook.com; FPR:EC5CF1D5.A7CA97F2.F1F171A3.CAED8341.204C9; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (: microsoft.com does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_b47cdff7d5264c2ba88710fed5545c37BN1PR03MB023namprd03pro_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/mWbj17FrbeXnMU2YMyzOfgUEsPA
Cc: "tcpm \(tcpm@ietf.org\)" <tcpm@ietf.org>
Subject: Re: [tcpm] CWD flag use in DCTCP
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Mar 2014 21:13:20 -0000

--_000_b47cdff7d5264c2ba88710fed5545c37BN1PR03MB023namprd03pro_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Richard,



My name is Stephen Bensley. I'm one of the authors of the draft. I'm also t=
he development lead for the Data Path and Transports team in the Operating =
Systems Group at Microsoft. I was not involved in the original design and i=
mplementation of DCTCP, but my team currently owns and maintains this code.



I'm guessing by CWD, you really mean the CWR flag.



The CWR handling on the sender is exactly as per RFC 3168. The receiver ign=
ores the CWR flag.



In reviewing this, I realized that the draft is incorrect about the cwnd up=
date behavior. In particular, cwnd is not updated whenever the TCP congesti=
on estimate is updated. It is updated as per RFC 3168; the only difference =
is that cwnd is scaled by (1 - DCTCP.Alpha / 2) instead of always being red=
uced by half.



Windows does not implement the RTT fairness tweak suggested in the paper yo=
u referenced below.



I'll fix all of this in the next version of the draft.



Thanks for the feedback.


From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scheffenegger, Richa=
rd
Sent: Tuesday, March 11, 2014 6:37 AM
To: draft-bensley-tcpm-dctcp@tools.ietf.org
Cc: tcpm (tcpm@ietf.org)
Subject: [tcpm] CWD flag use in DCTCP

Hi,

Section 2.3 misses out a small, but crucial detail.

When I discussed DCTCP deployments and interoperability with Murari in Prag=
ue (IETF80), he indicated that a DCTCP sender will still send (at least?) o=
ne CWD flag in each window where cwnd was reduced.

However, none of the DCTCP papers mention the handling of the CWD flag, lea=
ving open three potential variants:

a.       CWD is not set when DCTCP is in use
There is no need towards a DCTCP client, as ECE doesn't need to be reset, e=
ver. However, this badly breaks comparibility with any existing classic ECN=
 TCP stack. I haven't investigated, but I think this is most unlike to be i=
n the code.
b.      CWD is set once per window
This is similar to the behavior of classic ECN TCP, and provides conservati=
ve interoperability. I suspect that this is what DCTCP code currently does =
- but again, haven't measured it yet.
c.       CWD is set whenever cwnd is reduced (which could be nearly every p=
acket for a few windows time). Working towards a classic ECN TCP receiver, =
this could provide slightly more CE signals, when the RTT increases signifi=
cantly during a congestion episode. However, the exact behavior of the inte=
raction between DCTCP sender and classic receiver would be much more comple=
x, with potentially unexpected outcomes. Nevertheless, this also may have g=
one into the code.

Furthermore, the draft is a bit vague how and when cwnd is updated. From th=
e formula used, this appears to be the initial DCTCP update algorithm, reac=
ting  once per window only; According to [1], dynamically updating cwnd on =
every receipt of ECE:

cwnd =3D cwnd + (1/cwnd - alpha/2)*MSS

would also address the RTT unfairness problem of the initial DCTCP algorith=
m. However, I understand that this draft is to document the deployed mechan=
ism, thus that latter point would be something for a different document.


I think it would not only be me and Midori who would appreciate filling out=
 these details in the draft.

Richard Scheffenegger
[1] Alizadeh, Mohammad, Adel Javanmard, and Balaji Prabhakar. "Analysis of =
DCTCP: stability, convergence, and fairness." Proceedings of the ACM SIGMET=
RICS joint international conference on Measurement and modeling of computer=
 systems. ACM, 2011.



--_000_b47cdff7d5264c2ba88710fed5545c37BN1PR03MB023namprd03pro_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	border:none;
	padding:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:726757156;
	mso-list-template-ids:799733822;}
@list l0:level1
	{mso-level-start-at:3;
	mso-level-number-format:alpha-lower;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level4
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level7
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1
	{mso-list-id:980695638;
	mso-list-template-ids:1254010022;}
@list l1:level1
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level3
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level4
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level6
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level7
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1:level9
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2
	{mso-list-id:1411462273;
	mso-list-template-ids:-395805866;}
@list l2:level1
	{mso-level-start-at:2;
	mso-level-number-format:alpha-lower;
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level3
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level4
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level6
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level7
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l2:level9
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText">Hi Richard,<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">My name is Stephen Bensley. I&#8217;m one of the =
authors of the draft. I&#8217;m also the development lead for the Data Path=
 and Transports team in the Operating Systems Group at Microsoft. I was not=
 involved in the original design and implementation
 of DCTCP, but my team currently owns and maintains this code.<o:p></o:p></=
p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">I&#8217;m guessing by CWD, you really mean the CW=
R flag.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">The CWR handling on the sender is exactly as per =
RFC 3168. The receiver ignores the CWR flag.
<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">In reviewing this, I realized that the draft is i=
ncorrect about the cwnd update behavior. In particular, cwnd is not updated=
 whenever the TCP congestion estimate is updated. It is updated as per RFC =
3168; the only difference is that
 cwnd is scaled by (1 - DCTCP.Alpha / 2) instead of always being reduced by=
 half.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Windows does not implement the RTT fairness tweak=
 suggested in the paper you referenced below.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">I&#8217;ll fix all of this in the next version of=
 the draft.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText">Thanks for the feedback.<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-=
size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"> tcpm [=
mailto:tcpm-bounces@ietf.org]
<b>On Behalf Of </b>Scheffenegger, Richard<br>
<b>Sent:</b> Tuesday, March 11, 2014 6:37 AM<br>
<b>To:</b> draft-bensley-tcpm-dctcp@tools.ietf.org<br>
<b>Cc:</b> tcpm (tcpm@ietf.org)<br>
<b>Subject:</b> [tcpm] CWD flag use in DCTCP<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Hi,<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Section 2.3 misses out a small, but cru=
cial detail.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">When I discussed DCTCP deployments and =
interoperability with Murari in Prague (IETF80), he indicated that a DCTCP =
sender will still send (at least?) one CWD flag in each
 window where cwnd was reduced.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">However, none of the DCTCP papers menti=
on the handling of the CWD flag, leaving open three potential variants:<o:p=
></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:0in;text-indent:-.25in;mso-list:l1 level1 lfo1">
<![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&quot;Cali=
bri&quot;,&quot;sans-serif&quot;"><span style=3D"mso-list:Ignore">a.<span s=
tyle=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;">CWD is not set when DCTCP is in=
 use<o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">There is no need towards a DCTCP client=
, as ECE doesn&#8217;t need to be reset, ever. However, this badly breaks c=
omparibility with any existing classic ECN TCP stack. I haven&#8217;t
 investigated, but I think this is most unlike to be in the code.<o:p></o:p=
></span></p>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:0in;text-indent:-.25in;mso-list:l2 level1 lfo2">
<![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&quot;Cali=
bri&quot;,&quot;sans-serif&quot;"><span style=3D"mso-list:Ignore">b.<span s=
tyle=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;">CWD is set once per window<o:p>=
</o:p></span></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">This is similar to the behavior of clas=
sic ECN TCP, and provides conservative interoperability. I suspect that thi=
s is what DCTCP code currently does &#8211; but again, haven&#8217;t
 measured it yet.<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;margin-left:0in;text-indent:-.25in;mso-list:l0 level1 lfo3">
<![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&quot;Cali=
bri&quot;,&quot;sans-serif&quot;"><span style=3D"mso-list:Ignore">c.<span s=
tyle=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;">CWD is set whenever cwnd is red=
uced (which could be nearly every packet for a few windows time). Working t=
owards a classic ECN TCP receiver, this could provide
 slightly more CE signals, when the RTT increases significantly during a co=
ngestion episode. However, the exact behavior of the interaction between DC=
TCP sender and classic receiver would be much more complex, with potentiall=
y unexpected outcomes. Nevertheless,
 this also may have gone into the code.<o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Furthermore, the draft is a bit vague h=
ow and when cwnd is updated. From the formula used, this appears to be the =
initial DCTCP update algorithm, reacting&nbsp; once per window
 only; According to [1], dynamically updating cwnd on every receipt of ECE:=
<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">cwnd =3D cwnd &#43; (1/cwnd - alpha/2)*=
MSS<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">would also address the RTT unfairness p=
roblem of the initial DCTCP algorithm. However, I understand that this draf=
t is to document the deployed mechanism, thus that latter
 point would be something for a different document.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">I think it would not only be me and Mid=
ori who would appreciate filling out these details in the draft.<o:p></o:p>=
</span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">Richard Scheffenegger<o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">[1]
</span>Alizadeh, Mohammad, Adel Javanmard, and Balaji Prabhakar. &quot;Anal=
ysis of DCTCP: stability, convergence, and fairness.&quot;
<i>Proceedings of the ACM SIGMETRICS joint international conference on Meas=
urement and modeling of computer systems</i>. ACM, 2011.<span style=3D"font=
-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"><o:p><=
/o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span></p>
</div>
</div>
</body>
</html>

--_000_b47cdff7d5264c2ba88710fed5545c37BN1PR03MB023namprd03pro_--


From nobody Thu Mar 13 03:56:13 2014
Return-Path: <michawe@ifi.uio.no>
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 AE6941A09C9 for <tcpm@ietfa.amsl.com>; Thu, 13 Mar 2014 03:56:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.446
X-Spam-Level: 
X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] 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 mhA3osogh_kF for <tcpm@ietfa.amsl.com>; Thu, 13 Mar 2014 03:56:09 -0700 (PDT)
Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id B817F1A093F for <tcpm@ietf.org>; Thu, 13 Mar 2014 03:56:08 -0700 (PDT)
Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from <michawe@ifi.uio.no>) id 1WO3Iv-0000VZ-B1 for tcpm@ietf.org; Thu, 13 Mar 2014 11:56:01 +0100
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1WO3Iu-0002Ze-SL for tcpm@ietf.org; Thu, 13 Mar 2014 11:56:01 +0100
From: Michael Welzl <michawe@ifi.uio.no>
Content-Type: multipart/alternative; boundary="Apple-Mail=_91129FF5-A734-474A-850A-8CE075B1A0C9"
Date: Thu, 13 Mar 2014 11:56:00 +0100
References: <CAAvOmMs-MJEotVbC-AyztOauTNaCEzmazoW3szM_kaQ+_KT4-w@mail.gmail.com>
To: "tcpm (tcpm@ietf.org)" <tcpm@ietf.org>
Message-Id: <93BCF9DB-B918-416E-B7E3-32D40F4FDB71@ifi.uio.no>
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 5 sum msgs/h 4 total rcpts 13570 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 21A1A38F39837C0E10ECD2D3BB2FDB1E867202B5
X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 4585 max/h 16 blacklist 0 greylist 0 ratelimit 0
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/YEciP9hoMiVqw_JGeq90d8foY8Y
Subject: [tcpm] Fwd: [iccrg] draft update: draft-sallantin-iccrg-initial-spreading-01
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Mar 2014 10:56:11 -0000

--Apple-Mail=_91129FF5-A734-474A-850A-8CE075B1A0C9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

FYI - I guess this is of interest to folks in TCPM; however please keep =
discussion in ICCRG ( iccrg@irtf.org ).

Cheers,
Michael


Begin forwarded message:

> From: renaud sallantin <renaud.sallantin@gmail.com>
> Subject: [iccrg] draft update: =
draft-sallantin-iccrg-initial-spreading-01
> Date: 13. mars 2014 11:30:53 GMT+01:00
> To: iccrg@irtf.org, cedric baudoin =
<cedric.baudoin@thalesaleniaspace.com>, Fabrice Arnal =
<fabrice.arnal@thalesaleniaspace.com>, Andre-Luc Beylot =
<andre-luc.beylot@enseeiht.fr>, Dubois Emmanuel =
<emmanuel.dubois@cnes.fr>, Chaput <emmanuel.chaput@enseeiht.fr>
>=20
> Dear all,
>=20
> Thanks to the numerous comments and supports we got during the last =
ICCRG meeting but also during the whole week, we have updated our draft.
>=20
> It notably takes into account your remarks and advices on the kernel's =
timers.
>=20
> http://tools.ietf.org/html/draft-sallantin-iccrg-initial-spreading-01
>=20
>=20
> We would be more than happy to receive your feedback,
> Cheers,
>=20
> Renaud Sallantin
>=20
>=20
> _______________________________________________
> iccrg mailing list
> iccrg@irtf.org
> https://www.irtf.org/mailman/listinfo/iccrg


--Apple-Mail=_91129FF5-A734-474A-850A-8CE075B1A0C9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">FYI - =
I guess this is of interest to folks in TCPM; however please keep =
discussion in ICCRG ( <a href=3D"mailto:iccrg@irtf.org">iccrg@irtf.org</a>=
 =
).<div><br></div><div><div>Cheers,</div><div>Michael</div><div><br></div><=
div><br><div>Begin forwarded message:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family:'Helvetica'; =
font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>From: </b></span><span =
style=3D"font-family:'Helvetica'; font-size:medium;">renaud sallantin =
&lt;<a =
href=3D"mailto:renaud.sallantin@gmail.com">renaud.sallantin@gmail.com</a>&=
gt;<br></span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px;"><span =
style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, =
1.0);"><b>Subject: </b></span><span style=3D"font-family:'Helvetica'; =
font-size:medium;"><b>[iccrg] draft update: =
draft-sallantin-iccrg-initial-spreading-01</b><br></span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family:'Helvetica'; =
font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>Date: </b></span><span =
style=3D"font-family:'Helvetica'; font-size:medium;">13. mars 2014 =
11:30:53 GMT+01:00<br></span></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span =
style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, =
1.0);"><b>To: </b></span><span style=3D"font-family:'Helvetica'; =
font-size:medium;"><a href=3D"mailto:iccrg@irtf.org">iccrg@irtf.org</a>, =
cedric baudoin &lt;<a =
href=3D"mailto:cedric.baudoin@thalesaleniaspace.com">cedric.baudoin@thales=
aleniaspace.com</a>&gt;,  Fabrice Arnal &lt;<a =
href=3D"mailto:fabrice.arnal@thalesaleniaspace.com">fabrice.arnal@thalesal=
eniaspace.com</a>&gt;,  Andre-Luc Beylot &lt;<a =
href=3D"mailto:andre-luc.beylot@enseeiht.fr">andre-luc.beylot@enseeiht.fr<=
/a>&gt;, Dubois Emmanuel &lt;<a =
href=3D"mailto:emmanuel.dubois@cnes.fr">emmanuel.dubois@cnes.fr</a>&gt;, =
 Chaput &lt;<a =
href=3D"mailto:emmanuel.chaput@enseeiht.fr">emmanuel.chaput@enseeiht.fr</a=
>&gt;<br></span></div><br><div dir=3D"ltr"><div><div>Dear =
all,<br><br></div>Thanks to the numerous comments and supports we got =
during the last ICCRG meeting but also during the whole week, we have =
updated our draft.<br><br></div>It notably takes into account your =
remarks and advices on the kernel's timers.<br>
<div><br><div><div><div><a =
href=3D"http://tools.ietf.org/html/draft-sallantin-iccrg-initial-spreading=
-01">http://tools.ietf.org/html/draft-sallantin-iccrg-initial-spreading-01=
</a><br><br><br></div><div>We would be more than happy to receive your =
feedback,<br>
</div><div>Cheers,<br><br></div><div>Renaud =
Sallantin<br></div><div><br><br></div></div></div></div></div>
_______________________________________________<br>iccrg mailing =
list<br><a =
href=3D"mailto:iccrg@irtf.org">iccrg@irtf.org</a><br>https://www.irtf.org/=
mailman/listinfo/iccrg<br></blockquote></div><br></div></body></html>=

--Apple-Mail=_91129FF5-A734-474A-850A-8CE075B1A0C9--


From nobody Thu Mar 13 04:23:10 2014
Return-Path: <rs@netapp.com>
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 AD5AC1A0950 for <tcpm@ietfa.amsl.com>; Thu, 13 Mar 2014 04:23:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.448
X-Spam-Level: 
X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-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 dulI7lGnGVge for <tcpm@ietfa.amsl.com>; Thu, 13 Mar 2014 04:23:03 -0700 (PDT)
Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 87AB31A095C for <tcpm@ietf.org>; Thu, 13 Mar 2014 04:23:03 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.97,646,1389772800";  d="scan'208,217";a="149703223"
Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx12-out.netapp.com with ESMTP; 13 Mar 2014 04:22:57 -0700
Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Thu, 13 Mar 2014 04:22:57 -0700
From: "Scheffenegger, Richard" <rs@netapp.com>
To: Stephen Bensley <sbens@microsoft.com>, "draft-bensley-tcpm-dctcp@tools.ietf.org" <draft-bensley-tcpm-dctcp@tools.ietf.org>
Thread-Topic: CWD flag use in DCTCP
Thread-Index: Ac89LGvu60jvlEzrTUC2Lbm6I8rcmQBCz0KgAB1/EyA=
Date: Thu, 13 Mar 2014 11:22:56 +0000
Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F260E5FC5@SACEXCMBX02-PRD.hq.netapp.com>
References: <012C3117EDDB3C4781FD802A8C27DD4F260DD086@SACEXCMBX02-PRD.hq.netapp.com> <b47cdff7d5264c2ba88710fed5545c37@BN1PR03MB023.namprd03.prod.outlook.com>
In-Reply-To: <b47cdff7d5264c2ba88710fed5545c37@BN1PR03MB023.namprd03.prod.outlook.com>
Accept-Language: de-AT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.122.105.29]
Content-Type: multipart/alternative; boundary="_000_012C3117EDDB3C4781FD802A8C27DD4F260E5FC5SACEXCMBX02PRDh_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/GUmpaxbQWy_hi3QvRT_DgczRn5o
Cc: "tcpm \(tcpm@ietf.org\)" <tcpm@ietf.org>
Subject: Re: [tcpm] CWD flag use in DCTCP
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Mar 2014 11:23:08 -0000

--_000_012C3117EDDB3C4781FD802A8C27DD4F260E5FC5SACEXCMBX02PRDh_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Stephen,

You are correct, I meant the CWR flag, of course. And I am relieved that wh=
at I understood from Murari a few years ago, about the interaction of a DCT=
CP sender with a classic ECN (3168) receiver is in fact correct. You may wa=
nt to dedicate a short section on that behavior, as sometimes it's not evid=
ent that such a combination works mostly similar to classic ECN, provided t=
he marking rate becomes high enough. (I think, the EWMA term in calculating=
 alpha will delay the reaction of DCTCP though, thus result in preferential=
 use of bandwidth by DCTCP over 3168 classic ECN TCP; but at least classic =
ECN shouldn't be locked out completely)

Thank you for considering the feedback, I appreciate it.

Richard Scheffenegger

NetApp
rs@netapp.com<mailto:rs@netapp.com>
+43 1 3676811 3146 Office (2143 3146 - internal)
+43 676 654 3146 Mobile
www.netapp.com<http://www.netapp.com>

EURO PLAZA
Geb=E4ude G, Stiege 7, 3.OG
Am Euro Platz 2
A-1120 Wien


From: Stephen Bensley [mailto:sbens@microsoft.com]
Sent: Mittwoch, 12. M=E4rz 2014 22:13
To: Scheffenegger, Richard; draft-bensley-tcpm-dctcp@tools.ietf.org
Cc: tcpm (tcpm@ietf.org)
Subject: RE: CWD flag use in DCTCP


Hi Richard,



My name is Stephen Bensley. I'm one of the authors of the draft. I'm also t=
he development lead for the Data Path and Transports team in the Operating =
Systems Group at Microsoft. I was not involved in the original design and i=
mplementation of DCTCP, but my team currently owns and maintains this code.



I'm guessing by CWD, you really mean the CWR flag.



The CWR handling on the sender is exactly as per RFC 3168. The receiver ign=
ores the CWR flag.



In reviewing this, I realized that the draft is incorrect about the cwnd up=
date behavior. In particular, cwnd is not updated whenever the TCP congesti=
on estimate is updated. It is updated as per RFC 3168; the only difference =
is that cwnd is scaled by (1 - DCTCP.Alpha / 2) instead of always being red=
uced by half.



Windows does not implement the RTT fairness tweak suggested in the paper yo=
u referenced below.



I'll fix all of this in the next version of the draft.



Thanks for the feedback.


From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scheffenegger, Richa=
rd
Sent: Tuesday, March 11, 2014 6:37 AM
To: draft-bensley-tcpm-dctcp@tools.ietf.org<mailto:draft-bensley-tcpm-dctcp=
@tools.ietf.org>
Cc: tcpm (tcpm@ietf.org<mailto:tcpm@ietf.org>)
Subject: [tcpm] CWD flag use in DCTCP

Hi,

Section 2.3 misses out a small, but crucial detail.

When I discussed DCTCP deployments and interoperability with Murari in Prag=
ue (IETF80), he indicated that a DCTCP sender will still send (at least?) o=
ne CWD flag in each window where cwnd was reduced.

However, none of the DCTCP papers mention the handling of the CWD flag, lea=
ving open three potential variants:

a.       CWD is not set when DCTCP is in use
There is no need towards a DCTCP client, as ECE doesn't need to be reset, e=
ver. However, this badly breaks comparibility with any existing classic ECN=
 TCP stack. I haven't investigated, but I think this is most unlike to be i=
n the code.
b.      CWD is set once per window
This is similar to the behavior of classic ECN TCP, and provides conservati=
ve interoperability. I suspect that this is what DCTCP code currently does =
- but again, haven't measured it yet.
c.       CWD is set whenever cwnd is reduced (which could be nearly every p=
acket for a few windows time). Working towards a classic ECN TCP receiver, =
this could provide slightly more CE signals, when the RTT increases signifi=
cantly during a congestion episode. However, the exact behavior of the inte=
raction between DCTCP sender and classic receiver would be much more comple=
x, with potentially unexpected outcomes. Nevertheless, this also may have g=
one into the code.

Furthermore, the draft is a bit vague how and when cwnd is updated. From th=
e formula used, this appears to be the initial DCTCP update algorithm, reac=
ting  once per window only; According to [1], dynamically updating cwnd on =
every receipt of ECE:

cwnd =3D cwnd + (1/cwnd - alpha/2)*MSS

would also address the RTT unfairness problem of the initial DCTCP algorith=
m. However, I understand that this draft is to document the deployed mechan=
ism, thus that latter point would be something for a different document.


I think it would not only be me and Midori who would appreciate filling out=
 these details in the draft.

Richard Scheffenegger
[1] Alizadeh, Mohammad, Adel Javanmard, and Balaji Prabhakar. "Analysis of =
DCTCP: stability, convergence, and fairness." Proceedings of the ACM SIGMET=
RICS joint international conference on Measurement and modeling of computer=
 systems. ACM, 2011.



--_000_012C3117EDDB3C4781FD802A8C27DD4F260E5FC5SACEXCMBX02PRDh_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle24
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"DE-AT" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi Stephen,<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">You are co=
rrect, I meant the CWR flag, of course. And I am relieved that what I under=
stood from Murari a few years ago, about the interaction of
 a DCTCP sender with a classic ECN (3168) receiver is in fact correct. You =
may want to dedicate a short section on that behavior, as sometimes it&#821=
7;s not evident that such a combination works mostly similar to classic ECN=
, provided the marking rate becomes high
 enough. (I think, the EWMA term in calculating alpha will delay the reacti=
on of DCTCP though, thus result in preferential use of bandwidth by DCTCP o=
ver 3168 classic ECN TCP; but at least classic ECN shouldn&#8217;t be locke=
d out completely)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thank you =
for considering the feedback, I appreciate it.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Richard Scheffenegger</sp=
an><span style=3D"font-size:10.0pt;font-family:&quot;Calibri&quot;,&quot;sa=
ns-serif&quot;;color:#1F497D"><br>
<br>
NetApp<br>
<a href=3D"mailto:rs@netapp.com"><span style=3D"color:blue">rs@netapp.com</=
span></a><br>
&#43;43 1 3676811 3146 Office (2143 3146 - internal)<br>
&#43;43 676 654 3146 Mobile<br>
<a href=3D"http://www.netapp.com"><span style=3D"color:blue">www.netapp.com=
</span></a>&nbsp;&nbsp;<br>
<br>
EURO PLAZA<br>
Geb=E4ude G, Stiege 7, 3.OG<br>
Am Euro Platz 2<br>
A-1120 Wien<br>
<br>
<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo=
nt-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span =
lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&qu=
ot;sans-serif&quot;"> Stephen Bensley [mailto:sbens@microsoft.com]
<br>
<b>Sent:</b> Mittwoch, 12. M=E4rz 2014 22:13<br>
<b>To:</b> Scheffenegger, Richard; draft-bensley-tcpm-dctcp@tools.ietf.org<=
br>
<b>Cc:</b> tcpm (tcpm@ietf.org)<br>
<b>Subject:</b> RE: CWD flag use in DCTCP<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">Hi Richard,<o:p></o:p></span=
></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">My name is Stephen Bensley. =
I&#8217;m one of the authors of the draft. I&#8217;m also the development l=
ead for the Data Path and Transports team in the Operating Systems Group at=
 Microsoft. I was not involved in the original design
 and implementation of DCTCP, but my team currently owns and maintains this=
 code.<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">I&#8217;m guessing by CWD, y=
ou really mean the CWR flag.<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">The CWR handling on the send=
er is exactly as per RFC 3168. The receiver ignores the CWR flag.
<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">In reviewing this, I realize=
d that the draft is incorrect about the cwnd update behavior. In particular=
, cwnd is not updated whenever the TCP congestion estimate is updated. It i=
s updated as per RFC 3168; the only
 difference is that cwnd is scaled by (1 - DCTCP.Alpha / 2) instead of alwa=
ys being reduced by half.<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">Windows does not implement t=
he RTT fairness tweak suggested in the paper you referenced below.<o:p></o:=
p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">I&#8217;ll fix all of this i=
n the next version of the draft.<o:p></o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoPlainText"><span lang=3D"EN-US">Thanks for the feedback.<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:11.0pt;fo=
nt-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">From:</span></b><span=
 lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&=
quot;sans-serif&quot;"> tcpm [<a href=3D"mailto:tcpm-bounces@ietf.org">mail=
to:tcpm-bounces@ietf.org</a>]
<b>On Behalf Of </b>Scheffenegger, Richard<br>
<b>Sent:</b> Tuesday, March 11, 2014 6:37 AM<br>
<b>To:</b> <a href=3D"mailto:draft-bensley-tcpm-dctcp@tools.ietf.org">draft=
-bensley-tcpm-dctcp@tools.ietf.org</a><br>
<b>Cc:</b> tcpm (<a href=3D"mailto:tcpm@ietf.org">tcpm@ietf.org</a>)<br>
<b>Subject:</b> [tcpm] CWD flag use in DCTCP<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">Hi,<o:p></o:p></span></p=
>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">Section 2.3 misses out a=
 small, but crucial detail.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">When I discussed DCTCP d=
eployments and interoperability with Murari in Prague (IETF80), he indicate=
d that a DCTCP sender will still send (at least?) one CWD
 flag in each window where cwnd was reduced.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">However, none of the DCT=
CP papers mention the handling of the CWD flag, leaving open three potentia=
l variants:<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span>=
</p>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;text-indent:-18.0pt">
<span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;Calibri&qu=
ot;,&quot;sans-serif&quot;">a.</span><span lang=3D"EN-US" style=3D"font-siz=
e:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;">CWD is not set when DCTCP is in use<o:p>=
</o:p></span></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">There is no need towards=
 a DCTCP client, as ECE doesn&#8217;t need to be reset, ever. However, this=
 badly breaks comparibility with any existing classic ECN TCP stack.
 I haven&#8217;t investigated, but I think this is most unlike to be in the=
 code.<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;text-indent:-18.0pt">
<span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;Calibri&qu=
ot;,&quot;sans-serif&quot;">b.</span><span lang=3D"EN-US" style=3D"font-siz=
e:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;">CWD is set once per window<o:p></o:p></s=
pan></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">This is similar to the b=
ehavior of classic ECN TCP, and provides conservative interoperability. I s=
uspect that this is what DCTCP code currently does &#8211; but again,
 haven&#8217;t measured it yet.<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;text-indent:-18.0pt">
<span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;Calibri&qu=
ot;,&quot;sans-serif&quot;">c.</span><span lang=3D"EN-US" style=3D"font-siz=
e:7.0pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;Cal=
ibri&quot;,&quot;sans-serif&quot;">CWD is set whenever cwnd is reduced (whi=
ch could be nearly every packet for a few windows time). Working towards a =
classic ECN TCP receiver, this could provide slightly more
 CE signals, when the RTT increases significantly during a congestion episo=
de. However, the exact behavior of the interaction between DCTCP sender and=
 classic receiver would be much more complex, with potentially unexpected o=
utcomes. Nevertheless, this also
 may have gone into the code.<o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">Furthermore, the draft i=
s a bit vague how and when cwnd is updated. From the formula used, this app=
ears to be the initial DCTCP update algorithm, reacting&nbsp; once
 per window only; According to [1], dynamically updating cwnd on every rece=
ipt of ECE:<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">cwnd =3D cwnd &#43; (1/c=
wnd - alpha/2)*MSS<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">would also address the R=
TT unfairness problem of the initial DCTCP algorithm. However, I understand=
 that this draft is to document the deployed mechanism, thus
 that latter point would be something for a different document.<o:p></o:p><=
/span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">I think it would not onl=
y be me and Midori who would appreciate filling out these details in the dr=
aft.<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">Richard Scheffenegger<o:=
p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">[1]
</span><span lang=3D"EN-US">Alizadeh, Mohammad, Adel Javanmard, and Balaji =
Prabhakar. &quot;Analysis of DCTCP: stability, convergence, and fairness.&q=
uot;
<i>Proceedings of the ACM SIGMETRICS joint international conference on Meas=
urement and modeling of computer systems</i>. ACM, 2011.</span><span lang=
=3D"EN-US" style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span>=
</p>
</div>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;">&nbsp;<o:p></o:p></span>=
</p>
</div>
</div>
</div>
</body>
</html>

--_000_012C3117EDDB3C4781FD802A8C27DD4F260E5FC5SACEXCMBX02PRDh_--


From nobody Thu Mar 13 07:52:23 2014
Return-Path: <sbens@microsoft.com>
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 A24EE1A09E9 for <tcpm@ietfa.amsl.com>; Thu, 13 Mar 2014 07:52:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 9mE6RnHTsln3 for <tcpm@ietfa.amsl.com>; Thu, 13 Mar 2014 07:52:14 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4771A0A0D for <tcpm@ietf.org>; Thu, 13 Mar 2014 07:52:14 -0700 (PDT)
Received: from BN1PR03MB023.namprd03.prod.outlook.com (10.255.224.41) by BN1PR03MB023.namprd03.prod.outlook.com (10.255.224.41) with Microsoft SMTP Server (TLS) id 15.0.898.11; Thu, 13 Mar 2014 14:52:06 +0000
Received: from BN1PR03MB023.namprd03.prod.outlook.com ([169.254.6.66]) by BN1PR03MB023.namprd03.prod.outlook.com ([169.254.6.66]) with mapi id 15.00.0898.005; Thu, 13 Mar 2014 14:52:06 +0000
From: Stephen Bensley <sbens@microsoft.com>
To: Bob Briscoe <bob.briscoe@bt.com>, "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>, Martin Stiemerling <mls.ietf@gmail.com>,  "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Richard Scheffenegger <rs@netapp.com>
Thread-Topic: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
Thread-Index: AQHPOUuqAo6vz4uFNkGDCeAsqicfcZrYm3eAgAF4BwCAAeVxAIADJy2A
Date: Thu, 13 Mar 2014 14:52:06 +0000
Message-ID: <c1a10e94e7194d07bc6f3ea010eb0d12@BN1PR03MB023.namprd03.prod.outlook.com>
References: <201403061451.s26Epwcq006941@bagheera.jungle.bt.co.uk> <655C07320163294895BBADA28372AF5D213359@FR712WXCHMBA15.zeu.alcatel-lucent.com> <531D85A6.3020807@erg.abdn.ac.uk> <201403111425.s2BEPXxp002313@bagheera.jungle.bt.co.uk>
In-Reply-To: <201403111425.s2BEPXxp002313@bagheera.jungle.bt.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ed31::2]
x-forefront-prvs: 01494FA7F7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(377454003)(479174003)(13464003)(24454002)(189002)(199002)(51914003)(19580405001)(69226001)(80976001)(83322001)(2656002)(15975445006)(81686001)(19580395003)(81816001)(74876001)(81542001)(81342001)(56816005)(90146001)(87936001)(63696002)(79102001)(20776003)(65816001)(80022001)(33646001)(77982001)(59766001)(74316001)(85306002)(74366001)(74502001)(74662001)(31966008)(74706001)(87266001)(76786001)(76796001)(76576001)(77096001)(50986001)(54356001)(51856001)(46102001)(47736001)(47976001)(93136001)(95416001)(93516002)(4396001)(49866001)(97186001)(92566001)(94316002)(94946001)(86362001)(86612001)(53806001)(76482001)(95666003)(83072002)(56776001)(97336001)(85852003)(54316002)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR03MB023; H:BN1PR03MB023.namprd03.prod.outlook.com; FPR:E7BFC1A5.B7D2913E.BDC3BF6B.C2D41A43.20542; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (: microsoft.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/Nw7NMwhRjBJSIdsMVsMrQCqXVJo
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Mar 2014 14:52:17 -0000

Hello Bob and others,

I'm one of the authors of the draft. I'm new to writing IETF drafts, so I'l=
l defer to my co-authors on the debate over intended status. The current pl=
an is to switch this to Informational in the next version.

I agree that we should document any known limitations with DCTCP. I don't h=
ave any data on the effect of lost ACKs, but I will mention that dropped AC=
Ks degrade the congestion estimate. In the deployment issues section, I wil=
l make it clear that there is no negotiation. I'll also mention the RTT fai=
rness issue. Anything else specifically that you'd like to see covered?

I think Lars has already made this clear, but just to reiterate, our primar=
y goals for documenting DCTCP were to provide a mechanism for the IPR discl=
osure and to document Windows behavior for the benefit of other stacks that=
 would like to interoperate. There are some sizable DCTCP deployments, and =
thus, there has been some interest from non-Microsoft vendors to implement =
DCTCP. We hope to facilitate this by providing quality documentation and a =
royalty-free license.

If there is interest in doing further congestion control improvements for d=
atacenters, I'm happy to participate, but perhaps this draft isn't the best=
 vehicle for that.

Thanks for the feedback,
Stephen Bensley

-----Original Message-----
From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe
Sent: Tuesday, March 11, 2014 7:26 AM
To: Scharf, Michael (Michael); Martin Stiemerling; gorry@erg.abdn.ac.uk; Ri=
chard Scheffenegger
Cc: tcpm IETF list
Subject: Re: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?

Gorry, Michael, Martin, Richard,

I would be happy with INF as long as the outstanding issues were clearly id=
entified (feedback broken, no negotiation of alternate wire protocol, deplo=
yment applicability, etc)

The main reason for suggesting HISTORIC was to avoid people getting the imp=
ression the protocol as currently implemented is good to go on the public I=
nternet.


Bob

At 09:28 10/03/2014, Gorry Fairhurst wrote:
>This seems sensible to me, get WG comments feedback for an individual=20
>submission (via AD) and propose as INFO. If there is feedback by the=20
>authors they want it to be HISTORIC, that would be OK also.
>
>To me, it would need careful crafting of the abstract to explain the=20
>current position with respect to other work in this area.
>
>Gorry
>
>On 09/03/2014 11:02, Scharf, Michael (Michael) wrote:
>>Hi Bob,
>>
>>I think we should encourage that implementers document widely deployed=20
>>TCP mechanism in the RFC series, if they are willing to discuss with=20
>>the IETF and improve document clarity so that the document is a good,=20
>>informational description that can be used as reference. (This thought=20
>>is actually independent of DCTCP.)
>>
>>If implementers are responsive to questions, such informational=20
>>documentation (possible as AD-sponsored document) should actually be=20
>>possible rather quickly. This almost likely implies that the RFC=20
>>documents a mechanism that is still in use at the time of publication.=20
>>To me, this is not "historic".
>>
>>I could imagine that a Proposed Standard produced by the IETF changes=20
>>the status to "Historic" at a later stage. But even then I'd ask=20
>>whether the Proposed Standard indeed describes what is deployed, or=20
>>will be deployed, at large scale in the Internet.
>>
>>Thanks
>>
>>Michael (as individual contributor)
>>
>>
>>
>>>-----Original Message-----
>>>From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe
>>>Sent: Thursday, March 06, 2014 3:52 PM
>>>To: EGGERT, Lars; Martin Stiemerling
>>>Cc: tcpm IETF list
>>>Subject: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
>>>
>>>Lars,
>>>
>>>Everyone seems to agree this should be independent stream. That=20
>>>leaves the question of intended status...
>>>
>>>Imagine Microsoft now updates DCTCP to fix the feedback flaw. Then do=20
>>>you want to update this draft? I doubt it.
>>>
>>>So, IMO if you wanted to only document what Microsoft did, even tho=20
>>>it was  broken, then this should be HISTORIC, not INFORMATIONAL.
>>>
>>>If it's INFORMATIONAL it should at least fix known major problems=20
>>>before it is published.
>>>
>>>
>>>
>>>Bob
>>>
>>>
>>>
>>>________________________________________________________________
>>>Bob Briscoe,                                                  BT
>>>
>>>_______________________________________________
>>>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
>
>________________________________________________________________
>Bob Briscoe,                                                  BT=20

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm


From nobody Thu Mar 13 08:02:09 2014
Return-Path: <bill.wu@huawei.com>
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 EA7901A093B for <tcpm@ietfa.amsl.com>; Thu, 13 Mar 2014 03:35:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.747
X-Spam-Level: 
X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 x1ahIwOlam4u for <tcpm@ietfa.amsl.com>; Thu, 13 Mar 2014 03:35:16 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F22251A09B4 for <tcpm@ietf.org>; Thu, 13 Mar 2014 03:35:14 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCA48129; Thu, 13 Mar 2014 10:35:08 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Mar 2014 10:34:12 +0000
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Mar 2014 10:35:06 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 13 Mar 2014 18:35:01 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Joe Touch <touch@isi.edu>, "Diego R. Lopez" <diego@tid.es>, "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: [tcpm] Looking for advice on a draft from the PCE working group
Thread-Index: AQHPPSQOPWN7uGul1keGON95aVpVwJrb9joAgALQHnA=
Date: Thu, 13 Mar 2014 10:35:01 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA8450865B@nkgeml501-mbs.china.huawei.com>
References: <FDC308AD-096A-4FB7-AAA1-B6FAA1660F85@tid.es> <531F918C.2080700@isi.edu>
In-Reply-To: <531F918C.2080700@isi.edu>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.41.149]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA8450865Bnkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/xV0pUHl5dzY3bWpxD9RbzcOZ6RI
X-Mailman-Approved-At: Thu, 13 Mar 2014 08:02:07 -0700
Cc: "draft-ietf-pce-pceps@tools.ietf.org" <draft-ietf-pce-pceps@tools.ietf.org>
Subject: Re: [tcpm] Looking for advice on a draft from the PCE working group
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Mar 2014 10:35:20 -0000

--_000_B8F9A780D330094D99AF023C5877DABA8450865Bnkgeml501mbschi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksIEpvZToNCkl0IGlzIHN0aWxsIG5vdCBjbGVhciB0byBtZSB3aGVuIHdlIGNob29zZSB0aGUg
c2FtZSBwb3J0IGFuZCB3aGVuIHdlIGNob29zZSB0aGUgZGlmZmVyZW50IHBvcnQgaWYgd2UgYXBw
bHkgVExTIHRvIGRpZmZlcmVudCBwcm90b2NvbHMsDQpUYWtlIFNNVFAsIFBPUDMsSU1BUCBhcyBl
eGFtcGxlczoNClByb3RvY29sDQoNClB1cnBvc2UNCg0KTm9ybWFsIHBvcnQNCg0KU1NMIHZhcmlh
bnQNCg0KU1NMIHBvcnQNCg0KU01UUDxodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL1NNVFA+
DQoNClNlbmQgZW1haWwNCg0KMjUvNTg3DQoNClNNVFBTPGh0dHA6Ly9lbi53aWtpcGVkaWEub3Jn
L3dpa2kvU01UUFM+DQoNCjQ2NVs1XTxodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL1NUQVJU
VExTI2NpdGVfbm90ZS01Pg0KDQpQT1AzPGh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvUE9Q
Mz4NCg0KUmV0cmlldmUgZW1haWwNCg0KMTEwDQoNClBPUDNTPGh0dHA6Ly9lbi53aWtpcGVkaWEu
b3JnL3cvaW5kZXgucGhwP3RpdGxlPVBPUDNTJmFjdGlvbj1lZGl0JnJlZGxpbms9MT4NCg0KOTk1
DQoNCklNQVA8aHR0cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9JTUFQPg0KDQpSZWFkIGVtYWls
DQoNCjE0Mw0KDQpJTUFQUzxodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0lNQVBTPg0KDQo5
OTMNCg0KDQoNCg0KSXQgbG9va3MgdG8gbWUgd2hlbiB3ZSBhcHBseSBTU0wgdG8gU01UUCxQT1Az
LElNQVAsIHRoZW4gU01UUCwgUE9QMyBhbmQgSU1BUCB3aXRoIFNTTCBzdXBwb3J0KGkuZS4sU01U
UFMsUE9QM1MsSU1BUFMpDQoNCldpbGwgdXN1YWxseSBjaG9vc2UgdGhlIGRpZmZlcmVudCBwb3J0
cy4NCg0KDQoNClRoZSBzYW1lIHJ1bGUgYWJvdmUgaXMgYWxzbyBhcHBsaWVkIHRvIEhUVFAgd2hl
biB3ZSBhcHBseSBTU0wgdG8gSFRUUChpLmUuLCBIVFRQUykuDQoNCg0KDQpSZWdhcmRzIQ0KDQot
UWluDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2UgVG91Y2ggW21haWx0
bzp0b3VjaEBpc2kuZWR1XQ0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAxMiwgMjAxNCA2OjQzIEFN
DQpUbzogRGllZ28gUi4gTG9wZXo7IHRjcG1AaWV0Zi5vcmcNCkNjOiBkcmFmdC1pZXRmLXBjZS1w
Y2Vwc0B0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0Y3BtXSBMb29raW5nIGZvciBhZHZp
Y2Ugb24gYSBkcmFmdCBmcm9tIHRoZSBQQ0Ugd29ya2luZyBncm91cA0KDQoNCg0KU29tZSBjb21t
ZW50czoNCg0KDQoNCi0gdGhlIHRpdGxlIHNob3VsZCBiZSBjaGFuZ2VkIHRvIGZvY3VzIG9uIFRM
UzsgdGhlIHRlcm0gInRyYW5zcG9ydA0KDQpzZWN1cml0eSIgbWVhbnMgZGlmZmVyZW50IHRoaW5n
cyB0byBkaWZmZXJlbnQgcGVvcGxlLg0KDQoNCg0KLSBDb250cmFyeSB0byB0aGUgY2xhaW0gaW4g
dGhlIEludHJvZHVjdGlubywgUkZDNTQ0MCBtYWtlcyB2ZXJ5IHNwZWNpZmljDQoNCnJlcXVpcmVt
ZW50cyBvbiBQQ0VQLCBlLmcuLCBpdCBNVVNUIHVzZSBUQ1AgTUQ1DQoNCg0KDQp0aGlzIGRvY3Vt
ZW50IGFwcGVhcnMgdG8gb3ZlcnJpZGUgdGhhdCByZXF1aXJlbWVudCB3aXRoIFRDUC1BTzsgd2hp
bGUgSQ0KDQpzdXBwb3J0IHRoYXQsIHRoZSBjaGFuZ2UgbmVlZHMgdG8gYmUgbW9yZSBleHBsaWNp
dA0KDQoNCg0KLSBJIGRpc2FncmVlIHdpdGggdGhlIG5lZWQgZm9yICh5ZXQgYW5vdGhlcikgcG9y
dCBmb3IgYSBUTFMtZW5hYmxlZA0KDQpQQ0VQOyBTVEFSVFRMUyBhbGxvd3MgdGhlIHVzZSBvZiBU
TFMgdG8gYmUgbmVnb3RpYXRlZCBpbi1iYW5kLCBhbmQgc28NCg0KdGhlIGV4aXN0aW5nIHBvcnQg
c2hvdWxkIGJlIHVzZWQNCg0KDQoNCkpvZQ0KDQoNCg0KDQoNCk9uIDMvMTEvMjAxNCA1OjE4IEFN
LCBEaWVnbyBSLiBMb3BleiB3cm90ZToNCg0KPiBIaSwNCg0KPg0KDQo+IFRoZXJlIGlzIGEgZHJh
ZnQsIHJlY2VudGx5IGFkb3B0ZWQgYnkgdGhlIFBDRSBXRywgb24gcnVubmluZyB0aGUgUENFUCBw
cm90b2NvbCBvbiB0b3Agb2YgVExTLiBEdXJpbmcgdGhlIGRpc2N1c3Npb24gb2YgdGhpcyBkcmFm
dCBzZXZlcmFsIGlzc3VlcyByZWdhcmRpbmcgdHJhbnNwb3J0IGFzcGVjdHMgd2VyZSByYWlzZWQs
IGVzc2VudGlhbGx5IGRlYWxpbmcgd2l0aCB0aGUgdXNhZ2Ugb2YgVENQIHNlY3VyaXR5IG9wdGlv
bnMgYW5kIHdpdGggdGhlIG5lZWQgZm9yIHJlcXVpcmluZyBhIHNlcGFyYXRlIHBvcnQgZnJvbSB0
aGUgInBsYWluIiBQQ0VQLiBUaGUgV0cgZGVjaWRlZCB0byBzZWVrIGZvciBhZHZpY2UgZnJvbSB0
aGUgdHJhbnNwb3J0IGNvbW11bml0eSBhbmQgdGhlIEFEcyBwb2ludGVkIG1lIHRvIHRoaXMgbGlz
dCBhcyB0aGUgbW9zdCBhcHByb3ByaWF0ZSBwbGFjZSBmb3Igc3VjaCBhbiBhZHZpY2UuDQoNCj4N
Cg0KPiBZb3UgaGF2ZSB0aGUgdGV4dCBvZiB0aGUgZHJhZnQgYXZhaWxhYmxlIHRocm91Z2ggaHR0
cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1wY2UtcGNlcHMvDQoNCj4N
Cg0KPiBBbnkgZmVlZGJhY2sgb24gdGhlIGFib3ZlIG1lbnRpb25lZCBpc3N1ZXMgb3IgYW55dGhp
bmcgZWxzZSB5b3Ugc2VlIGluIHRoZSBkb2N1bWVudCB3aWxsIGJlIGV4dHJlbWVseSB3ZWxjb21l
Lg0KDQo+DQoNCj4gQmUgZ29vZGUsDQoNCj4gLS0NCg0KPiAiRXN0YSB2ZXogbm8gZmFsbGFyZW1v
cywgRG9jdG9yIEluZmllcm5vIg0KDQo+DQoNCj4gRHIgRGllZ28gUi4gTG9wZXoNCg0KPiBUZWxl
Zm9uaWNhIEkrRA0KDQo+IGh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6Lw0KDQo+DQoN
Cj4gZS1tYWlsOiBkaWVnb0B0aWQuZXMNCg0KPiBUZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0KDQo+
IE1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCg0KPg0KDQo+DQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCg0KPg0KDQo+IEVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBz
dSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbD
rW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVh
ZG8gbcOhcyBhYmFqby4NCg0KPiBUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkg
Zm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUg
YmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQ6DQoNCj4gaHR0cDovL3d3dy50aWQuZXMvRVMv
UEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgNCg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KDQo+IHRjcG0gbWFpbGluZyBsaXN0DQoNCj4gdGNwbUBpZXRm
Lm9yZw0KDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbQ0KDQo+
DQo=

--_000_B8F9A780D330094D99AF023C5877DABA8450865Bnkgeml501mbschi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBh
bm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERl
ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ
e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7
DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv
SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv
d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYu
TXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi
57qv5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K
CWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0KcHJlDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hh
ciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy
LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5
bGUtbmFtZToi57qv5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t
c3R5bGUtbGluazrnuq/mlofmnKw7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5IVE1M
Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJ
Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLmg1MQ0KCXttc28tc3R5bGUtbmFtZTpo
NTE7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglmb250LXdlaWdodDpib2xkO30NCi5N
c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRT
ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3
Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K
LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl
eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0
ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6
ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t
Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi
Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCBK
b2U6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyBzdGlsbCBub3Qg
Y2xlYXIgdG8gbWUgd2hlbiB3ZSBjaG9vc2UgdGhlIHNhbWUgcG9ydCBhbmQgd2hlbiB3ZSBjaG9v
c2UgdGhlIGRpZmZlcmVudCBwb3J0IGlmIHdlIGFwcGx5IFRMUyB0byBkaWZmZXJlbnQgcHJvdG9j
b2xzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGFrZSBTTVRQLCBQT1Az
LElNQVAgYXMgZXhhbXBsZXM6PG86cD48L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1h
bFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBz
dHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxiPlByb3RvY29s
PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48
L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVw
dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGln
bjpjZW50ZXIiPjxiPlB1cnBvc2U8L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi
PjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43
NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50
ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PGI+Tm9ybWFsIHBvcnQ8L2I+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L3Rk
Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PGI+
U1NMIHZhcmlhbnQ8L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9v
OnA+PC9zcGFuPjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0
IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxl
PSJ0ZXh0LWFsaWduOmNlbnRlciI+PGI+U1NMIHBvcnQ8L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L3RkPg0KPC90cj4NCjx0
cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL1NNVFAi
IHRpdGxlPSJTTVRQIj5TTVRQPC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0
IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlbmQgZW1haWw8c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBz
dHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4yNS81ODc8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVw
dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vZW4ud2lraXBlZGlhLm9y
Zy93aWtpL1NNVFBTIiB0aXRsZT0iU01UUFMiPlNNVFBTPC9hPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRk
aW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjQ2NTxz
dXAgaWQ9ImNpdGVfcmVmLTUiPjxhIGhyZWY9Imh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kv
U1RBUlRUTFMjY2l0ZV9ub3RlLTUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj5bNV08L3NwYW4+
PC9hPjwvc3VwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVw
dCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vZW4u
d2lraXBlZGlhLm9yZy93aWtpL1BPUDMiIHRpdGxlPSJQT1AzIj5QT1AzPC9hPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHN0
eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlJldHJpZXZlIGVtYWlsPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1
cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MTEwPHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRp
bmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJl
Zj0iaHR0cDovL2VuLndpa2lwZWRpYS5vcmcvdy9pbmRleC5waHA/dGl0bGU9UE9QM1MmYW1wO2Fj
dGlvbj1lZGl0JmFtcDtyZWRsaW5rPTEiIHRpdGxlPSJQT1AzUyAocGFnZSBkb2VzIG5vdCBleGlz
dCkiPlBPUDNTPC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43
NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjk5NTxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu
MHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHls
ZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48YSBocmVmPSJodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0lNQVAiIHRpdGxlPSJJTUFQ
Ij5JTUFQPC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlYWQgZW1haWw8c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGlu
ZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xNDM8c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4N
Cjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0lNQVBTIiB0
aXRsZT0iSU1BUFMiPklNQVBTPC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0
IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjk5MzxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJv
ZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JdCBsb29rcyB0byBtZSB3aGVuIHdlIGFwcGx5
IFNTTCB0byBTTVRQLFBPUDMsSU1BUCwgdGhlbiBTTVRQLCBQT1AzIGFuZCBJTUFQIHdpdGggU1NM
IHN1cHBvcnQoaS5lLixTTVRQUyxQT1AzUyxJTUFQUyk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPldpbGwgdXN1YWxseSBjaG9vc2UgdGhlIGRpZmZlcmVudCBwb3J0cy48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIHNhbWUgcnVsZSBhYm92ZSBpcyBhbHNv
IGFwcGxpZWQgdG8gSFRUUCB3aGVuIHdlIGFwcGx5IFNTTCB0byBIVFRQKGkuZS4sIEhUVFBTKS48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SZWdh
cmRzITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LVFpbjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS08YnI+DQpGcm9tOiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBpc2kuZWR1XSA8YnI+DQpTZW50
OiBXZWRuZXNkYXksIE1hcmNoIDEyLCAyMDE0IDY6NDMgQU08YnI+DQpUbzogRGllZ28gUi4gTG9w
ZXo7IHRjcG1AaWV0Zi5vcmc8YnI+DQpDYzogZHJhZnQtaWV0Zi1wY2UtcGNlcHNAdG9vbHMuaWV0
Zi5vcmc8YnI+DQpTdWJqZWN0OiBSZTogW3RjcG1dIExvb2tpbmcgZm9yIGFkdmljZSBvbiBhIGRy
YWZ0IGZyb20gdGhlIFBDRSB3b3JraW5nIGdyb3VwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPlNvbWUgY29tbWVudHM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0gdGhlIHRp
dGxlIHNob3VsZCBiZSBjaGFuZ2VkIHRvIGZvY3VzIG9uIFRMUzsgdGhlIHRlcm0gJnF1b3Q7dHJh
bnNwb3J0DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnNlY3VyaXR5
JnF1b3Q7IG1lYW5zIGRpZmZlcmVudCB0aGluZ3MgdG8gZGlmZmVyZW50IHBlb3BsZS48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LSBDb250cmFyeSB0byB0aGUgY2xhaW0gaW4gdGhlIElu
dHJvZHVjdGlubywgUkZDNTQ0MCBtYWtlcyB2ZXJ5IHNwZWNpZmljDQo8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnJlcXVpcmVtZW50cyBvbiBQQ0VQLCBlLmcuLCBpdCBN
VVNUIHVzZSBUQ1AgTUQ1PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnRoaXMgZG9jdW1l
bnQgYXBwZWFycyB0byBvdmVycmlkZSB0aGF0IHJlcXVpcmVtZW50IHdpdGggVENQLUFPOyB3aGls
ZSBJDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnN1cHBvcnQgdGhh
dCwgdGhlIGNoYW5nZSBuZWVkcyB0byBiZSBtb3JlIGV4cGxpY2l0PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPi0gSSBkaXNhZ3JlZSB3aXRoIHRoZSBuZWVkIGZvciAoeWV0IGFub3RoZXIp
IHBvcnQgZm9yIGEgVExTLWVuYWJsZWQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+UENFUDsgU1RBUlRUTFMgYWxsb3dzIHRoZSB1c2Ugb2YgVExTIHRvIGJlIG5lZ290
aWF0ZWQgaW4tYmFuZCwgYW5kIHNvDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPnRoZSBleGlzdGluZyBwb3J0IHNob3VsZCBiZSB1c2VkPG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPkpvZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk9uIDMvMTEvMjAxNCA1OjE4IEFN
LCBEaWVnbyBSLiBMb3BleiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPiZndDsgSGksPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m
Z3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRo
ZXJlIGlzIGEgZHJhZnQsIHJlY2VudGx5IGFkb3B0ZWQgYnkgdGhlIFBDRSBXRywgb24gcnVubmlu
ZyB0aGUgUENFUCBwcm90b2NvbCBvbiB0b3Agb2YgVExTLiBEdXJpbmcgdGhlIGRpc2N1c3Npb24g
b2YgdGhpcyBkcmFmdCBzZXZlcmFsIGlzc3VlcyByZWdhcmRpbmcgdHJhbnNwb3J0IGFzcGVjdHMg
d2VyZSByYWlzZWQsIGVzc2VudGlhbGx5IGRlYWxpbmcgd2l0aCB0aGUgdXNhZ2Ugb2YgVENQIHNl
Y3VyaXR5DQogb3B0aW9ucyBhbmQgd2l0aCB0aGUgbmVlZCBmb3IgcmVxdWlyaW5nIGEgc2VwYXJh
dGUgcG9ydCBmcm9tIHRoZSAmcXVvdDtwbGFpbiZxdW90OyBQQ0VQLiBUaGUgV0cgZGVjaWRlZCB0
byBzZWVrIGZvciBhZHZpY2UgZnJvbSB0aGUgdHJhbnNwb3J0IGNvbW11bml0eSBhbmQgdGhlIEFE
cyBwb2ludGVkIG1lIHRvIHRoaXMgbGlzdCBhcyB0aGUgbW9zdCBhcHByb3ByaWF0ZSBwbGFjZSBm
b3Igc3VjaCBhbiBhZHZpY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7
IFlvdSBoYXZlIHRoZSB0ZXh0IG9mIHRoZSBkcmFmdCBhdmFpbGFibGUgdGhyb3VnaCBodHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXBjZS1wY2Vwcy88bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgQW55IGZlZWRiYWNrIG9uIHRoZSBhYm92ZSBt
ZW50aW9uZWQgaXNzdWVzIG9yIGFueXRoaW5nIGVsc2UgeW91IHNlZSBpbiB0aGUgZG9jdW1lbnQg
d2lsbCBiZSBleHRyZW1lbHkgd2VsY29tZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPiZndDsgQmUgZ29vZGUsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij4mZ3Q7IC0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICZx
dW90O0VzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyZxdW90OzxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBEciBEaWVnbyBSLiBMb3BlejxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUZWxlZm9uaWNhIEkmIzQzO0Q8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgaHR0cDovL3Blb3Bs
ZS50aWQuZXMvZGllZ28ubG9wZXovPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m
Z3Q7IGUtbWFpbDogZGllZ29AdGlkLmVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij4mZ3Q7IFRlbDombmJzcDsmbmJzcDsmbmJzcDsgJiM0MzszNCA5MTMgMTI5IDA0MTxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBNb2JpbGU6ICYjNDM7
MzQgNjgyIDA1MSAwOTE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn
dDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDs8bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgRXN0ZSBtZW5zYWplIHNlIGRpcmln
ZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFyIG51ZXN0
cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVsZWN0csOzbmlj
byBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZl
bHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0
aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQ6PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xh
aW1lci5hc3B4PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHRjcG0gbWFpbGluZyBsaXN0PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHRjcG1AaWV0Zi5vcmc8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv
aHRtbD4NCg==

--_000_B8F9A780D330094D99AF023C5877DABA8450865Bnkgeml501mbschi_--


From nobody Thu Mar 13 08:11:06 2014
Return-Path: <gorry@erg.abdn.ac.uk>
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 48C321A09F1 for <tcpm@ietfa.amsl.com>; Thu, 13 Mar 2014 08:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.148
X-Spam-Level: 
X-Spam-Status: No, score=-4.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 rhPQkbXhSR_o for <tcpm@ietfa.amsl.com>; Thu, 13 Mar 2014 08:11:00 -0700 (PDT)
Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB781A09CD for <tcpm@ietf.org>; Thu, 13 Mar 2014 08:11:00 -0700 (PDT)
Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 7127D2B4522; Thu, 13 Mar 2014 15:10:53 +0000 (GMT)
Received: from ERG-research.local (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 460762B41D5; Thu, 13 Mar 2014 15:10:51 +0000 (GMT)
Message-ID: <5321CA7A.60302@erg.abdn.ac.uk>
Date: Thu, 13 Mar 2014 15:10:50 +0000
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
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:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Qin Wu <bill.wu@huawei.com>, Joe Touch <touch@isi.edu>,  "Diego R. Lopez" <diego@tid.es>, "tcpm@ietf.org" <tcpm@ietf.org>
References: <FDC308AD-096A-4FB7-AAA1-B6FAA1660F85@tid.es> <531F918C.2080700@isi.edu> <B8F9A780D330094D99AF023C5877DABA8450865B@nkgeml501-mbs.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA8450865B@nkgeml501-mbs.china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/UVcMRWp_nqRWHkNJZyjVHB__QKM
Cc: "draft-ietf-pce-pceps@tools.ietf.org" <draft-ietf-pce-pceps@tools.ietf.org>
Subject: Re: [tcpm] Looking for advice on a draft from the PCE working group
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 <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Mar 2014 15:11:03 -0000

Some of these started off as insecure protocols where security was a 
later addition. This draft may help (it's about to be WGLC'ed in the 
Transport Area WG):

http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-03

Gorry

On 13/03/2014 10:35, Qin Wu wrote:
> Hi, Joe:
> It is still not clear to me when we choose the same port and when we choose the different port if we apply TLS to different protocols,
> Take SMTP, POP3,IMAP as examples:
> Protocol
>
> Purpose
>
> Normal port
>
> SSL variant
>
> SSL port
>
> SMTP<http://en.wikipedia.org/wiki/SMTP>
>
> Send email
>
> 25/587
>
> SMTPS<http://en.wikipedia.org/wiki/SMTPS>
>
> 465[5]<http://en.wikipedia.org/wiki/STARTTLS#cite_note-5>
>
> POP3<http://en.wikipedia.org/wiki/POP3>
>
> Retrieve email
>
> 110
>
> POP3S<http://en.wikipedia.org/w/index.php?title=POP3S&action=edit&redlink=1>
>
> 995
>
> IMAP<http://en.wikipedia.org/wiki/IMAP>
>
> Read email
>
> 143
>
> IMAPS<http://en.wikipedia.org/wiki/IMAPS>
>
> 993
>
>
>
>
> It looks to me when we apply SSL to SMTP,POP3,IMAP, then SMTP, POP3 and IMAP with SSL support(i.e.,SMTPS,POP3S,IMAPS)
>
> Will usually choose the different ports.
>
>
>
> The same rule above is also applied to HTTP when we apply SSL to HTTP(i.e., HTTPS).
>
>
>
> Regards!
>
> -Qin
>
> -----Original Message-----
> From: Joe Touch [mailto:touch@isi.edu]
> Sent: Wednesday, March 12, 2014 6:43 AM
> To: Diego R. Lopez; tcpm@ietf.org
> Cc: draft-ietf-pce-pceps@tools.ietf.org
> Subject: Re: [tcpm] Looking for advice on a draft from the PCE working group
>
>
>
> Some comments:
>
>
>
> - the title should be changed to focus on TLS; the term "transport
>
> security" means different things to different people.
>
>
>
> - Contrary to the claim in the Introductino, RFC5440 makes very specific
>
> requirements on PCEP, e.g., it MUST use TCP MD5
>
>
>
> this document appears to override that requirement with TCP-AO; while I
>
> support that, the change needs to be more explicit
>
>
>
> - I disagree with the need for (yet another) port for a TLS-enabled
>
> PCEP; STARTTLS allows the use of TLS to be negotiated in-band, and so
>
> the existing port should be used
>
>
>
> Joe
>
>
>
>
>
> On 3/11/2014 5:18 AM, Diego R. Lopez wrote:
>
>> Hi,
>
>>
>
>> There is a draft, recently adopted by the PCE WG, on running the PCEP protocol on top of TLS. During the discussion of this draft several issues regarding transport aspects were raised, essentially dealing with the usage of TCP security options and with the need for requiring a separate port from the "plain" PCEP. The WG decided to seek for advice from the transport community and the ADs pointed me to this list as the most appropriate place for such an advice.
>
>>
>
>> You have the text of the draft available through https://datatracker.ietf.org/doc/draft-ietf-pce-pceps/
>
>>
>
>> Any feedback on the above mentioned issues or anything else you see in the document will be extremely welcome.
>
>>
>
>> Be goode,
>
>> --
>
>> "Esta vez no fallaremos, Doctor Infierno"
>
>>
>
>> Dr Diego R. Lopez
>
>> Telefonica I+D
>
>> http://people.tid.es/diego.lopez/
>
>>
>
>> e-mail: diego@tid.es
>
>> Tel:    +34 913 129 041
>
>> Mobile: +34 682 051 091
>
>> -----------------------------------------
>
>>
>
>>
>
>> ________________________________
>
>>
>
>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
>
>> This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
>
>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>
>> _______________________________________________
>
>> 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 Mar 13 08:59:00 2014
Return-Path: <touch@isi.edu>
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 764831A0A18 for <tcpm@ietfa.amsl.com>; Thu, 13 Mar 2014 08:58:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.747
X-Spam-Level: 
X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 vpVA5JODIIiS for <tcpm@ietfa.amsl.com>; Thu, 13 Mar 2014 08:58:48 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4399B1A08ED for <tcpm@ietf.org>; Thu, 13 Mar 2014 08:58:48 -0700 (PDT)
Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s2DFvXrT015233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Mar 2014 08:57:48 -0700 (PDT)
Message-ID: <5321D570.60008@isi.edu>
Date: Thu, 13 Mar 2014 08:57:36 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Qin Wu <bill.wu@huawei.com>, "Diego R. Lopez" <diego@tid.es>, "tcpm@ietf.org" <tcpm@ietf.org>
References: <FDC308AD-096A-4FB7-AAA1-B6FAA1660F85@tid.es> <531F918C.2080700@isi.edu> <B8F9A780D330094D99AF023C5877DABA8450865B@nkgeml501-mbs.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA8450865B@nkgeml501-mbs.china.huawei.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/TC85doI4d7SyWHndcK15S8mKWsA
Cc: "draft-ietf-pce-pceps@tools.ietf.org" <draft-ietf-pce-pceps@tools.ietf.org>
Subject: Re: [tcpm] Looking for advice on a draft from the PCE working group
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Mar 2014 15:58:51 -0000

Hi, Qin,

On 3/13/2014 3:35 AM, Qin Wu wrote:
> Hi, Joe:
>
> It is still not clear to me when we choose the same port and when we
> choose the different port if we apply TLS to different protocols,

It's simple to determine:

	- if you designed your service before STARTTLS, then you needed
	a separate port

	- if you are designing your port now, you don't

> Take SMTP, POP3,IMAP as examples:
...
> It looks to me when we apply SSL to SMTP,POP3,IMAP, then SMTP, POP3 and
> IMAP with SSL support(i.e.,SMTPS,POP3S,IMAPS)
>
> Will usually choose the different ports.
>
> The same rule above is also applied to HTTP when we apply SSL to
> HTTP(i.e., HTTPS).

All of the above are good examples of the first part of the rule.

Note that we have other assignments that now would be declined, because 
we've learned to do better. E.g., there would not be a POP2 or POP3 
because we would expect POP to indicate the protocol version in-band. We 
also no longer assign multiple names for the same service, as was done 
for http/www, nor do we now assign multiple ports for the same service 
(80, 8080), nor do we now assign ports for development purposes  (http-dev).

We've learned to do better.

Joe


From nobody Fri Mar 14 04:36:22 2014
Return-Path: <bob.briscoe@bt.com>
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 3B31A1A0120 for <tcpm@ietfa.amsl.com>; Fri, 14 Mar 2014 04:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, 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 mr0qaBYp2UEB for <tcpm@ietfa.amsl.com>; Fri, 14 Mar 2014 04:36:16 -0700 (PDT)
Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 007561A010E for <tcpm@ietf.org>; Fri, 14 Mar 2014 04:36:15 -0700 (PDT)
Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 14 Mar 2014 11:36:03 +0000
Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 14 Mar 2014 11:36:06 +0000
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.347.0; Fri, 14 Mar 2014 11:36:03 +0000
Received: from BTP075694.jungle.bt.co.uk ([10.109.120.201])	by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s2EBZx2I015898;	Fri, 14 Mar 2014 11:36:00 GMT
Message-ID: <201403141136.s2EBZx2I015898@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 13 Mar 2014 19:05:02 +0000
To: Stephen Bensley <sbens@microsoft.com>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <c1a10e94e7194d07bc6f3ea010eb0d12@BN1PR03MB023.namprd03.pro d.outlook.com>
References: <201403061451.s26Epwcq006941@bagheera.jungle.bt.co.uk> <655C07320163294895BBADA28372AF5D213359@FR712WXCHMBA15.zeu.alcatel-lucent.com> <531D85A6.3020807@erg.abdn.ac.uk> <201403111425.s2BEPXxp002313@bagheera.jungle.bt.co.uk> <c1a10e94e7194d07bc6f3ea010eb0d12@BN1PR03MB023.namprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/_Np9RuJ2_dpc1ZxFrT7JxHsw9OU
Cc: Martin Stiemerling <mls.ietf@gmail.com>, tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Mar 2014 11:36:20 -0000

Stephen,

At 14:52 13/03/2014, Stephen Bensley wrote:
>Hello Bob and others,
>
>I'm one of the authors of the draft. I'm new to writing IETF drafts, 
>so I'll defer to my co-authors on the debate over intended status. 
>The current plan is to switch this to Informational in the next version.
>
>I agree that we should document any known limitations with DCTCP. I 
>don't have any data on the effect of lost ACKs, but I will mention 
>that dropped ACKs degrade the congestion estimate.

It's worse than that. Even if no ACKS have been dropped, the sender 
cannot know that no ACKs have been dropped, because every gap between 
delayed ACKS could represent a pure ACK loss. So the feedback is 
always highly ambiguous. If losses are extremely rare on ECN traffic, 
the ambiguity can be assumed not to exist. But as soon as there's a 
few losses, that assumption collapses and you have a very broken TCP protocol.

>In the deployment issues section, I will make it clear that there is 
>no negotiation. I'll also mention the RTT fairness issue. Anything 
>else specifically that you'd like to see covered?

For me personally, RTT fairness isn't an issue, and if it were for 
anyone else, they would have to deprecate TCP itself as well.

The only other concern I have is what people will do when they read 
an RFC that says Microsoft is using DCTCP, altho it has problems, but 
then the draft doesn't point to any solutions (because we are still 
working on them). Won't they conclude that they can use DCTCP as is, 
given MS is using it?

==The no.1 concern is capability negotiation. ==
There are very few codepoints left for negotiation, so if 
implementations appear that either burn up the remaining codepoints 
without agreement, or don't negotiate at all, the TCP wire protocol 
will become unusable with ECN. So the stakes are very high.

Win8 server already started us down this slippery slope, given it can 
use a different wire protocol without negotiation, so we need to fix 
this rapidly.

Superficially it seems safe because:
- the data centre template has to be turned on in Windows,
- it has to have negotiated ECN with the other end
- the RTT has to be below x (5ms from memory).

But what if one of our customers turns on the DC template in the 
Windows servers in one of the DCs we interconnect with the DCs of 
other customers? These TCPs will then start talking with other 
standard TCP implementations in other DCs, but using the ECN flags 
differently without the other end knowing. Chaos ensues.

>I think Lars has already made this clear, but just to reiterate, our 
>primary goals for documenting DCTCP were to provide a mechanism for 
>the IPR disclosure and to document Windows behavior for the benefit 
>of other stacks that would like to interoperate. There are some 
>sizable DCTCP deployments, and thus, there has been some interest 
>from non-Microsoft vendors to implement DCTCP. We hope to facilitate 
>this by providing quality documentation and a royalty-free license.

This must have involved quite a bit of work internally for no direct 
gain, so thank you for doing this.



>If there is interest in doing further congestion control 
>improvements for datacenters, I'm happy to participate, but perhaps 
>this draft isn't the best vehicle for that.

I think you were right to just document what you had done. 
Particularly to make the IPR position clear. And if you make the 
listed problems extremely clear, and point to solutions, I'll be happy.

Do you want me to point you at all the relevant background?

You will see a roadmap of the drafts I think are necessary on slide 
11 of a presentation I gave to TSVAREA about this last week 
(including your draft):
<http://bobbriscoe.net/presents/1403ietf/1403ecn-encap-guidelines.pdf>
To be clear, this roadmap has greater ambitions than just private data centres.


Bob


>Thanks for the feedback,
>Stephen Bensley
>
>-----Original Message-----
>From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe
>Sent: Tuesday, March 11, 2014 7:26 AM
>To: Scharf, Michael (Michael); Martin Stiemerling; 
>gorry@erg.abdn.ac.uk; Richard Scheffenegger
>Cc: tcpm IETF list
>Subject: Re: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
>
>Gorry, Michael, Martin, Richard,
>
>I would be happy with INF as long as the outstanding issues were 
>clearly identified (feedback broken, no negotiation of alternate 
>wire protocol, deployment applicability, etc)
>
>The main reason for suggesting HISTORIC was to avoid people getting 
>the impression the protocol as currently implemented is good to go 
>on the public Internet.
>
>
>Bob
>
>At 09:28 10/03/2014, Gorry Fairhurst wrote:
> >This seems sensible to me, get WG comments feedback for an individual
> >submission (via AD) and propose as INFO. If there is feedback by the
> >authors they want it to be HISTORIC, that would be OK also.
> >
> >To me, it would need careful crafting of the abstract to explain the
> >current position with respect to other work in this area.
> >
> >Gorry
> >
> >On 09/03/2014 11:02, Scharf, Michael (Michael) wrote:
> >>Hi Bob,
> >>
> >>I think we should encourage that implementers document widely deployed
> >>TCP mechanism in the RFC series, if they are willing to discuss with
> >>the IETF and improve document clarity so that the document is a good,
> >>informational description that can be used as reference. (This thought
> >>is actually independent of DCTCP.)
> >>
> >>If implementers are responsive to questions, such informational
> >>documentation (possible as AD-sponsored document) should actually be
> >>possible rather quickly. This almost likely implies that the RFC
> >>documents a mechanism that is still in use at the time of publication.
> >>To me, this is not "historic".
> >>
> >>I could imagine that a Proposed Standard produced by the IETF changes
> >>the status to "Historic" at a later stage. But even then I'd ask
> >>whether the Proposed Standard indeed describes what is deployed, or
> >>will be deployed, at large scale in the Internet.
> >>
> >>Thanks
> >>
> >>Michael (as individual contributor)
> >>
> >>
> >>
> >>>-----Original Message-----
> >>>From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe
> >>>Sent: Thursday, March 06, 2014 3:52 PM
> >>>To: EGGERT, Lars; Martin Stiemerling
> >>>Cc: tcpm IETF list
> >>>Subject: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
> >>>
> >>>Lars,
> >>>
> >>>Everyone seems to agree this should be independent stream. That
> >>>leaves the question of intended status...
> >>>
> >>>Imagine Microsoft now updates DCTCP to fix the feedback flaw. Then do
> >>>you want to update this draft? I doubt it.
> >>>
> >>>So, IMO if you wanted to only document what Microsoft did, even tho
> >>>it was  broken, then this should be HISTORIC, not INFORMATIONAL.
> >>>
> >>>If it's INFORMATIONAL it should at least fix known major problems
> >>>before it is published.
> >>>
> >>>
> >>>
> >>>Bob
> >>>
> >>>
> >>>
> >>>________________________________________________________________
> >>>Bob Briscoe,                                                  BT
> >>>
> >>>_______________________________________________
> >>>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
> >
> >________________________________________________________________
> >Bob Briscoe,                                                  BT
>
>_______________________________________________
>tcpm mailing list
>tcpm@ietf.org
>https://www.ietf.org/mailman/listinfo/tcpm

________________________________________________________________
Bob Briscoe,                                                  BT 


From nobody Fri Mar 14 19:27:44 2014
Return-Path: <sbens@microsoft.com>
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 57B311A027A for <tcpm@ietfa.amsl.com>; Fri, 14 Mar 2014 19:27:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 5yY907LVUIWa for <tcpm@ietfa.amsl.com>; Fri, 14 Mar 2014 19:27:40 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com [207.46.163.187]) by ietfa.amsl.com (Postfix) with ESMTP id B037A1A0279 for <tcpm@ietf.org>; Fri, 14 Mar 2014 19:27:39 -0700 (PDT)
Received: from BN1PR03MB023.namprd03.prod.outlook.com (10.255.224.41) by BN1PR03MB022.namprd03.prod.outlook.com (10.255.224.40) with Microsoft SMTP Server (TLS) id 15.0.898.11; Sat, 15 Mar 2014 02:27:31 +0000
Received: from BN1PR03MB023.namprd03.prod.outlook.com ([169.254.6.228]) by BN1PR03MB023.namprd03.prod.outlook.com ([169.254.6.228]) with mapi id 15.00.0898.005; Sat, 15 Mar 2014 02:27:30 +0000
From: Stephen Bensley <sbens@microsoft.com>
To: Bob Briscoe <bob.briscoe@bt.com>
Thread-Topic: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
Thread-Index: AQHPOUuqAo6vz4uFNkGDCeAsqicfcZrYm3eAgAF4BwCAAeVxAIADJy2AgAFgf+6AAOzBsA==
Date: Sat, 15 Mar 2014 02:27:29 +0000
Message-ID: <6e10127330744b0b996ef6b49a3e0b3b@BN1PR03MB023.namprd03.prod.outlook.com>
References: <201403061451.s26Epwcq006941@bagheera.jungle.bt.co.uk> <655C07320163294895BBADA28372AF5D213359@FR712WXCHMBA15.zeu.alcatel-lucent.com> <531D85A6.3020807@erg.abdn.ac.uk> <201403111425.s2BEPXxp002313@bagheera.jungle.bt.co.uk> <c1a10e94e7194d07bc6f3ea010eb0d12@BN1PR03MB023.namprd03.prod.outlook.com> <201403141136.s2EBZx2I015898@bagheera.jungle.bt.co.uk>
In-Reply-To: <201403141136.s2EBZx2I015898@bagheera.jungle.bt.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.132.2.190]
x-forefront-prvs: 015114592F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(377454003)(479174003)(13464003)(24454002)(199002)(189002)(243025003)(51914003)(81542001)(74876001)(66066001)(2656002)(81342001)(80022001)(63696002)(65816001)(20776003)(81816001)(87936001)(56816005)(81686001)(69226001)(83322001)(19580405001)(19580395003)(80976001)(90146001)(33646001)(77982001)(59766001)(47446002)(74316001)(85306002)(74366001)(31966008)(74662001)(74502001)(15395725003)(87266001)(76786001)(76796001)(76576001)(77096001)(50986001)(76482001)(94946001)(92566001)(4396001)(54356001)(46102001)(51856001)(47736001)(97186001)(93516002)(49866001)(94316002)(54316002)(85852003)(86362001)(95666003)(53806001)(95416001)(47976001)(93136001)(97336001)(56776001)(83072002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR03MB022; H:BN1PR03MB023.namprd03.prod.outlook.com; FPR:E7BFF1E5.A4FA913E.FDD3BD4B.D2E68141.207C2; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (: microsoft.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/_tja3dlnNY9VA2UvxZU-S1VGT8M
Cc: Martin Stiemerling <mls.ietf@gmail.com>, tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Mar 2014 02:27:43 -0000

Hi Bob,

I don't think dropped ACKs are as bad as that. If a drop occurs during an u=
nbroken string of CE or non-CE packets, the congestion estimate is unaffect=
ed. If a drop occurs during a transition between CE and non-CE, then yes, t=
he estimate will be less accurate than it would be without drops. However, =
there are some mitigations:
- It may be that even with a less accurate congestion estimate, DCTCP still=
 performs better than RFC 3168.
- If the estimation gain is small enough relative to the packet loss rate, =
the estimate may not be degraded much.
- It may be that packet losses mostly occur under heavy congestion. In whic=
h case, most drops occur during an unbroken string of CE packets.=20

I'd need data about the distribution of CE events relative to packet drops =
to analyze the impact, and I don't have this data, so the above is all spec=
ulation. But DCTCP is successfully deployed in large datacenters today, so =
it works well in at least some environments.

For the case where one server uses DCTCP and the other implements standard =
RFC 3168 behavior, Lars had a graduate student who analyzed this situation =
in detail and proposed some improvements. We will add a reference to this p=
aper in the next version.

"Won't they conclude that they can use DCTCP as is, given MS is using it?"

I believe they can use DCTCP as is. I'm not opposed to developing something=
 better, but DCTCP seems to work well in practice.

-----Original Message-----
From: Bob Briscoe [mailto:bob.briscoe@bt.com]=20
Sent: Thursday, March 13, 2014 12:05 PM
To: Stephen Bensley
Cc: Scharf, Michael (Michael); Martin Stiemerling; gorry@erg.abdn.ac.uk; Ri=
chard Scheffenegger; tcpm IETF list
Subject: RE: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?

Stephen,

At 14:52 13/03/2014, Stephen Bensley wrote:
>Hello Bob and others,
>
>I'm one of the authors of the draft. I'm new to writing IETF drafts, so=20
>I'll defer to my co-authors on the debate over intended status.
>The current plan is to switch this to Informational in the next version.
>
>I agree that we should document any known limitations with DCTCP. I=20
>don't have any data on the effect of lost ACKs, but I will mention that=20
>dropped ACKs degrade the congestion estimate.

It's worse than that. Even if no ACKS have been dropped, the sender cannot =
know that no ACKs have been dropped, because every gap between delayed ACKS=
 could represent a pure ACK loss. So the feedback is always highly ambiguou=
s. If losses are extremely rare on ECN traffic, the ambiguity can be assume=
d not to exist. But as soon as there's a few losses, that assumption collap=
ses and you have a very broken TCP protocol.

>In the deployment issues section, I will make it clear that there is no=20
>negotiation. I'll also mention the RTT fairness issue. Anything else=20
>specifically that you'd like to see covered?

For me personally, RTT fairness isn't an issue, and if it were for anyone e=
lse, they would have to deprecate TCP itself as well.

The only other concern I have is what people will do when they read an RFC =
that says Microsoft is using DCTCP, altho it has problems, but then the dra=
ft doesn't point to any solutions (because we are still working on them). W=
on't they conclude that they can use DCTCP as is, given MS is using it?

=3D=3DThe no.1 concern is capability negotiation. =3D=3D There are very few=
 codepoints left for negotiation, so if implementations appear that either =
burn up the remaining codepoints without agreement, or don't negotiate at a=
ll, the TCP wire protocol will become unusable with ECN. So the stakes are =
very high.

Win8 server already started us down this slippery slope, given it can use a=
 different wire protocol without negotiation, so we need to fix this rapidl=
y.

Superficially it seems safe because:
- the data centre template has to be turned on in Windows,
- it has to have negotiated ECN with the other end
- the RTT has to be below x (5ms from memory).

But what if one of our customers turns on the DC template in the Windows se=
rvers in one of the DCs we interconnect with the DCs of other customers? Th=
ese TCPs will then start talking with other standard TCP implementations in=
 other DCs, but using the ECN flags differently without the other end knowi=
ng. Chaos ensues.

>I think Lars has already made this clear, but just to reiterate, our=20
>primary goals for documenting DCTCP were to provide a mechanism for the=20
>IPR disclosure and to document Windows behavior for the benefit of=20
>other stacks that would like to interoperate. There are some sizable=20
>DCTCP deployments, and thus, there has been some interest from=20
>non-Microsoft vendors to implement DCTCP. We hope to facilitate this by=20
>providing quality documentation and a royalty-free license.

This must have involved quite a bit of work internally for no direct gain, =
so thank you for doing this.



>If there is interest in doing further congestion control=20
>improvements for datacenters, I'm happy to participate, but perhaps=20
>this draft isn't the best vehicle for that.

I think you were right to just document what you had done.=20
Particularly to make the IPR position clear. And if you make the=20
listed problems extremely clear, and point to solutions, I'll be happy.

Do you want me to point you at all the relevant background?

You will see a roadmap of the drafts I think are necessary on slide=20
11 of a presentation I gave to TSVAREA about this last week=20
(including your draft):
<http://bobbriscoe.net/presents/1403ietf/1403ecn-encap-guidelines.pdf>
To be clear, this roadmap has greater ambitions than just private data cent=
res.


Bob


>Thanks for the feedback,
>Stephen Bensley
>
>-----Original Message-----
>From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe
>Sent: Tuesday, March 11, 2014 7:26 AM
>To: Scharf, Michael (Michael); Martin Stiemerling;=20
>gorry@erg.abdn.ac.uk; Richard Scheffenegger
>Cc: tcpm IETF list
>Subject: Re: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
>
>Gorry, Michael, Martin, Richard,
>
>I would be happy with INF as long as the outstanding issues were=20
>clearly identified (feedback broken, no negotiation of alternate=20
>wire protocol, deployment applicability, etc)
>
>The main reason for suggesting HISTORIC was to avoid people getting=20
>the impression the protocol as currently implemented is good to go=20
>on the public Internet.
>
>
>Bob
>
>At 09:28 10/03/2014, Gorry Fairhurst wrote:
> >This seems sensible to me, get WG comments feedback for an individual
> >submission (via AD) and propose as INFO. If there is feedback by the
> >authors they want it to be HISTORIC, that would be OK also.
> >
> >To me, it would need careful crafting of the abstract to explain the
> >current position with respect to other work in this area.
> >
> >Gorry
> >
> >On 09/03/2014 11:02, Scharf, Michael (Michael) wrote:
> >>Hi Bob,
> >>
> >>I think we should encourage that implementers document widely deployed
> >>TCP mechanism in the RFC series, if they are willing to discuss with
> >>the IETF and improve document clarity so that the document is a good,
> >>informational description that can be used as reference. (This thought
> >>is actually independent of DCTCP.)
> >>
> >>If implementers are responsive to questions, such informational
> >>documentation (possible as AD-sponsored document) should actually be
> >>possible rather quickly. This almost likely implies that the RFC
> >>documents a mechanism that is still in use at the time of publication.
> >>To me, this is not "historic".
> >>
> >>I could imagine that a Proposed Standard produced by the IETF changes
> >>the status to "Historic" at a later stage. But even then I'd ask
> >>whether the Proposed Standard indeed describes what is deployed, or
> >>will be deployed, at large scale in the Internet.
> >>
> >>Thanks
> >>
> >>Michael (as individual contributor)
> >>
> >>
> >>
> >>>-----Original Message-----
> >>>From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Bob Briscoe
> >>>Sent: Thursday, March 06, 2014 3:52 PM
> >>>To: EGGERT, Lars; Martin Stiemerling
> >>>Cc: tcpm IETF list
> >>>Subject: [tcpm] draft-bensley-tcpm-dctcp: INF or HISTORIC?
> >>>
> >>>Lars,
> >>>
> >>>Everyone seems to agree this should be independent stream. That
> >>>leaves the question of intended status...
> >>>
> >>>Imagine Microsoft now updates DCTCP to fix the feedback flaw. Then do
> >>>you want to update this draft? I doubt it.
> >>>
> >>>So, IMO if you wanted to only document what Microsoft did, even tho
> >>>it was  broken, then this should be HISTORIC, not INFORMATIONAL.
> >>>
> >>>If it's INFORMATIONAL it should at least fix known major problems
> >>>before it is published.
> >>>
> >>>
> >>>
> >>>Bob
> >>>
> >>>
> >>>
> >>>________________________________________________________________
> >>>Bob Briscoe,                                                  BT
> >>>
> >>>_______________________________________________
> >>>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
> >
> >________________________________________________________________
> >Bob Briscoe,                                                  BT
>
>_______________________________________________
>tcpm mailing list
>tcpm@ietf.org
>https://www.ietf.org/mailman/listinfo/tcpm

________________________________________________________________
Bob Briscoe,                                                  BT=20


From nobody Sun Mar 16 04:17:32 2014
Return-Path: <rs@netapp.com>
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 3555D1A02DD for <tcpm@ietfa.amsl.com>; Sun, 16 Mar 2014 04:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.449
X-Spam-Level: 
X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-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 0AtXeB7Sx06K for <tcpm@ietfa.amsl.com>; Sun, 16 Mar 2014 04:17:29 -0700 (PDT)
Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE891A00EF for <tcpm@ietf.org>; Sun, 16 Mar 2014 04:17:29 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.97,664,1389772800"; d="scan'208";a="150505522"
Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 16 Mar 2014 04:17:21 -0700
Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.03.0123.003; Sun, 16 Mar 2014 04:17:20 -0700
From: "Scheffenegger, Richard" <rs@netapp.com>
To: Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de>, Brian Trammell <trammell@tik.ee.ethz.ch>
Thread-Topic: AccECN semantics
Thread-Index: Ac9AV/5jgP8Aw1jgRQ6xQn461Eo16Q==
Date: Sun, 16 Mar 2014 11:17:20 +0000
Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F260F5701@SACEXCMBX02-PRD.hq.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.105.30]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/zSwsj9WNrAlERsraiYJZQcQK0FM
Cc: "tcpm \(tcpm@ietf.org\)" <tcpm@ietf.org>
Subject: [tcpm] AccECN semantics
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Mar 2014 11:17:31 -0000

Hi Mirja, Brian, group,


I'm currently testing, trying to follow what Mirja and you have described h=
ere:

http://tools.ietf.org/html/draft-kuehlewind-tcpm-ecn-fallback-01

but extending it a bit into the ambiguous region against a ECN receiver.

RFC3168 stipulates that pure control packets MUST NOT have ECT (thus no CE)=
 (section 6.1.4), but doesn't explicitly specify the receiver reaction, if =
a control packet is nevertheless received with CE...

With one ECN TCP stack I happened to have under test, the receiver actually=
 suppresses and conceals the CE information.=20

IMHO, the receiver should not make assumptions or remove information (a pat=
h still using TOS rather than DiffServ might be the cause - but it's up to =
the sender to detect that misbehavior).

I think the requirement given in 3168 about control packets MUST NOT carry =
ECT is sound, it probably would have been better a SHOULD NOT; but IMHO, th=
e receiver MUST reflect the ECT/CE once the session has negotiated ECN supp=
ort - to allow future extensions without having to modify the receiver agai=
n.

However, this might make the accounting more complex, as CE marks on pure A=
CKs, while no data is being sent, don't necessarily have to invoke a CC rea=
ction (other than ACK-CC) immediately.

Perhaps that should go into either AccEcn requirements, or one of the AccEC=
N mechanism drafts?


Any thoughts?

Richard Scheffenegger


From nobody Mon Mar 17 02:25:06 2014
Return-Path: <ietf@trammell.ch>
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 018451A0051 for <tcpm@ietfa.amsl.com>; Mon, 17 Mar 2014 02:25:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 f2p6vt7BfuPa for <tcpm@ietfa.amsl.com>; Mon, 17 Mar 2014 02:25:03 -0700 (PDT)
Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6F15D1A004A for <tcpm@ietf.org>; Mon, 17 Mar 2014 02:25:02 -0700 (PDT)
Received: from [IPv6:2001:67c:10ec:3ec2:8000::56] (unknown [IPv6:2001:67c:10ec:3ec2:8000::56]) by trammell.ch (Postfix) with ESMTPSA id 0A1911A1311; Mon, 17 Mar 2014 10:24:17 +0100 (CET)
Content-Type: multipart/signed; boundary="Apple-Mail=_B30156E2-5395-4320-BAD5-9B2D20188AF4"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F260F5701@SACEXCMBX02-PRD.hq.netapp.com>
Date: Mon, 17 Mar 2014 10:24:15 +0100
Message-Id: <EFA2335D-4D00-4106-89F8-12D0AA904323@trammell.ch>
References: <012C3117EDDB3C4781FD802A8C27DD4F260F5701@SACEXCMBX02-PRD.hq.netapp.com>
To: "Scheffenegger, Richard" <rs@netapp.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/EV7QjCP9My1H54eqHTaImqNyzlw
Cc: "tcpm \(tcpm@ietf.org\)" <tcpm@ietf.org>
Subject: Re: [tcpm] AccECN semantics
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Mar 2014 09:25:06 -0000

--Apple-Mail=_B30156E2-5395-4320-BAD5-9B2D20188AF4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Richard, all,

On 16 Mar 2014, at 12:17, Scheffenegger, Richard <rs@netapp.com> wrote:

> Hi Mirja, Brian, group,
>=20
> I'm currently testing, trying to follow what Mirja and you have =
described here:
>=20
> http://tools.ietf.org/html/draft-kuehlewind-tcpm-ecn-fallback-01
>=20
> but extending it a bit into the ambiguous region against a ECN =
receiver.

Very cool. Backing all this up with information about reality in the =
network is essential. :)

FWIW, though the draft expired last week, we do intend to develop it =
further. I have a student project that started last week to revisit the =
proportion of usable and unusable endpoints among popular servers (the =
2013 PAM paper), as well as to catalog ECN failure modes, and to =
determine the likelihood of mid-flow transition from ECN-usable to =
ECN-unusable as discussed in Vancouver. We intend to update the draft =
backed up by data produced by this work.

> RFC3168 stipulates that pure control packets MUST NOT have ECT (thus =
no CE) (section 6.1.4), but doesn't explicitly specify the receiver =
reaction, if a control packet is nevertheless received with CE...

It does point (non-normatively) in the direction of "future research":

                                      ... [m]echanisms for responding to
   congestion on the ACK-path are areas for current and future research.
   (One simple possibility would be for the sender to reduce its
   congestion window when it receives a pure ACK packet with the CE
   codepoint set).

> With one ECN TCP stack I happened to have under test, the receiver =
actually suppresses and conceals the CE information.=20

Interesting to see the stack didn't take the hint there. :) "suppresses =
and conceals" means no ECE, no reduction, and no information to the =
application layer?

> IMHO, the receiver should not make assumptions or remove information =
(a path still using TOS rather than DiffServ might be the cause - but =
it's up to the sender to detect that misbehavior).

Given how many flows we observed on the open Internet that were clearly =
misusing the ECT bits, the receiver should probably always assume that =
the sender is broken.

> I think the requirement given in 3168 about control packets MUST NOT =
carry ECT is sound, it probably would have been better a SHOULD NOT; but =
IMHO, the receiver MUST reflect the ECT/CE once the session has =
negotiated ECN support - to allow future extensions without having to =
modify the receiver again.
>=20
> However, this might make the accounting more complex, as CE marks on =
pure ACKs, while no data is being sent, don't necessarily have to invoke =
a CC reaction (other than ACK-CC) immediately.
>=20
> Perhaps that should go into either AccEcn requirements, or one of the =
AccECN mechanism drafts?

Well, "mechanisms for responding to congestion on the ACK-path are areas =
for ... future research" so maybe splitting that work out into another =
draft might scope the work a bit better. AccECN seems more complete than =
any of this at the moment...

Cheers,

Brian

--Apple-Mail=_B30156E2-5395-4320-BAD5-9B2D20188AF4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJTJr8/AAoJENt3nsOmbNJcoKEH/RZ7Wzs20g2hLwOcFFXlqCGA
T/V/nkd41aDpDvFlETeeBMTNvxy68MyRLNt3w47hG2+RM0xUzpMaEuoYXHEtv72Y
vn3t5PVqpn3RvCq+5WeGXwT5uRXg7rIxUYqGwqFvJEaTPLc7aFVbc6H3QfqWVEhY
LgqPBR7ntkkCJlKCGC/ov1ploHt9B4qaKwC/zexb4LwU5ATlUb69aGMXarHmMM49
defiY40GUl4p5RfCik0+82EQIxnFi1Sq12qEmfFw5MekzV5hGP2px0AEUqFA+ed/
Uh+MrtSSgG/laOEk3j8mVbUG49imNVkIdJ667KSCk5Andk26Ik/5dKa3goGt3W8=
=6dzx
-----END PGP SIGNATURE-----

--Apple-Mail=_B30156E2-5395-4320-BAD5-9B2D20188AF4--


From nobody Mon Mar 17 02:45:08 2014
Return-Path: <rs@netapp.com>
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 123CA1A00A2 for <tcpm@ietfa.amsl.com>; Mon, 17 Mar 2014 02:45:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.449
X-Spam-Level: 
X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-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 sANHzac5iIXJ for <tcpm@ietfa.amsl.com>; Mon, 17 Mar 2014 02:45:03 -0700 (PDT)
Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8896A1A004A for <tcpm@ietf.org>; Mon, 17 Mar 2014 02:45:03 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.97,668,1389772800"; d="scan'208";a="150639536"
Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx12-out.netapp.com with ESMTP; 17 Mar 2014 02:44:54 -0700
Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.77]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.03.0123.003; Mon, 17 Mar 2014 02:44:55 -0700
From: "Scheffenegger, Richard" <rs@netapp.com>
To: Brian Trammell <ietf@trammell.ch>
Thread-Topic: AccECN semantics
Thread-Index: Ac9AV/5jgP8Aw1jgRQ6xQn461Eo16QBpVgSAAA5cqNA=
Date: Mon, 17 Mar 2014 09:44:54 +0000
Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F260F7664@SACEXCMBX02-PRD.hq.netapp.com>
References: <012C3117EDDB3C4781FD802A8C27DD4F260F5701@SACEXCMBX02-PRD.hq.netapp.com> <EFA2335D-4D00-4106-89F8-12D0AA904323@trammell.ch>
In-Reply-To: <EFA2335D-4D00-4106-89F8-12D0AA904323@trammell.ch>
Accept-Language: de-AT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.106.53.53]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/aPO8e2HCde3NsrlgDxpWZO3zdPE
Cc: "tcpm \(tcpm@ietf.org\)" <tcpm@ietf.org>
Subject: Re: [tcpm] AccECN semantics
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Mar 2014 09:45:06 -0000

Hi Brian,


> > RFC3168 stipulates that pure control packets MUST NOT have ECT (thus no
> CE) (section 6.1.4), but doesn't explicitly specify the receiver reaction=
,
> if a control packet is nevertheless received with CE...
>=20
> It does point (non-normatively) in the direction of "future research":
>=20
>                                       ... [m]echanisms for responding to
>    congestion on the ACK-path are areas for current and future research.
>    (One simple possibility would be for the sender to reduce its
>    congestion window when it receives a pure ACK packet with the CE
>    codepoint set).
>=20
> > With one ECN TCP stack I happened to have under test, the receiver
> actually suppresses and conceals the CE information.
>=20
> Interesting to see the stack didn't take the hint there. :) "suppresses
> and conceals" means no ECE, no reduction, and no information to the
> application layer?

Well, I was only looking at the network layer without checking application =
sockets directly; Also, I'm concered at this point about the receiver behav=
ior rather than the sender behavior.

ECE's reflected during phases where the sender only ACKs data from the rece=
iver - that is, data is only flowing in the reverse direction - wouldn't ne=
ed to actually reduce the cwnd on the sender (which is not sending data any=
way, at that point. But they could reveal ACK-path congestion, which *may* =
help during cwnd validation phases etc.



>=20
> > IMHO, the receiver should not make assumptions or remove information (a
> path still using TOS rather than DiffServ might be the cause - but it's u=
p
> to the sender to detect that misbehavior).
>=20
> Given how many flows we observed on the open Internet that were clearly
> misusing the ECT bits, the receiver should probably always assume that th=
e
> sender is broken.

I take this as a statement of irony :)

ECN signaling is seriously impeded, but I think with we have a chance to ge=
t the end hosts right with the deployment of AccECN, we should be clear wha=
t the expected behavior *of the signaling alone* should be. Not leaving thi=
ngs ambiguous in the specs should make it easier to have implementations th=
at follow the spirit of the spec...=20


> > Perhaps that should go into either AccEcn requirements, or one of the
> AccECN mechanism drafts?
>=20
> Well, "mechanisms for responding to congestion on the ACK-path are areas
> for ... future research" so maybe splitting that work out into another
> draft might scope the work a bit better. AccECN seems more complete than
> any of this at the moment...

True, but we haven't yet any text that makes it clear if there should be a =
distinction between data and control segments. At least I assumed that the =
AccECN signal should be agnostic what type of segment the CE (ECT(0) /ECT(1=
)) was sent with...



Richard Scheffenegger


From nobody Mon Mar 17 12:23:54 2014
Return-Path: <pasi.sarolahti@iki.fi>
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 EFEF51A0488 for <tcpm@ietfa.amsl.com>; Mon, 17 Mar 2014 12:23:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 ywLI_7XWH4Gm for <tcpm@ietfa.amsl.com>; Mon, 17 Mar 2014 12:23:47 -0700 (PDT)
Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEEC1A0417 for <tcpm@ietf.org>; Mon, 17 Mar 2014 12:23:47 -0700 (PDT)
Received: from pasisarahtismbp.lan (80.223.92.46) by jenni1.inet.fi (8.5.140.03) (authenticated as saropa-1) id 527750DA0B3EE8A8 for tcpm@ietf.org; Mon, 17 Mar 2014 21:23:38 +0200
From: Pasi Sarolahti <pasi.sarolahti@iki.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <38B26AB6-8909-4601-92CE-0FB6C44355DE@iki.fi>
Date: Mon, 17 Mar 2014 21:23:35 +0200
To: "tcpm@ietf.org (tcpm@ietf.org)" <tcpm@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/37cmi_7h1iZTgzegxI1DX7Cmg_8
Subject: [tcpm] TCPM minutes from London
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Mar 2014 19:23:50 -0000

Hi,

The minutes also from the Thursday TCPM session have now been added to =
http://www.ietf.org/proceedings/89/minutes/minutes-89-tcpm . They can be =
found after the Monday minutes.

Thanks to Brian and Alexander for taking the notes!

- Pasi


From nobody Tue Mar 18 03:01:49 2014
Return-Path: <michael.scharf@alcatel-lucent.com>
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 EAA0C1A06A8 for <tcpm@ietfa.amsl.com>; Tue, 18 Mar 2014 03:01:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I08W8bRoVAxy for <tcpm@ietfa.amsl.com>; Tue, 18 Mar 2014 03:01:41 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 5016C1A0051 for <tcpm@ietf.org>; Tue, 18 Mar 2014 03:01:40 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2IA1UM3018911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <tcpm@ietf.org>; Tue, 18 Mar 2014 05:01:32 -0500 (CDT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2IA1Unw026382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <tcpm@ietf.org>; Tue, 18 Mar 2014 11:01:30 +0100
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 18 Mar 2014 11:01:30 +0100
From: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
To: tcpm IETF list <tcpm@ietf.org>
Thread-Topic: Intended status of draft-ietf-tcpm-newcwv - Confirmation of discussion during IETF 89
Thread-Index: Ac9CkQejKwbzWGacT/GEJPxAXXwu/Q==
Date: Tue, 18 Mar 2014 10:01:29 +0000
Message-ID: <655C07320163294895BBADA28372AF5D2314B7@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: http://mailarchive.ietf.org/arch/msg/tcpm/JmbTkT2lii09D8qXDo_wogF_Fig
Subject: [tcpm] Intended status of draft-ietf-tcpm-newcwv - Confirmation of discussion during IETF 89
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Mar 2014 10:01:47 -0000

Hi all,

In London, we had a long discussion on the TCPM charter milestone ("Decide =
the intended status of the document on TCP support for rate-limited traffic=
"). In the room there was strong consensus that this document should be hea=
ding for Experimental status, given that further experimentation and operat=
ional experience with the mechanism is needed (e.g., regarding pacing). If =
there are any further thoughts on this, please speak up on the list in the =
next two weeks.

In addition, draft-ietf-tcpm-newcwv recommends (for a long time already) to=
 move RFC 2861 from Experimental to Historic. According to the feedback in =
the room, the TCPM working group seems to agree on that. This message thus =
intends to confirm that obsoleting RFC 2861 is consensus of the TCPM workin=
g group. Please let us know in the next two weeks if you disagree.

This message just deals with the formal status of draft-ietf-tcpm-newcwv, i=
.e., it is independent of the ongoing review discussions.

Thanks

Michael, Pasi, Yoshifumi
=20


From nobody Tue Mar 18 04:42:59 2014
Return-Path: <mallman@icir.org>
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 D84D11A03C9 for <tcpm@ietfa.amsl.com>; Tue, 18 Mar 2014 04:42:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Hnw6iqx9tbwB for <tcpm@ietfa.amsl.com>; Tue, 18 Mar 2014 04:42:54 -0700 (PDT)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE5D1A03CC for <tcpm@ietf.org>; Tue, 18 Mar 2014 04:42:54 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id A29942C4013; Tue, 18 Mar 2014 04:42:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id d9OkZpQv9sWL; Tue, 18 Mar 2014 04:42:46 -0700 (PDT)
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 1E9312C4012; Tue, 18 Mar 2014 04:42:46 -0700 (PDT)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id D01952A9C2CF; Tue, 18 Mar 2014 07:42:42 -0400 (EDT)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1B5AA39C197E; Tue, 18 Mar 2014 07:42:42 -0400 (EDT)
To: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
From: Mark Allman <mallman@icir.org>
In-Reply-To: <655C07320163294895BBADA28372AF5D2314B7@FR712WXCHMBA15.zeu.alcatel-lucent.com>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Back in the Saddle
X-URL-0: http://www.icir.org/mallman-files/Document78928.doc
X-URL-1: http://www.icir.org/mallman-files/Document91098.html
X-URL-2: http://www.icir.org/mallman-files/Document6129.pdf
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma12593-1"; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Tue, 18 Mar 2014 07:42:42 -0400
Sender: mallman@icir.org
Message-Id: <20140318114242.1B5AA39C197E@lawyers.icir.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ihV6dnKqeqvAuXCsKLygywkjRXA
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] Intended status of draft-ietf-tcpm-newcwv - Confirmation of discussion during IETF 89
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mallman@icir.org
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Mar 2014 11:42:57 -0000

----------ma12593-1
Content-Type: text/plain
Content-Disposition: inline


My high order bit here is that the newcwv document isn't in very good
shape [per previous comments] and so its a little hard to have these
conversations in that context if you ask me.  And, so I'd suggest this
arbitrary two week period is premature.

However, to give a hit on the two questions you asked ...

> In the room there was strong consensus that this document should be
> heading for Experimental status, given that further experimentation
> and operational experience with the mechanism is needed (e.g.,
> regarding pacing).

If it is the pacing that is the reason for experimental instead of
proposed I'd disagree.  Pacing makes the imposed load on the network
less aggressive than current mechanisms and so I don't see any reason to
spin at experimental.  Not that there may not be a refining of our
understanding of pacing by actually doing it, but that the possibility
of harm to the network seems pretty small to me.

Now if the reason for experimental is that newcwv is more aggressive
than the current TCP spec recommends then perhaps that is a better
reason.  However, the flip side is that we have gotten by with no
downward adjustment based on cwnd use / non-use for a long time and so
relative to that newcwv is still more conservative and hence seems fine
for proposed.

(Of course, both these are modulo that I don't really yet understand or
buy newcwv because the document has yet to convince me we need something
new and/or that the new algorithm is reasonable.  But, I do have some
trust in the involved folks and so I figure the document will probably
get there.)

> In addition, draft-ietf-tcpm-newcwv recommends (for a long time
> already) to move RFC 2861 from Experimental to Historic. According to
> the feedback in the room, the TCPM working group seems to agree on
> that. This message thus intends to confirm that obsoleting RFC 2861 is
> consensus of the TCPM working group.

I don't see this yet.  Per previous discussion with Gorry the newcwv
pertains to 'rate limited' periods, whereas RFC 2681 pertains to 'idle'
or 'application limited' periods.  The new document does not shed any
light on how these periods relate to one another.  Gorry seems to
indicate that the new version encompasses the old (and then some).  But,
I have no good understanding of this relationship myself.  I am sure I
will better grok it after the next version of the draft.  But, until we
see a cogent argument written down I don't see how we can decide whether
to obsolete RFC 2681.

Given the state of the newcwv document these questions are just
premature.  We'd be better off spending cycles on the actual meat of the
document.

allman





----------ma12593-1
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (Darwin)

iEYEARECAAYFAlMoMTEACgkQWyrrWs4yIs56xwCcDUNHvw4rj+wJuiaISl9B/LnR
iIoAnROYmiduPyzVYWPfkCTQwJVUj+n+
=wlRU
-----END PGP SIGNATURE-----
----------ma12593-1--


From nobody Tue Mar 18 05:21:03 2014
Return-Path: <michael.scharf@alcatel-lucent.com>
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 196C21A038C for <tcpm@ietfa.amsl.com>; Tue, 18 Mar 2014 05:21:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEoqnTeyx8xb for <tcpm@ietfa.amsl.com>; Tue, 18 Mar 2014 05:20:58 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7471A0333 for <tcpm@ietf.org>; Tue, 18 Mar 2014 05:20:58 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2ICKkR8010483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 18 Mar 2014 07:20:47 -0500 (CDT)
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 s2ICKgJ3006944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Mar 2014 13:20:44 +0100
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 18 Mar 2014 13:20:42 +0100
From: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
To: "mallman@icir.org" <mallman@icir.org>
Thread-Topic: [tcpm] Intended status of draft-ietf-tcpm-newcwv - Confirmation of discussion during IETF 89 
Thread-Index: AQHPQp8/2gKYl0msMEKeCZzoVtptVZrmuiIQ
Date: Tue, 18 Mar 2014 12:20:42 +0000
Message-ID: <655C07320163294895BBADA28372AF5D23590B@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References: <655C07320163294895BBADA28372AF5D2314B7@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140318114242.1B5AA39C197E@lawyers.icir.org>
In-Reply-To: <20140318114242.1B5AA39C197E@lawyers.icir.org>
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: http://mailarchive.ietf.org/arch/msg/tcpm/Tj62PMUyBgw0VP6306WISb4FRro
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] Intended status of draft-ietf-tcpm-newcwv - Confirmation of discussion during IETF 89
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Mar 2014 12:21:01 -0000

> My high order bit here is that the newcwv document isn't in very good
> shape [per previous comments] and so its a little hard to have these
> conversations in that context if you ask me.  And, so I'd suggest this
> arbitrary two week period is premature.

To clarify: This is not a WGLC.

The deadline is just for those who haven't attended the meeting to speak up=
 regarding the planned status and let us know if they have thoughts (which =
you did - good!). So far, we got plenty of comments that the document shoul=
d be Experimental as a first step, possibly evolving to PS later.=20

In the meeting, we discussed whether the document fulfills the requirements=
 on Standards Track (RFC 2026, sec. 4.1.1):

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.

   Usually, neither implementation nor operational experience is
   required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable, and will
   usually represent a strong argument in favor of a Proposed Standard
   designation.

In my view, a PS document on newcwv would really benefit from operational e=
xperience.

> However, to give a hit on the two questions you asked ...
>=20
> > In the room there was strong consensus that this document should be
> > heading for Experimental status, given that further experimentation
> > and operational experience with the mechanism is needed (e.g.,
> > regarding pacing).
>=20
> If it is the pacing that is the reason for experimental instead of
> proposed I'd disagree.  Pacing makes the imposed load on the network
> less aggressive than current mechanisms and so I don't see any reason
> to
> spin at experimental.  Not that there may not be a refining of our
> understanding of pacing by actually doing it, but that the possibility
> of harm to the network seems pretty small to me.

My own concern is operational experience and the likelihood of wide adoptio=
n by TCP/IP stacks.

However, pacing specifically seems to be a concern for the community (see h=
ttp://www.ietf.org/proceedings/89/minutes/minutes-89-tcpm). I just tried to=
 summarize this briefly.

> Now if the reason for experimental is that newcwv is more aggressive
> than the current TCP spec recommends then perhaps that is a better
> reason.  However, the flip side is that we have gotten by with no
> downward adjustment based on cwnd use / non-use for a long time and so
> relative to that newcwv is still more conservative and hence seems fine
> for proposed.
>=20
> (Of course, both these are modulo that I don't really yet understand or
> buy newcwv because the document has yet to convince me we need
> something
> new and/or that the new algorithm is reasonable.  But, I do have some
> trust in the involved folks and so I figure the document will probably
> get there.)
>=20
> > In addition, draft-ietf-tcpm-newcwv recommends (for a long time
> > already) to move RFC 2861 from Experimental to Historic. According to
> > the feedback in the room, the TCPM working group seems to agree on
> > that. This message thus intends to confirm that obsoleting RFC 2861
> is
> > consensus of the TCPM working group.
>=20
> I don't see this yet.  Per previous discussion with Gorry the newcwv
> pertains to 'rate limited' periods, whereas RFC 2681 pertains to 'idle'
> or 'application limited' periods.  The new document does not shed any
> light on how these periods relate to one another.  Gorry seems to
> indicate that the new version encompasses the old (and then some).
> But,
> I have no good understanding of this relationship myself.  I am sure I
> will better grok it after the next version of the draft.  But, until we
> see a cogent argument written down I don't see how we can decide
> whether
> to obsolete RFC 2681.

Point taken. I raise that point mainly because I have not been aware of muc=
h discussion on that so far, even if it is in the document for a long time.=
 This can be finally discussed during the WGLC.
=20
> Given the state of the newcwv document these questions are just
> premature.  We'd be better off spending cycles on the actual meat of
> the
> document.

Yes, the latter is required anyway.=20

Michael


From nobody Tue Mar 18 21:56:46 2014
Return-Path: <nishida@sfc.wide.ad.jp>
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 DCC041A0381 for <tcpm@ietfa.amsl.com>; Tue, 18 Mar 2014 21:56:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.464
X-Spam-Level: *
X-Spam-Status: No, score=1.464 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, RP_MATCHES_RCVD=-0.547, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-IrSGAOsQW0 for <tcpm@ietfa.amsl.com>; Tue, 18 Mar 2014 21:56:40 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5341A04B4 for <tcpm@ietf.org>; Tue, 18 Mar 2014 21:56:39 -0700 (PDT)
Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 79D272781AA for <tcpm@ietf.org>; Wed, 19 Mar 2014 13:56:29 +0900 (JST)
Received: by mail-lb0-f169.google.com with SMTP id q8so5622076lbi.28 for <tcpm@ietf.org>; Tue, 18 Mar 2014 21:56:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=rXdJAaE0e6eCrJo+v2E5r9NhvDG17y+OOX49VUO5sY8=; b=Jflp1uK28hrpRBvorr8kWUTOfDjnQlboY7GXb3nLjeg+pNHV7aXRoxMx39gRWw7B13 wMpZj2Pz3BDn9mNn4zLzRa6VqGgcx8oMHI4TM3bw2xRPoObgFkne4G19mehCUtN9DwwO GzzsZUX422efugeQLg5Vwl+/yHpwX0Jm9bnBlPqYmaCtkZjCtjKMwHvWl8QX/kyHLqte Zk4xM6wYLF2uXpLtQw/3TzW7uzCmI7jaLY25Edz/LAUJpJfU4q4zxErJcEwnzJnm8Ig+ FGv+hAIrHKsygVyQYJtdxDb1tloZY5IdLfidctdziKwUi2ZqODRI3WzOxeqc+6UVdVpn 01QA==
MIME-Version: 1.0
X-Received: by 10.112.136.71 with SMTP id py7mr22977057lbb.26.1395204986751; Tue, 18 Mar 2014 21:56:26 -0700 (PDT)
Received: by 10.114.95.101 with HTTP; Tue, 18 Mar 2014 21:56:26 -0700 (PDT)
Date: Tue, 18 Mar 2014 21:56:26 -0700
Message-ID: <CAO249ycbAaCq3cWE7_KcPSGgf-zXFhtZRuo3XVQfJTx1TDLzWQ@mail.gmail.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
To: "tcpm@ietf.org" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary=089e01182f349fd13e04f4ee7938
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/3oD1lmttkdBn5-A-7eG_cLWHZ1s
Subject: [tcpm] WGLC for draft-ietf-tcpm-tcp-rfc4614bis-03
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Mar 2014 04:56:45 -0000

--089e01182f349fd13e04f4ee7938
Content-Type: text/plain; charset=ISO-8859-1

Hello,

As we have discussed in the London meeting, we initiate WGLC
for draft-ietf-tcpm-tcp-rfc4614bis-03. The WGLC will run until * April 4th
*.
The intended status of the draft is Informational.

If you have any comments or questions on this document, please send us
before the deadline.
The draft is available at:
http://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-03

Thanks,
--
Yoshifumi
(on behalf of tcpm co-chairs)

--089e01182f349fd13e04f4ee7938
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<div><br></div><div>As we have discussed in the Lond=
on meeting, we initiate WGLC for=A0draft-ietf-tcpm-tcp-rfc4614bis-03. The W=
GLC will run until * April 4th *.</div><div>The intended status of the draf=
t is Informational.</div>

<div><br></div><div>If you have any comments or questions on this document,=
 please send us before the deadline.</div><div>The draft is available at:</=
div><div><a href=3D"http://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614b=
is-03" target=3D"_blank">http://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc=
4614bis-03</a><br>

</div><div><br></div><div>Thanks,</div><div>--</div><div>Yoshifumi</div><di=
v>(on behalf of tcpm co-chairs)</div></div>

--089e01182f349fd13e04f4ee7938--


From nobody Wed Mar 19 05:21:18 2014
Return-Path: <gorry@erg.abdn.ac.uk>
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 8C5C91A0264 for <tcpm@ietfa.amsl.com>; Wed, 19 Mar 2014 05:21:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 nCAVGD-xAM2b for <tcpm@ietfa.amsl.com>; Wed, 19 Mar 2014 05:21:10 -0700 (PDT)
Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8B72C1A03CE for <tcpm@ietf.org>; Wed, 19 Mar 2014 05:21:10 -0700 (PDT)
Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id DC3FE2B44D5; Wed, 19 Mar 2014 12:21:00 +0000 (GMT)
Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 19 Mar 2014 12:21:01 -0000
Message-ID: <7966118b4e76d2f24dab06ff15356f25.squirrel@www.erg.abdn.ac.uk>
In-Reply-To: <20140318114242.1B5AA39C197E@lawyers.icir.org>
References: <20140318114242.1B5AA39C197E@lawyers.icir.org>
Date: Wed, 19 Mar 2014 12:21:01 -0000
From: gorry@erg.abdn.ac.uk
To: mallman@icir.org
User-Agent: SquirrelMail/1.4.22
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/lYixadiaMKYsd7FBvaR76PBRk3M
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] Intended status of draft-ietf-tcpm-newcwv - Confirmation of discussion during IETF 89
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Mar 2014 12:21:14 -0000

>
> My high order bit here is that the newcwv document isn't in very good
> shape [per previous comments] and so its a little hard to have these
> conversations in that context if you ask me.  And, so I'd suggest this
> arbitrary two week period is premature.
>
In retrospect, I agree - and since the authors started an internal review,
we have found several places where language is confusing etc. Mea culpa -
we will fix, but this requires some detailed consistency checks by us.

> However, to give a hit on the two questions you asked ...
>
>> In the room there was strong consensus that this document should be
>> heading for Experimental status, given that further experimentation
>> and operational experience with the mechanism is needed (e.g.,
>> regarding pacing).
>
> If it is the pacing that is the reason for experimental instead of
> proposed I'd disagree.  Pacing makes the imposed load on the network
> less aggressive than current mechanisms and so I don't see any reason to
> spin at experimental.  Not that there may not be a refining of our
> understanding of pacing by actually doing it, but that the possibility
> of harm to the network seems pretty small to me.
>
I think so too - In my mind we discussed if Pacing is useful (it is), if
we should recommend some of pacing pacing (I think we should, and the
draft now does). It's always going to be the case that OS implement pacing
in various ways - the big step is to say "turn it on" for these cases, I
don't see turning on as a risk.

> Now if the reason for experimental is that newcwv is more aggressive
> than the current TCP spec recommends then perhaps that is a better
> reason.  However, the flip side is that we have gotten by with no
> downward adjustment based on cwnd use / non-use for a long time and so
> relative to that newcwv is still more conservative and hence seems fine
> for proposed.
>
> (Of course, both these are modulo that I don't really yet understand or
> buy newcwv because the document has yet to convince me we need something
> new and/or that the new algorithm is reasonable.  But, I do have some
> trust in the involved folks and so I figure the document will probably
> get there.)
>
The authors intent resonates with this.

>> In addition, draft-ietf-tcpm-newcwv recommends (for a long time
>> already) to move RFC 2861 from Experimental to Historic. According to
>> the feedback in the room, the TCPM working group seems to agree on
>> that. This message thus intends to confirm that obsoleting RFC 2861 is
>> consensus of the TCPM working group.
>
> I don't see this yet.  Per previous discussion with Gorry the newcwv
> pertains to 'rate limited' periods, whereas RFC 2681 pertains to 'idle'
> or 'application limited' periods.  The new document does not shed any
> light on how these periods relate to one another.  Gorry seems to
> indicate that the new version encompasses the old (and then some).  But,
> I have no good understanding of this relationship myself.  I am sure I
> will better grok it after the next version of the draft.  But, until we
> see a cogent argument written down I don't see how we can decide whether
> to obsolete RFC 2681.
>
> Given the state of the newcwv document these questions are just
> premature.  We'd be better off spending cycles on the actual meat of the
> document.
>
Again, our fault, we'll strive to do better in the next draft.

> allman
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

Gorry


From nobody Wed Mar 19 15:01:35 2014
Return-Path: <touch@isi.edu>
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 0E85E1A078A for <tcpm@ietfa.amsl.com>; Wed, 19 Mar 2014 15:01:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.747
X-Spam-Level: 
X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] 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 8UD89c0UkNcL for <tcpm@ietfa.amsl.com>; Wed, 19 Mar 2014 15:01:31 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3C14F1A0761 for <tcpm@ietf.org>; Wed, 19 Mar 2014 15:01:31 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s2JM0omI021115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Mar 2014 15:00:50 -0700 (PDT)
Message-ID: <532A1392.8030001@isi.edu>
Date: Wed, 19 Mar 2014 15:00:50 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "tcpm@ietf.org" <tcpm@ietf.org>
References: <20140319215335.20587.83977.idtracker@ietfa.amsl.com>
In-Reply-To: <20140319215335.20587.83977.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20140319215335.20587.83977.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/d81TkzvPlDqrikh_hjbXt_Hdeu0
Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcp-ao-encrypt-00.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Mar 2014 22:01:33 -0000

Hi, all,

Given a few recent discussions on TCP encryption alternatives, I figured 
I'd throw my view into the mix.

The following describes a variant of TCP-AO that, in addition to 
authenticating the TCP header and payload, also encrypts the payload.

It's a fairly simple approach that seems like it might be useful whether 
or not we consider other TCP encryption approaches.

Feedback welcome.

Joe

-------- Original Message --------
Subject: New Version Notification for draft-touch-tcp-ao-encrypt-00.txt
Date: Wed, 19 Mar 2014 14:53:35 -0700
From: internet-drafts@ietf.org
To: Dr. Joseph D. Touch <touch@isi.edu>, Joe Touch <touch@isi.edu>


A new version of I-D, draft-touch-tcp-ao-encrypt-00.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name:		draft-touch-tcp-ao-encrypt
Revision:	00
Title:		A TCP Authentication Option Extension for Payload Encryption
Document date:	2014-03-19
Group:		Individual Submission
Pages:		7
URL: 
http://www.ietf.org/internet-drafts/draft-touch-tcp-ao-encrypt-00.txt
Status:         https://datatracker.ietf.org/doc/draft-touch-tcp-ao-encrypt/
Htmlized:       http://tools.ietf.org/html/draft-touch-tcp-ao-encrypt-00


Abstract:
    This document describes an extension to the TCP Authentication
    Option (TCP-AO) to encrypt the TCP segment payload in addition to
    providing TCP-AO's authentication of the payload, TCP header, and IP
    pseudoheader. This extension changes how the packet contents and
    headers are processed and which keys are derived, but not its key
    coordination or protection of long-lived connections.

 



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



From nobody Thu Mar 20 15:25:47 2014
Return-Path: <bob.briscoe@bt.com>
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 28B931A077C for <tcpm@ietfa.amsl.com>; Thu, 20 Mar 2014 15:25:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 I7F4FusRkIWH for <tcpm@ietfa.amsl.com>; Thu, 20 Mar 2014 15:25:43 -0700 (PDT)
Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) by ietfa.amsl.com (Postfix) with ESMTP id C74FC1A048D for <tcpm@ietf.org>; Thu, 20 Mar 2014 15:25:41 -0700 (PDT)
Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 20 Mar 2014 22:25:31 +0000
Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 20 Mar 2014 22:25:29 +0000
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Thu, 20 Mar 2014 22:25:24 +0000
Received: from BTP075694.jungle.bt.co.uk ([10.109.25.95])	by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s2KMPLJZ017004;	Thu, 20 Mar 2014 22:25:22 GMT
Message-ID: <201403202225.s2KMPLJZ017004@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 20 Mar 2014 22:25:21 +0000
To: "Scheffenegger, Richard" <rs@netapp.com>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F260F7664@SACEXCMBX02-PRD.h q.netapp.com>
References: <012C3117EDDB3C4781FD802A8C27DD4F260F5701@SACEXCMBX02-PRD.hq.netapp.com> <EFA2335D-4D00-4106-89F8-12D0AA904323@trammell.ch> <012C3117EDDB3C4781FD802A8C27DD4F260F7664@SACEXCMBX02-PRD.hq.netapp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/TVbjpWwIFNcO6RowHrmq_k00pDk
Cc: "tcpm \(tcpm@ietf.org\)" <tcpm@ietf.org>
Subject: Re: [tcpm] AccECN semantics
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Mar 2014 22:25:46 -0000

Richard, Brian,

At 09:44 17/03/2014, Scheffenegger, Richard wrote:
>Hi Brian,
>
>
> > > RFC3168 stipulates that pure control packets MUST NOT have ECT (thus no
> > CE) (section 6.1.4), but doesn't explicitly specify the receiver reaction,
> > if a control packet is nevertheless received with CE...
> >
> > It does point (non-normatively) in the direction of "future research":
> >
> >                                       ... [m]echanisms for responding to
> >    congestion on the ACK-path are areas for current and future research.
> >    (One simple possibility would be for the sender to reduce its
> >    congestion window when it receives a pure ACK packet with the CE
> >    codepoint set).

That's because Sally had in mind to work on ACK-CC [RFC5690].

> >
> > > With one ECN TCP stack I happened to have under test, the receiver
> > actually suppresses and conceals the CE information.
> >
> > Interesting to see the stack didn't take the hint there. :) "suppresses
> > and conceals" means no ECE, no reduction, and no information to the
> > application layer?
>
>Well, I was only looking at the network layer without checking 
>application sockets directly; Also, I'm concered at this point about 
>the receiver behavior rather than the sender behavior.
>
>ECE's reflected during phases where the sender only ACKs data from 
>the receiver - that is, data is only flowing in the reverse 
>direction - wouldn't need to actually reduce the cwnd on the sender 
>(which is not sending data anyway, at that point. But they could 
>reveal ACK-path congestion, which *may* help during cwnd validation phases etc.
>
> > > IMHO, the receiver should not make assumptions or remove information (a
> > path still using TOS rather than DiffServ might be the cause - but it's up
> > to the sender to detect that misbehavior).

I agree in principle, but this is hard in practice (see below).

> >
> > Given how many flows we observed on the open Internet that were clearly
> > misusing the ECT bits, the receiver should probably always assume that the
> > sender is broken.
>
>I take this as a statement of irony :)

Seriously, in case its not obvious, it would be wrong to /always/ 
assume the sender is always broken, just because it always is now. 
Otherwise, if senders get fixed, we have a load of broken receivers.

> > > I think the requirement given in 3168 about control packets 
> MUST NOT carry ECT is
> > sound, it probably would have been better a SHOULD NOT; but IMHO, 
> the receiver MUST
> > reflect the ECT/CE once the session has negotiated ECN support - 
> to allow future
> > extensions without having to modify the receiver again.
>
> > > However, this might make the accounting more complex, as CE 
> marks on pure ACKs, while
> > no data is being sent, don't necessarily have to invoke a CC 
> reaction (other than ACK-
> > CC) immediately.

[Bob: I added the above 2 paras back into the thread]
+1 to allowing future extensions without mod'ing the rcvr.

But how?...
a) If we tried to define feedback of CE-marked bytes, then a 
CE-marked pure ACK would trigger zero feedback (feedback of the 
number zero could be semantically different from no feedback).
b) If we tried to define feedback of CE-marked packets, then a 
CE-marked pure ACK would increment the feedback count by 1, and the 
sender would usually be able to infer that over the same packet the 
ACK counter had incremented by zero bytes.

If the receiver got a CE-marked rexmt, and fed this back either way, 
the sender would read it as more bytes CE marked. But that's safe - 
IMHO the argument in 3168 for making re-transmissions Not-ECT is less 
clear-cut than with pure ACKs. If you lose a packet you respond to 
the congestion. If the repair is then CE-marked, that means more 
congestion AFA I'm concerned, so another congestion response seems 
reasonable to me.

So either way, the sender would (at least statistically) be able to 
work out what had happened, and decide how and whether to respond 
(ie. do nothing if the receiver feeds back that there was CE on a 
control packet). Superficially, option b) seems more efficient and a) 
doesn't give much more info in return for the greater overhead. 
Either way, the sender could at least change its behaviour 
unilaterally in the future.


>ECN signaling is seriously impeded, but I think with we have a 
>chance to get the end hosts right with the deployment of AccECN, we 
>should be clear what the expected behavior *of the signaling alone* 
>should be. Not leaving things ambiguous in the specs should make it 
>easier to have implementations that follow the spirit of the spec...

In this spirit I wrote my recent email tightening up the definition 
of the ACE field when the ACK flag is cleared for 
draft-kuehlewind-tcpm-accurate-ecn (I'll late cc to Brian too).


> > > Perhaps that should go into either AccEcn requirements, or one of the
> > AccECN mechanism drafts?
> >
> > Well, "mechanisms for responding to congestion on the ACK-path are areas
> > for ... future research" so maybe splitting that work out into another
> > draft might scope the work a bit better. AccECN seems more complete than
> > any of this at the moment...
>
>True, but we haven't yet any text that makes it clear if there 
>should be a distinction between data and control segments. At least 
>I assumed that the AccECN signal should be agnostic what type of 
>segment the CE (ECT(0) /ECT(1)) was sent with...

AccECN requires mods to both sender and receiver (it is negotiated), 
so we can require that the receiver reflects as much info as it can 
as faithfully as possible, and that the sender attempts to do nothing 
in response to any feedback of CE on control packets.


Bob




>Richard Scheffenegger

________________________________________________________________
Bob Briscoe,                                                  BT 


From nobody Thu Mar 20 15:50:04 2014
Return-Path: <wes@mti-systems.com>
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 3570A1A0931 for <tcpm@ietfa.amsl.com>; Thu, 20 Mar 2014 15:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzlFEZVjm5bX for <tcpm@ietfa.amsl.com>; Thu, 20 Mar 2014 15:50:02 -0700 (PDT)
Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id 58E811A0933 for <tcpm@ietf.org>; Thu, 20 Mar 2014 15:50:02 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s2KMnq1u003045 for <tcpm@ietf.org>; Thu, 20 Mar 2014 18:49:52 -0400
Received: (qmail 19169 invoked by uid 0); 20 Mar 2014 22:49:52 -0000
X-TCPREMOTEIP: 69.81.143.143
X-Authenticated-UID: wes@mti-systems.com
Received: from unknown (HELO ?192.168.1.142?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 20 Mar 2014 22:49:51 -0000
Message-ID: <532B7083.4080908@mti-systems.com>
Date: Thu, 20 Mar 2014 18:49:39 -0400
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "tcpm@ietf.org" <tcpm@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/aZHscmABiIVaEyqVBQ28KmDUB-Y
Subject: [tcpm] revision -01 of 793bis proposal
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Mar 2014 22:50:04 -0000

This is just a notification that I've posted revision -01 of the
proposed update to RFC793 that we talked about at IETF 88 and
prior on the mailing list.

In order to make change tracking relatively easy, in this revision
I attempted to only bring in the original RFC 793 material and get
it converted into XML2RFC.  Aside from text reflow on pages and
updated figure numbers, there *shouldn't* be changes from 793 yet.

Subsequent revisions are planned to be focused on specific updates,
so that the diffs between revisions will show what was done for
particular specific types of updates that are needed to the 793
content.

You can find the document here:
http://tools.ietf.org/html/draft-eddy-rfc793bis-01

-- 
Wes Eddy
MTI Systems


From nobody Fri Mar 21 04:36:14 2014
Return-Path: <ietf@trammell.ch>
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 BE1D71A0945 for <tcpm@ietfa.amsl.com>; Fri, 21 Mar 2014 04:36:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 JDnqsuo_oVLt for <tcpm@ietfa.amsl.com>; Fri, 21 Mar 2014 04:36:10 -0700 (PDT)
Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0BE1A08AE for <tcpm@ietf.org>; Fri, 21 Mar 2014 04:36:09 -0700 (PDT)
Received: from [192.168.0.52] (chello084113020103.2.12.vie.surfer.at [84.113.20.103]) by trammell.ch (Postfix) with ESMTPSA id 9C2F11A001C; Fri, 21 Mar 2014 12:35:26 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <201403202225.s2KMPLJZ017004@bagheera.jungle.bt.co.uk>
Date: Fri, 21 Mar 2014 12:35:24 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <E2CB3623-2325-4420-8BD4-D8E63A4B7F00@trammell.ch>
References: <012C3117EDDB3C4781FD802A8C27DD4F260F5701@SACEXCMBX02-PRD.hq.netapp.com> <EFA2335D-4D00-4106-89F8-12D0AA904323@trammell.ch> <012C3117EDDB3C4781FD802A8C27DD4F260F7664@SACEXCMBX02-PRD.hq.netapp.com> <201403202225.s2KMPLJZ017004@bagheera.jungle.bt.co.uk>
To: Bob Briscoe <bob.briscoe@bt.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/dbNq0gzPfC6z6MV5RS-FmY60-mM
Cc: "tcpm \(tcpm@ietf.org\)" <tcpm@ietf.org>
Subject: Re: [tcpm] AccECN semantics
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Mar 2014 11:36:13 -0000

hi Bob, all,

On 20 Mar 2014, at 23:25, Bob Briscoe <bob.briscoe@bt.com> wrote:

<snip>

>> > > IMHO, the receiver should not make assumptions or remove =
information (a
>> > path still using TOS rather than DiffServ might be the cause - but =
it's up
>> > to the sender to detect that misbehavior).
>=20
> I agree in principle, but this is hard in practice (see below).
>=20
>> >
>> > Given how many flows we observed on the open Internet that were =
clearly
>> > misusing the ECT bits, the receiver should probably always assume =
that the
>> > sender is broken.
>>=20
>> I take this as a statement of irony :)
>=20
> Seriously, in case its not obvious, it would be wrong to /always/ =
assume the sender is always broken, just because it always is now. =
Otherwise, if senders get fixed, we have a load of broken receivers.

I was making a more general point, along the lines of the principle of =
liberal acceptance. Given the prevalence of traffic (at least as of =
2012) misusing these codepoints, ECN-capable endpoints should be =
designed and implemented defensively. This is the point of the ECN =
fallback draft.

Receivers should also note whether they saw CE on the SYN, and mark =
those peers/paths ECN-unusable. This probably needs to go in the ECN =
fallback draft too. It's not clear how to handle this misuse in-network. =
At this point in 2014, I think I'm happy giving guidance that it's okay =
to break TOS-byte traffic on the open Internet by marking when =
appropriate, since at least in our observations the vast majority of =
such misuse came from a very small number of providers.

Once ECN is negotiated, the sender/receiver should still be prepared to =
back off in case the path becomes ECN-impaired. Currently running =
research should shed some light on how often we expect this to happen.

>> > > I think the requirement given in 3168 about control packets MUST =
NOT carry ECT is
>> > sound, it probably would have been better a SHOULD NOT; but IMHO, =
the receiver MUST
>> > reflect the ECT/CE once the session has negotiated ECN support - to =
allow future
>> > extensions without having to modify the receiver again.
>>=20
>> > > However, this might make the accounting more complex, as CE marks =
on pure ACKs, while
>> > no data is being sent, don't necessarily have to invoke a CC =
reaction (other than ACK-
>> > CC) immediately.
>=20
> [Bob: I added the above 2 paras back into the thread]
> +1 to allowing future extensions without mod'ing the rcvr.
>=20
> But how?...
> a) If we tried to define feedback of CE-marked bytes, then a CE-marked =
pure ACK would trigger zero feedback (feedback of the number zero could =
be semantically different from no feedback).
> b) If we tried to define feedback of CE-marked packets, then a =
CE-marked pure ACK would increment the feedback count by 1, and the =
sender would usually be able to infer that over the same packet the ACK =
counter had incremented by zero bytes.
>=20
> If the receiver got a CE-marked rexmt, and fed this back either way, =
the sender would read it as more bytes CE marked. But that's safe - IMHO =
the argument in 3168 for making re-transmissions Not-ECT is less =
clear-cut than with pure ACKs. If you lose a packet you respond to the =
congestion. If the repair is then CE-marked, that means more congestion =
AFA I'm concerned, so another congestion response seems reasonable to =
me.

Yep.

> So either way, the sender would (at least statistically) be able to =
work out what had happened, and decide how and whether to respond (ie. =
do nothing if the receiver feeds back that there was CE on a control =
packet). Superficially, option b) seems more efficient and a) doesn't =
give much more info in return for the greater overhead. Either way, the =
sender could at least change its behaviour unilaterally in the future.

Also yep.

Cheers,

Brian


From nobody Fri Mar 21 05:12:15 2014
Return-Path: <internet-drafts@ietf.org>
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 2F7721A097F; Fri, 21 Mar 2014 05:12:05 -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 Q8FeClK0DDV9; Fri, 21 Mar 2014 05:12:03 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4801A072C; Fri, 21 Mar 2014 05:12:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.2.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140321121203.30688.12749.idtracker@ietfa.amsl.com>
Date: Fri, 21 Mar 2014 05:12:03 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/4tWDzmjjmnH7lomvfIuOgUveLro
Cc: tcpm@ietf.org
Subject: [tcpm] I-D Action: draft-ietf-tcpm-newcwv-06.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Mar 2014 12:12:05 -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-06.txt
	Pages           : 23
	Date            : 2014-03-21

Abstract:
   This document proposes an update to RFC 5681 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 either 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-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-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 Fri Mar 21 11:17:55 2014
Return-Path: <gorry@erg.abdn.ac.uk>
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 D33431A0A27 for <tcpm@ietfa.amsl.com>; Fri, 21 Mar 2014 11:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 37BIV65WccfZ for <tcpm@ietfa.amsl.com>; Fri, 21 Mar 2014 11:17:49 -0700 (PDT)
Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 32A7C1A0A2C for <tcpm@ietf.org>; Fri, 21 Mar 2014 11:17:47 -0700 (PDT)
Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 542E12B456E; Fri, 21 Mar 2014 18:17:37 +0000 (GMT)
Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 7B5FB2B43C1 for <tcpm@ietf.org>; Fri, 21 Mar 2014 18:17:36 +0000 (GMT)
Message-ID: <532C8240.8080100@erg.abdn.ac.uk>
Date: Fri, 21 Mar 2014 18:17:36 +0000
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
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:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "tcpm@ietf.org" <tcpm@ietf.org>
References: <CAKUix-5jYEhKYnyZNao-isZk0mO1ueDidpQghGRrG=_4r6kdBA@mail.gmail.com>
In-Reply-To: <CAKUix-5jYEhKYnyZNao-isZk0mO1ueDidpQghGRrG=_4r6kdBA@mail.gmail.com>
X-Forwarded-Message-Id: <CAKUix-5jYEhKYnyZNao-isZk0mO1ueDidpQghGRrG=_4r6kdBA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/7YHxMpbPHiQQXLJI7hhaeDQDYMs
Subject: [tcpm] A readable version of the TCP-new-CWV spec....
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 <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Mar 2014 18:17:52 -0000

Hi,

We have just submitted a new version (-06) of the CWV draft:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-newcwv-06.txt


This draft does not internationally change the mechanisms, but it is a 
significant editorial update (largely based on marks various comments) 
that is intended to make this much more readable and give clearer 
motivation. (We also tentatively changed the document status - as 
instructed by the WG Chairs.)

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-newcwv-06

We'd really welcome reviews of this new version.

Gorry Raffaello & Arjuna


-- 

University of Aberdeen
Aberdeen AB24 3UE
phone: +441224272807




From nobody Fri Mar 21 14:53:15 2014
Return-Path: <uma.chunduri@ericsson.com>
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 2CF211A0A14 for <tcpm@ietfa.amsl.com>; Fri, 21 Mar 2014 14:53:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level: 
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEqqTRRcOGLD for <tcpm@ietfa.amsl.com>; Fri, 21 Mar 2014 14:53:09 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF131A0A09 for <tcpm@ietf.org>; Fri, 21 Mar 2014 14:53:09 -0700 (PDT)
X-AuditID: c6180641-b7f2f8e000002cdc-30-532cb1d31c1e
Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 50.82.11484.3D1BC235; Fri, 21 Mar 2014 22:40:35 +0100 (CET)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0387.000; Fri, 21 Mar 2014 17:52:57 -0400
From: Uma Chunduri <uma.chunduri@ericsson.com>
To: Joe Touch <touch@isi.edu>, "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: [tcpm] Fwd: New Version Notification for draft-touch-tcp-ao-encrypt-00.txt
Thread-Index: AQHPQ77IJVNJeEzOtEyFgDwAlkF4R5rsEBhg
Date: Fri, 21 Mar 2014 21:52:57 +0000
Message-ID: <1B502206DFA0C544B7A60469152008633F2268E8@eusaamb105.ericsson.se>
References: <20140319215335.20587.83977.idtracker@ietfa.amsl.com> <532A1392.8030001@isi.edu>
In-Reply-To: <532A1392.8030001@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.9]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyuXRPgu7ljTrBBvtfy1psOzmfyWLdn7ks DkweS5b8ZPLY/X4rSwBTFJdNSmpOZllqkb5dAlfGo+9zWAomKlWsfrSStYGxX7qLkZNDQsBE YuOmtYwQtpjEhXvr2boYuTiEBI4wSvzatZIZwlnOKDHr7S8mkCo2AT2Jj1N/soPYIgJ2Ep2X 94DZwgKREtf2nIKKR0mcvbafFcI2kvhy6BvQBg4OFgFVie6L9iBhXgFfiXfTu9lAbCGBOIk1 vy4zg9icAuoSD16sAFvFCHTQ91NrwGxmAXGJW0/mM0EcKiCxZM95ZghbVOLl43+sELaixL7+ 6ewQ9ToSC3Z/YoOwtSWWLXzNDLFXUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFyFFanFqW m25kuIkRGA3HJNgcdzAu+GR5iFGag0VJnPfLW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxS DYwei5/P4ixpfuyQdern5omrZRJFpx+dsSHyV8XflmV15te+v3ZOWHfncfSNB64uyawBwXdO PTjywdxKsOVcjr64wPwFdpJ+YpumGU4peNO6+uvH0ysKHDr3rbu/3km6JSfOt8T1SpBY9Yr8 tKztkRuurErb8aVdbj7Dts6GPdfrWydXP3W2iVitxFKckWioxVxUnAgA9I26RVQCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/uZp1kLG5OZmE_ijCo6w98jH78hg
Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcp-ao-encrypt-00.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Mar 2014 21:53:11 -0000

Joe,

Good to see this.=20

Though it's still early to understand how  and why ENC is needed here;
 but  due to SDN/NFV/etc.. there are routing  specifications which talk abo=
ut complete internal topology transport between AS'es or to  a central cont=
roller..

Frankly we were recently having this discussion internally and realized thi=
s extension could be useful.

Quick comments:


1.   TCP-AO NAT Extension  =3D=3D> Title inside the document says this..

2.   Given the in band processing AUTH/CIPHER by processors, it's better to=
 give the flexibility  to have Symmetric/Stream=20
      ciphers (remove the restriction) and yes, this requires introduction =
of  padding and pad length

3.   Section 3
     "...TCP-AO-NAT is intended
   for use only where coordinated between endpoints for connections
   that match the shared MKT parameters, as with all other MKT
   parameters."
  =20
   Should have been TCP-AO-ENC

4. Section 4.1
   We need another Master Key for Encryption.
   Else we may potentially get the same key for both AUTH and ENC if the sa=
me algorithm is used.

5. Section 4.1 - Something is missing here
   "   PTCP-AO-ENC processes TCP packets in the same way as TCP-AO, except
   that it replaces the authentication input and output processing as
   follows:.."

6.  Section 4.3. Per-Connection TCP-AO Parameters
     Yes, can use the same SendID, RecvID with encryption and still can hav=
e 2 Master Keys one for encryption and one for AUTH.=20
     The quality (randomness requirements etc..) of the master key can be d=
ifferent for both purposes.

7.  Section 5.
     "..Note that the encryption
   initialization vector MAY depend on TCP header state, but MUST NOT
   depend on the processing of previous segments because segments may
   arrive (and need to be decrypted) out of order."

   IV is critical for some algorithms, this may need to be looked into furt=
her.
   I remember FIPS tests are very hard on this.

8. Section 7
    "Where are required algorithms specified? This doc or a separate one?"
   Separate.

     =20
--
Uma C.

-----Original Message-----
From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Joe Touch
Sent: Wednesday, March 19, 2014 3:01 PM
To: tcpm@ietf.org
Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcp-ao-encryp=
t-00.txt

Hi, all,

Given a few recent discussions on TCP encryption alternatives, I figured I'=
d throw my view into the mix.

The following describes a variant of TCP-AO that, in addition to authentica=
ting the TCP header and payload, also encrypts the payload.

It's a fairly simple approach that seems like it might be useful whether or=
 not we consider other TCP encryption approaches.

Feedback welcome.

Joe

-------- Original Message --------
Subject: New Version Notification for draft-touch-tcp-ao-encrypt-00.txt
Date: Wed, 19 Mar 2014 14:53:35 -0700
From: internet-drafts@ietf.org
To: Dr. Joseph D. Touch <touch@isi.edu>, Joe Touch <touch@isi.edu>


A new version of I-D, draft-touch-tcp-ao-encrypt-00.txt has been successful=
ly submitted by Joe Touch and posted to the IETF repository.

Name:		draft-touch-tcp-ao-encrypt
Revision:	00
Title:		A TCP Authentication Option Extension for Payload Encryption
Document date:	2014-03-19
Group:		Individual Submission
Pages:		7
URL:=20
http://www.ietf.org/internet-drafts/draft-touch-tcp-ao-encrypt-00.txt
Status:         https://datatracker.ietf.org/doc/draft-touch-tcp-ao-encrypt=
/
Htmlized:       http://tools.ietf.org/html/draft-touch-tcp-ao-encrypt-00


Abstract:
    This document describes an extension to the TCP Authentication
    Option (TCP-AO) to encrypt the TCP segment payload in addition to
    providing TCP-AO's authentication of the payload, TCP header, and IP
    pseudoheader. This extension changes how the packet contents and
    headers are processed and which keys are derived, but not its key
    coordination or protection of long-lived connections.

=20



Please note that it may take a couple of minutes from the time of submissio=
n 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


From nobody Fri Mar 21 15:05:36 2014
Return-Path: <touch@isi.edu>
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 539D41A0048 for <tcpm@ietfa.amsl.com>; Fri, 21 Mar 2014 15:05:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level: 
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RP_MATCHES_RCVD=-0.547] 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 KFCYWA8QUcBd for <tcpm@ietfa.amsl.com>; Fri, 21 Mar 2014 15:05:31 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9238F1A0917 for <tcpm@ietf.org>; Fri, 21 Mar 2014 15:05:31 -0700 (PDT)
Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2LM4vkv028532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Mar 2014 15:04:57 -0700 (PDT)
Message-ID: <532CB78A.6090209@isi.edu>
Date: Fri, 21 Mar 2014 15:04:58 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Uma Chunduri <uma.chunduri@ericsson.com>, "tcpm@ietf.org" <tcpm@ietf.org>
References: <20140319215335.20587.83977.idtracker@ietfa.amsl.com> <532A1392.8030001@isi.edu> <1B502206DFA0C544B7A60469152008633F2268E8@eusaamb105.ericsson.se>
In-Reply-To: <1B502206DFA0C544B7A60469152008633F2268E8@eusaamb105.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/c2735TyQaeltBToXIQyH0TY3YWk
Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcp-ao-encrypt-00.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Mar 2014 22:05:34 -0000

On 3/21/2014 2:52 PM, Uma Chunduri wrote:
> Joe,
>
> Good to see this.
>
> Though it's still early to understand how  and why ENC is needed here;

I'm not sure either, except that if you want it, you can do it nearly 
for free (i.e., in terms of extending the protocol) with the information 
you already have.

> but  due to SDN/NFV/etc.. there are routing  specifications which
> talk about complete internal topology transport between AS'es or to
> a central controller..

AOK - SDN is definitely a good example.

> Frankly we were recently having this discussion internally and
realized this extension could be useful.
>
> Quick comments:
>
>
> 1.   TCP-AO NAT Extension  ==> Title inside the document says this..

Yeah - I reused the template and didn't figure that out before I sent 
it. I'll fix in the next rev.

> 2.   Given the in band processing AUTH/CIPHER by processors, it's better to give the flexibility  to have Symmetric/Stream
>        ciphers (remove the restriction) and yes, this requires introduction of  padding and pad length

But we can't pad; that would potentially run up against MTU 
considerations, as well as needing support for a length field somewhere 
(i.e., it'd change the option header too).

> 3.   Section 3
>       "...TCP-AO-NAT is intended
>     for use only where coordinated between endpoints for connections
>     that match the shared MKT parameters, as with all other MKT
>     parameters."
>
>     Should have been TCP-AO-ENC

Yup - will fix.

> 4. Section 4.1
>     We need another Master Key for Encryption.
>     Else we may potentially get the same key for both AUTH and ENC if the same algorithm is used.

It seems simpler to either salt the algorithm when used for encryption 
key derivation, or declare that the two keys must use different algs.

> 5. Section 4.1 - Something is missing here
>     "   PTCP-AO-ENC processes TCP packets in the same way as TCP-AO, except
>     that it replaces the authentication input and output processing as
>     follows:.."

It's complete, but poorly worded; I'll fix.

> 6.  Section 4.3. Per-Connection TCP-AO Parameters
>       Yes, can use the same SendID, RecvID with encryption and still can have 2 Master Keys one for encryption and one for AUTH.
>       The quality (randomness requirements etc..) of the master key can be different for both purposes.

Yes, but as noted above it just makes the MKT larger with no clear benefit.

Besides, if we salt the algs differently we would avoid a clash where 
the same key is used twice. If we leave it to the user to provide two 
keys, they may provide the same key for both encryption and auth.

> 7.  Section 5.
>       "..Note that the encryption
>     initialization vector MAY depend on TCP header state, but MUST NOT
>     depend on the processing of previous segments because segments may
>     arrive (and need to be decrypted) out of order."
>
>     IV is critical for some algorithms, this may need to be looked into further.
>     I remember FIPS tests are very hard on this.

Right, which is why we would need to take that into consideration if 
needed based on the alg, but that's an alg-specific consideration.

> 8. Section 7
>      "Where are required algorithms specified? This doc or a separate one?"
>     Separate.

Preference noted. I tend to agree, FWIW.

Thanks for the feedback.

Joe

>
>
> --
> Uma C.
>
> -----Original Message-----
> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Joe Touch
> Sent: Wednesday, March 19, 2014 3:01 PM
> To: tcpm@ietf.org
> Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcp-ao-encrypt-00.txt
>
> Hi, all,
>
> Given a few recent discussions on TCP encryption alternatives, I figured I'd throw my view into the mix.
>
> The following describes a variant of TCP-AO that, in addition to authenticating the TCP header and payload, also encrypts the payload.
>
> It's a fairly simple approach that seems like it might be useful whether or not we consider other TCP encryption approaches.
>
> Feedback welcome.
>
> Joe
>
> -------- Original Message --------
> Subject: New Version Notification for draft-touch-tcp-ao-encrypt-00.txt
> Date: Wed, 19 Mar 2014 14:53:35 -0700
> From: internet-drafts@ietf.org
> To: Dr. Joseph D. Touch <touch@isi.edu>, Joe Touch <touch@isi.edu>
>
>
> A new version of I-D, draft-touch-tcp-ao-encrypt-00.txt has been successfully submitted by Joe Touch and posted to the IETF repository.
>
> Name:		draft-touch-tcp-ao-encrypt
> Revision:	00
> Title:		A TCP Authentication Option Extension for Payload Encryption
> Document date:	2014-03-19
> Group:		Individual Submission
> Pages:		7
> URL:
> http://www.ietf.org/internet-drafts/draft-touch-tcp-ao-encrypt-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-touch-tcp-ao-encrypt/
> Htmlized:       http://tools.ietf.org/html/draft-touch-tcp-ao-encrypt-00
>
>
> Abstract:
>      This document describes an extension to the TCP Authentication
>      Option (TCP-AO) to encrypt the TCP segment payload in addition to
>      providing TCP-AO's authentication of the payload, TCP header, and IP
>      pseudoheader. This extension changes how the packet contents and
>      headers are processed and which keys are derived, but not its key
>      coordination or protection of long-lived connections.
>
>
>
>
>
> 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
>


From nobody Fri Mar 21 16:20:47 2014
Return-Path: <uma.chunduri@ericsson.com>
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 BDD201A01B1 for <tcpm@ietfa.amsl.com>; Fri, 21 Mar 2014 16:20:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QxNUqYcRxUAZ for <tcpm@ietfa.amsl.com>; Fri, 21 Mar 2014 16:20:42 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id C81461A0444 for <tcpm@ietf.org>; Fri, 21 Mar 2014 16:20:41 -0700 (PDT)
X-AuditID: c618062d-b7f858e0000031c7-ec-532cc6ec6be6
Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id DC.D3.12743.DE6CC235; Sat, 22 Mar 2014 00:10:37 +0100 (CET)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0387.000; Fri, 21 Mar 2014 19:20:30 -0400
From: Uma Chunduri <uma.chunduri@ericsson.com>
To: Joe Touch <touch@isi.edu>, "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: [tcpm] Fwd: New Version Notification for draft-touch-tcp-ao-encrypt-00.txt
Thread-Index: AQHPRVGrBUB3Gz2HyUWcdj8pCMGtoJrsKftg
Date: Fri, 21 Mar 2014 23:20:29 +0000
Message-ID: <1B502206DFA0C544B7A60469152008633F226A17@eusaamb105.ericsson.se>
References: <20140319215335.20587.83977.idtracker@ietfa.amsl.com> <532A1392.8030001@isi.edu> <1B502206DFA0C544B7A60469152008633F2268E8@eusaamb105.ericsson.se> <532CB78A.6090209@isi.edu>
In-Reply-To: <532CB78A.6090209@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [147.117.188.9]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyuXRPiO7bYzrBBlM2CFlsOzmfyWLdn7ks DkweS5b8ZPLY/X4rSwBTFJdNSmpOZllqkb5dAlfGgzVf2Apa+CtOnvzE2sD4lLuLkYNDQsBE 4lNLbBcjJ5ApJnHh3nq2LkYuDiGBI4wS+67eZgJJCAksZ5T4fjMQxGYT0JP4OPUnO4gtImAn 0Xl5D5gtLBApsXjeF2aIeJTEgsOLoGqMJNYfvckGYrMIqEosXvKXBcTmFfCV2H/8OCPEsv2M EtPPLQBLcAqoS/zZuhtsECPQRd9PrQE7gllAXOLWk/lMEJcKSCzZc54ZwhaVePn4HyuErSix r386O0S9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjFylBan luWmGxlsYgRGwzEJNt0djHteWh5ilOZgURLn/fLWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMH p1QDY+mCaaciIs4e/6dzVM7X3fWmcKTIthUHHUt/Trh3786LH3Nkj3ppr/S5lbZOr3m9jX/Z 0pDAeUYysyce/u5jsvmT7U2XTYt5bnWvL1X9t3mKhV9nv+KsppR1zy2NDzzV2PRkGWc90+sl Cn4flpidVTLd2Dk16qDzc8kL59c1vDCL/rNuflGFIacSS3FGoqEWc1FxIgAyDTYZVAIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/GJfBDlNbHS93S-ZwOjFpFeOP3Po
Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcp-ao-encrypt-00.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Mar 2014 23:20:45 -0000

2 quick comments in-line [Uma]:

--
Uma C.


-----Original Message-----
From: Joe Touch [mailto:touch@isi.edu]=20
Sent: Friday, March 21, 2014 3:05 PM
To: Uma Chunduri; tcpm@ietf.org
Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcp-ao-en=
crypt-00.txt



...
> 2.   Given the in band processing AUTH/CIPHER by processors, it's better =
to give the flexibility  to have Symmetric/Stream
>        ciphers (remove the restriction) and yes, this requires=20
> introduction of  padding and pad length

But we can't pad; that would potentially run up against MTU considerations,=
 as well as needing support for a length field somewhere (i.e., it'd change=
 the option header too).

[Uma]: Sure. Padding is needed for 2 reasons
1. Based on the algo to make it to the block size boundary
2. Also sometimes hardware crypto engines require 4 byte boundary.
Well, this should be seen bit more depending on the algorithms proposed for=
 both ENC and KDF.

...
> 6.  Section 4.3. Per-Connection TCP-AO Parameters
>       Yes, can use the same SendID, RecvID with encryption and still can =
have 2 Master Keys one for encryption and one for AUTH.
>       The quality (randomness requirements etc..) of the master key can b=
e different for both purposes.

Yes, but as noted above it just makes the MKT larger with no clear benefit.
Besides, if we salt the algs differently we would avoid a clash where the s=
ame key is used twice. If we leave it to the user to provide two keys, they=
 may provide the same key for both encryption and auth.

[Uma]: Right, in manual mode. But it's possible this could be provisioned  =
through KMP and master  key quality could be  central to the ENC (can quick=
ly become serious security requirement).
            If it's manual nothing much can be done, if you start with poor=
 quality (of course guidance should be provided)



From nobody Fri Mar 21 16:26:23 2014
Return-Path: <touch@isi.edu>
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 BF2FB1A06DF for <tcpm@ietfa.amsl.com>; Fri, 21 Mar 2014 16:26:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 YiG7etPNbPoU for <tcpm@ietfa.amsl.com>; Fri, 21 Mar 2014 16:26:20 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 2B15D1A0444 for <tcpm@ietf.org>; Fri, 21 Mar 2014 16:26:20 -0700 (PDT)
Received: from [10.120.117.145] (guest-wireless-upc-nat-206-117-88-006.usc.edu [206.117.88.6]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s2LNPqfD024446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Mar 2014 16:25:55 -0700 (PDT)
Message-ID: <532CCA82.8030205@isi.edu>
Date: Fri, 21 Mar 2014 16:25:54 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Uma Chunduri <uma.chunduri@ericsson.com>, "tcpm@ietf.org" <tcpm@ietf.org>
References: <20140319215335.20587.83977.idtracker@ietfa.amsl.com> <532A1392.8030001@isi.edu> <1B502206DFA0C544B7A60469152008633F2268E8@eusaamb105.ericsson.se> <532CB78A.6090209@isi.edu> <1B502206DFA0C544B7A60469152008633F226A17@eusaamb105.ericsson.se>
In-Reply-To: <1B502206DFA0C544B7A60469152008633F226A17@eusaamb105.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/3FF_wHffeg3_Gi9qkfoB9wLIGlA
Subject: Re: [tcpm] Fwd: New Version Notification for draft-touch-tcp-ao-encrypt-00.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Mar 2014 23:26:22 -0000

On 3/21/2014 4:20 PM, Uma Chunduri wrote:
> 2 quick comments in-line [Uma]:
...
> [Uma]: Sure. Padding is needed for 2 reasons
> 1. Based on the algo to make it to the block size boundary
> 2. Also sometimes hardware crypto engines require 4 byte boundary.

That's true only for non-stream cyphers.

> Well, this should be seen bit more depending on the algorithms proposed for both ENC and KDF.

We can pad for the KDF, but not the ENC alg. Option processing really 
should never change the size of the TCP payload.

> ...
>> 6.  Section 4.3. Per-Connection TCP-AO Parameters
>>        Yes, can use the same SendID, RecvID with encryption and still can have 2 Master Keys one for encryption and one for AUTH.
>>        The quality (randomness requirements etc..) of the master key can be different for both purposes.
>
> Yes, but as noted above it just makes the MKT larger with no clear benefit.
> Besides, if we salt the algs differently we would avoid a clash where the same key is used twice. If we leave it to the user to provide two keys, they may provide the same key for both encryption and auth.
>
> [Uma]: Right, in manual mode. But it's possible this could be provisioned  through KMP and master  key quality could be  central to the ENC (can quickly become serious security requirement).
>              If it's manual nothing much can be done, if you start with poor quality (of course guidance should be provided)

Let's hear back from others, perhaps during security review on this. 
It's not a big issue to do either method, but they're not compatible 
(both sides need to do the same thing).

I'll see if I can come up with a way of describing things that allows 
two master keys that could be identical and could use the same PRKs but 
are still sufficiently distinct; that way if the OOB key alg wants to 
negotiate different master keys it can.

Joe


From nobody Fri Mar 21 17:10:01 2014
Return-Path: <wes@mti-systems.com>
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 90FA61A08F5 for <tcpm@ietfa.amsl.com>; Fri, 21 Mar 2014 17:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQJTtqJ7YWkV for <tcpm@ietfa.amsl.com>; Fri, 21 Mar 2014 17:09:54 -0700 (PDT)
Received: from atl4mhob11.myregisteredsite.com (atl4mhob11.myregisteredsite.com [209.17.115.49]) by ietfa.amsl.com (Postfix) with ESMTP id 381841A08C7 for <tcpm@ietf.org>; Fri, 21 Mar 2014 17:09:54 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob11.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s2M09hRu032724 for <tcpm@ietf.org>; Fri, 21 Mar 2014 20:09:43 -0400
Received: (qmail 5274 invoked by uid 0); 22 Mar 2014 00:09:43 -0000
X-TCPREMOTEIP: 69.81.143.143
X-Authenticated-UID: wes@mti-systems.com
Received: from unknown (HELO ?192.168.1.142?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 22 Mar 2014 00:09:43 -0000
Message-ID: <532CD4B1.1020307@mti-systems.com>
Date: Fri, 21 Mar 2014 20:09:21 -0400
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, "tcpm@ietf.org" <tcpm@ietf.org>
References: <CAO249ycbAaCq3cWE7_KcPSGgf-zXFhtZRuo3XVQfJTx1TDLzWQ@mail.gmail.com>
In-Reply-To: <CAO249ycbAaCq3cWE7_KcPSGgf-zXFhtZRuo3XVQfJTx1TDLzWQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/pfc-X_vNDFNycGM_u01G7fsPfG0
Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-tcp-rfc4614bis-03
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Mar 2014 00:09:57 -0000

On 3/19/2014 12:56 AM, Yoshifumi Nishida wrote:
> Hello,
> 
> As we have discussed in the London meeting, we initiate WGLC
> for draft-ietf-tcpm-tcp-rfc4614bis-03. The WGLC will run until * April
> 4th *.
> The intended status of the draft is Informational.
> 
> If you have any comments or questions on this document, please send us
> before the deadline.
> The draft is available at:
> http://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-03


Many thanks to Alex for initiating and working on this update to RFC
4614 to get it this far.

One major comment:

- I recall after the last roadmap revision (4614) that we took the
  opportunity to write 6247 and make a bunch of things Historic.
  Since we unearthed several more old RFCs with "Unknown" status in
  this revision, at least some of those should probably go to Historic
  also.

  It probably makes more sense to do that as a short separate
  effort like 6247 was done, after this roadmap is published, rather
  than to bundle the status changes with this same document.  But,
  we should discuss it at least.

  I say this is major, because *if* people think it should be done
  inline in this roadmap, then there's more work to do.  To be clear,
  I would prefer not to do this inline in the roadmap though.  It
  is not an urgent task.

  Either way, I'll be happy to help with figuring out which ones to
  alter and what to do to them.  For instance, 675 should go to
  Historic, and show as being Obsoleted by 761, I believe.


Some minor comments:

(1) Section 4.6 text mentions both user timeouts and time-wait in the
    initial text, but it only includes RFC 5482, which is strictly the
    user timeout.  I think the mention of time-wait can be removed.

(2) I looked at RFC 794, and I'm not entirely sure it best fits now as
    "Implementation Advice" the way we have it here.  However, there's
    no place better that I see to put it.  The description of it should
    really boil down to something more like "This document clarifies
    that operating systems need to manage their limited resources,
    which may include TCP connection state, and that these decisions
    can be made with application input, but they do not need to be part
    of the TCP protocol specification itself."

(3) I wonder whether RFC 3360 "Inappropriate TCP Resets Considered
    Harmful" should be in Implementation Advice, or might be better
    in Architectural Guidelines.  It's more for people who build
    middleboxen than normal TCP implementations.

(4) In the 6429 description, we should change "be taken" to "take".

(5) I think we should change "Highspeed Congestion Control" to something
    more like "Congestion Control for High Rate Flows".

-- 
Wes Eddy
MTI Systems


From nobody Tue Mar 25 01:44:31 2014
Return-Path: <Alexander.Zimmermann@netapp.com>
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 79A161A0374 for <tcpm@ietfa.amsl.com>; Tue, 25 Mar 2014 01:44:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level: 
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zg0dVu_PNlD8 for <tcpm@ietfa.amsl.com>; Tue, 25 Mar 2014 01:44:27 -0700 (PDT)
Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) by ietfa.amsl.com (Postfix) with ESMTP id D927E1A036F for <tcpm@ietf.org>; Tue, 25 Mar 2014 01:44:27 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.97,727,1389772800";  d="asc'?scan'208";a="111845661"
Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 25 Mar 2014 01:44:26 -0700
Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.187]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 01:44:26 -0700
From: "Zimmermann, Alexander" <Alexander.Zimmermann@netapp.com>
To: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Thread-Topic: [multipathtcp] New Non-WG Mailing List: Tcpcrypt -- Discussion list for adding encryption to TCP
Thread-Index: AQHPSAZtkXu9RhSjwE2yneEbh/M83g==
Date: Tue, 25 Mar 2014 08:44:25 +0000
Message-ID: <523BB467-9868-4A70-87DB-D220652B2588@netapp.com>
References: <53311A54.6040206@it.uc3m.es>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.122.105.28]
Content-Type: multipart/signed; boundary="Apple-Mail=_2747D489-5191-4EBA-957D-E381B4490FCD"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/k2HfPCmu_3lcGY4_TTF6RzDmoZk
Subject: [tcpm] Fwd: [multipathtcp] New Non-WG Mailing List: Tcpcrypt -- Discussion list for adding encryption to TCP
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Mar 2014 08:44:29 -0000

--Apple-Mail=_2747D489-5191-4EBA-957D-E381B4490FCD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Again FYI

Anfang der weitergeleiteten Nachricht:

> Von: marcelo bagnulo braun <marcelo@it.uc3m.es>
> Betreff: [multipathtcp] Fwd: New Non-WG Mailing List: Tcpcrypt -- =
Discussion list for adding encryption to TCP
> Datum: 25. M=E4rz 2014 06:55:32 MEZ
> An: Multipath TCP Mailing List <multipathtcp@ietf.org>, =
<tcpm@ietf.org>
>=20
> FYI
>=20
>=20
> -------- Mensaje original --------
> Asunto: 	New Non-WG Mailing List: Tcpcrypt -- Discussion list for =
adding encryption to TCP
> Fecha: 	Mon, 24 Mar 2014 16:03:15 -0700
> De: 	IETF Secretariat <ietf-secretariat@ietf.org>
> Responder a: 	ietf@ietf.org
> Para: 	IETF Announcement List <ietf-announce@ietf.org>
> CC: 	mls.ietf@gmail.com, tcpcrypt@ietf.org
>=20
>=20
>=20
> A new IETF non-working group email list has been created.
>=20
> List address: tcpcrypt@ietf.org
> Archive: http://www.ietf.org/mail-archive/web/tcpcrypt/
> To subscribe: https://www.ietf.org/mailman/listinfo/tcpcrypt
>=20
> Purpose:
>=20
> The goal of this mailing list is to discuss encryption of TCP
> sessions, without necessarily requiring endpoint authentication
> in all cases (but while also making endpoint authentication
> possible). The initial purpose of the mailing list is to discuss the
> scope and a potential charter of a WG that would work
> on the definition of TCP extensions to support such encryption,
> or to find an existing WG to perform the work.
>=20
> For additional information, please contact the list administrators.
>=20
>=20
>=20
>=20
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp


--Apple-Mail=_2747D489-5191-4EBA-957D-E381B4490FCD
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlMxQegACgkQdyiq39b9uS6MAgCdGeyhCXrGGkOLk2VlXmbGkY+F
QZUAn0klKRKH98v8w3D7O7bRvpIkNhSy
=6nSo
-----END PGP SIGNATURE-----

--Apple-Mail=_2747D489-5191-4EBA-957D-E381B4490FCD--


From nobody Tue Mar 25 05:35:46 2014
Return-Path: <Alexander.Zimmermann@netapp.com>
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 F06461A00D1 for <tcpm@ietfa.amsl.com>; Tue, 25 Mar 2014 05:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level: 
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCJvBzp8_72h for <tcpm@ietfa.amsl.com>; Tue, 25 Mar 2014 05:35:15 -0700 (PDT)
Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id A81141A00CA for <tcpm@ietf.org>; Tue, 25 Mar 2014 05:35:15 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.97,728,1389772800";  d="asc'?scan'208";a="152738740"
Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 25 Mar 2014 05:35:12 -0700
Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.187]) by vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 05:35:12 -0700
From: "Zimmermann, Alexander" <Alexander.Zimmermann@netapp.com>
To: Wesley Eddy <wes@mti-systems.com>
Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-tcp-rfc4614bis-03
Thread-Index: AQHPQy+g9TP24VbggEGfY/X0rO3m3ZrstOyAgAWHXwA=
Date: Tue, 25 Mar 2014 12:35:11 +0000
Message-ID: <45E0F6BA-09CA-407A-9AE9-3EB9F3935340@netapp.com>
References: <CAO249ycbAaCq3cWE7_KcPSGgf-zXFhtZRuo3XVQfJTx1TDLzWQ@mail.gmail.com> <532CD4B1.1020307@mti-systems.com>
In-Reply-To: <532CD4B1.1020307@mti-systems.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.122.105.21]
Content-Type: multipart/signed; boundary="Apple-Mail=_5F0853B3-6251-484D-AB90-7AC5D4F4057D"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ALWQH8QosrKa_OcoyCwrLwo_p7g
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-tcp-rfc4614bis-03
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Mar 2014 12:35:18 -0000

--Apple-Mail=_5F0853B3-6251-484D-AB90-7AC5D4F4057D
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

Hi Wes,

Am 22.03.2014 um 01:09 schrieb Wesley Eddy <wes@mti-systems.com>:

> On 3/19/2014 12:56 AM, Yoshifumi Nishida wrote:
>> Hello,
>> 
>> As we have discussed in the London meeting, we initiate WGLC
>> for draft-ietf-tcpm-tcp-rfc4614bis-03. The WGLC will run until * April
>> 4th *.
>> The intended status of the draft is Informational.
>> 
>> If you have any comments or questions on this document, please send us
>> before the deadline.
>> The draft is available at:
>> http://tools.ietf.org/html/draft-ietf-tcpm-tcp-rfc4614bis-03
> 
> 
> Many thanks to Alex for initiating and working on this update to RFC
> 4614 to get it this far.
> 
> One major comment:
> 
> - I recall after the last roadmap revision (4614) that we took the
>  opportunity to write 6247 and make a bunch of things Historic.
>  Since we unearthed several more old RFCs with "Unknown" status in
>  this revision, at least some of those should probably go to Historic
>  also.

ACK

> 
>  It probably makes more sense to do that as a short separate
>  effort like 6247 was done, after this roadmap is published, rather
>  than to bundle the status changes with this same document.  But,
>  we should discuss it at least.
> 
>  I say this is major, because *if* people think it should be done
>  inline in this roadmap, then there's more work to do.  To be clear,
>  I would prefer not to do this inline in the roadmap though.  It
>  is not an urgent task.

I also prefer to make an additional doc. If we decide that this is way
we want to go, I can do an update of RFC 6247.

> 
>  Either way, I'll be happy to help with figuring out which ones to
>  alter and what to do to them.  For instance, 675 should go to
>  Historic, and show as being Obsoleted by 761, I believe.

I agree with all points mentioned below. Will include them in version 04

Alex

> 
> 
> Some minor comments:
> 
> (1) Section 4.6 text mentions both user timeouts and time-wait in the
>    initial text, but it only includes RFC 5482, which is strictly the
>    user timeout.  I think the mention of time-wait can be removed.
> 
> (2) I looked at RFC 794, and I'm not entirely sure it best fits now as
>    "Implementation Advice" the way we have it here.  However, there's
>    no place better that I see to put it.  The description of it should
>    really boil down to something more like "This document clarifies
>    that operating systems need to manage their limited resources,
>    which may include TCP connection state, and that these decisions
>    can be made with application input, but they do not need to be part
>    of the TCP protocol specification itself."
> 
> (3) I wonder whether RFC 3360 "Inappropriate TCP Resets Considered
>    Harmful" should be in Implementation Advice, or might be better
>    in Architectural Guidelines.  It's more for people who build
>    middleboxen than normal TCP implementations.
> 
> (4) In the 6429 description, we should change "be taken" to "take".
> 
> (5) I think we should change "Highspeed Congestion Control" to something
>    more like "Congestion Control for High Rate Flows".
> 
> -- 
> Wes Eddy
> MTI Systems
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm


--Apple-Mail=_5F0853B3-6251-484D-AB90-7AC5D4F4057D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlMxd/4ACgkQdyiq39b9uS6g8wCeNvnR1gfRNZpHjXHyTp6Vqhcu
kKEAoJVM0Tah30pAoIDBIUD/o+3tD+EY
=/aHY
-----END PGP SIGNATURE-----

--Apple-Mail=_5F0853B3-6251-484D-AB90-7AC5D4F4057D--


From nobody Tue Mar 25 09:12:11 2014
Return-Path: <marcelo@it.uc3m.es>
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 A343E1A00EE; Mon, 24 Mar 2014 22:55:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.811
X-Spam-Level: 
X-Spam-Status: No, score=-102.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, 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 8eice-CZXZet; Mon, 24 Mar 2014 22:55:35 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1751A00F2; Mon, 24 Mar 2014 22:55:34 -0700 (PDT)
Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C8FB976B2EA; Tue, 25 Mar 2014 06:55:32 +0100 (CET)
X-uc3m-safe: yes
Received: from [163.117.203.128] (unknown [163.117.203.128]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 88B168AA1EE; Tue, 25 Mar 2014 06:55:32 +0100 (CET)
Message-ID: <53311A54.6040206@it.uc3m.es>
Date: Tue, 25 Mar 2014 06:55:32 +0100
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Multipath TCP Mailing List <multipathtcp@ietf.org>, tcpm@ietf.org
References: <20140324230315.20999.31424.idtracker@ietfa.amsl.com>
In-Reply-To: <20140324230315.20999.31424.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20140324230315.20999.31424.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender IP whitelistedACL 131 matched, not delayed by milter-greylist-4.2.7 (smtp02.uc3m.es); Tue, 25 Mar 2014 06:55:32 +0100 (CET)
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20588.005
X-TM-AS-Result: No--9.892-7.0-31-1
X-imss-scan-details: No--9.892-7.0-31-1
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/sCSa7imdFAVGWNI-LFF5J6NCYQw
X-Mailman-Approved-At: Tue, 25 Mar 2014 09:11:58 -0700
Subject: [tcpm] Fwd: New Non-WG Mailing List: Tcpcrypt -- Discussion list for adding encryption to TCP
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Mar 2014 05:55:38 -0000

FYI


-------- Mensaje original --------
Asunto: 	New Non-WG Mailing List: Tcpcrypt -- Discussion list for adding 
encryption to TCP
Fecha: 	Mon, 24 Mar 2014 16:03:15 -0700
De: 	IETF Secretariat <ietf-secretariat@ietf.org>
Responder a: 	ietf@ietf.org
Para: 	IETF Announcement List <ietf-announce@ietf.org>
CC: 	mls.ietf@gmail.com, tcpcrypt@ietf.org



A new IETF non-working group email list has been created.

List address: tcpcrypt@ietf.org
Archive: http://www.ietf.org/mail-archive/web/tcpcrypt/
To subscribe: https://www.ietf.org/mailman/listinfo/tcpcrypt

Purpose:

The goal of this mailing list is to discuss encryption of TCP
sessions, without necessarily requiring endpoint authentication
in all cases (but while also making endpoint authentication
possible). The initial purpose of the mailing list is to discuss the
scope and a potential charter of a WG that would work
on the definition of TCP extensions to support such encryption,
or to find an existing WG to perform the work.

For additional information, please contact the list administrators.





From nobody Thu Mar 27 17:48:21 2014
Return-Path: <wes@mti-systems.com>
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 EDCF91A0765 for <tcpm@ietfa.amsl.com>; Thu, 27 Mar 2014 17:48:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxDKHwDWNG-H for <tcpm@ietfa.amsl.com>; Thu, 27 Mar 2014 17:48:14 -0700 (PDT)
Received: from atl4mhob14.myregisteredsite.com (atl4mhob14.myregisteredsite.com [209.17.115.52]) by ietfa.amsl.com (Postfix) with ESMTP id 375951A0410 for <tcpm@ietf.org>; Thu, 27 Mar 2014 17:48:14 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob14.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s2S0mAJo029153 for <tcpm@ietf.org>; Thu, 27 Mar 2014 20:48:10 -0400
Received: (qmail 2381 invoked by uid 0); 28 Mar 2014 00:48:10 -0000
X-TCPREMOTEIP: 69.81.143.143
X-Authenticated-UID: wes@mti-systems.com
Received: from unknown (HELO ?192.168.1.142?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 28 Mar 2014 00:48:10 -0000
Message-ID: <5334C6B6.4050900@mti-systems.com>
Date: Thu, 27 Mar 2014 20:47:50 -0400
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "tcpm@ietf.org" <tcpm@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/LYty--vs2-jzzpDe4QXv8nIRs2g
Subject: [tcpm] revision -02 of 793bis draft (errata addressed)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Mar 2014 00:48:19 -0000

I posted a revision of the RFC793bis draft:
https://datatracker.ietf.org/doc/draft-eddy-rfc793bis/

This revision builds on the last one by incorporating the errata
that exist on 793:
http://www.rfc-editor.org/errata_search.php?rfc=793&rec_status=15&presentation=table

Some are noted as incompletely dealt with, since other changes that
will be coming will either wipe them out or be more comprehensive
(e.g. due to 1122, urgent pointer deprecation, and other planned
changes).

-- 
Wes Eddy
MTI Systems


From nobody Thu Mar 27 18:14:40 2014
Return-Path: <wes@mti-systems.com>
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 115F31A0775 for <tcpm@ietfa.amsl.com>; Thu, 27 Mar 2014 18:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GY3ysEWU_E0K for <tcpm@ietfa.amsl.com>; Thu, 27 Mar 2014 18:14:34 -0700 (PDT)
Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5C22E1A040F for <tcpm@ietf.org>; Thu, 27 Mar 2014 18:14:34 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s2S1EVAF007861 for <tcpm@ietf.org>; Thu, 27 Mar 2014 21:14:31 -0400
Received: (qmail 18757 invoked by uid 0); 28 Mar 2014 01:14:31 -0000
X-TCPREMOTEIP: 69.81.143.143
X-Authenticated-UID: wes@mti-systems.com
Received: from unknown (HELO ?192.168.1.142?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 28 Mar 2014 01:14:31 -0000
Message-ID: <5334CCE3.5060209@mti-systems.com>
Date: Thu, 27 Mar 2014 21:14:11 -0400
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "tcpm@ietf.org" <tcpm@ietf.org>
References: <5334C6B6.4050900@mti-systems.com>
In-Reply-To: <5334C6B6.4050900@mti-systems.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/3aeFAd8VVrebdCJHQ8fQx7hKSUY
Subject: Re: [tcpm] revision -02 of 793bis draft (errata addressed)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Mar 2014 01:14:36 -0000

On 3/27/2014 8:47 PM, Wesley Eddy wrote:
> I posted a revision of the RFC793bis draft:
> https://datatracker.ietf.org/doc/draft-eddy-rfc793bis/
> 
> This revision builds on the last one by incorporating the errata
> that exist on 793:
> http://www.rfc-editor.org/errata_search.php?rfc=793&rec_status=15&presentation=table
> 
> Some are noted as incompletely dealt with, since other changes that
> will be coming will either wipe them out or be more comprehensive
> (e.g. due to 1122, urgent pointer deprecation, and other planned
> changes).
> 


I meant to note that the changes from 793 due to errata should be
pretty clear from the RFCdiff view:
http://tools.ietf.org/rfcdiff?url2=draft-eddy-rfc793bis-02.txt

Being able to isolate changes like that against the 793 baseline is
the reason I'm submitting incremental revisions rather than trying
to roll a whole bunch of things into a single posted revision.

-- 
Wes Eddy
MTI Systems