Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn

"Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com> Mon, 16 July 2018 17:48 UTC

Return-Path: <michael.scharf@nokia.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A91130E3E; Mon, 16 Jul 2018 10:48:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
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 5ev1IhxamPiB; Mon, 16 Jul 2018 10:48:21 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on0711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::711]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D54A130EB3; Mon, 16 Jul 2018 10:48:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6k1Tnax+Uu7H/TRtOgqytCRRLxgG7iNxNRGPmooRM7Q=; b=WHy4+ETqj+C0wo3ZphdpmUIdhrOoLBXwaran6z3MMiIs3w1uVD5u8OSL6MHeW2v/IDQQDjmiNK3nEWwYT7yMNlfDjtiYTBcD585hIeC2vvoC49ITQneEpMPsy4+ns6V1kkgM7emtimp3h39ObzINRsj0/4oTaZwKo+0LpypkYts=
Received: from VI1PR07MB0880.eurprd07.prod.outlook.com (10.161.108.22) by VI1PR07MB3486.eurprd07.prod.outlook.com (10.175.244.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.14; Mon, 16 Jul 2018 17:48:18 +0000
Received: from VI1PR07MB0880.eurprd07.prod.outlook.com ([fe80::3c69:da1e:3095:ab25]) by VI1PR07MB0880.eurprd07.prod.outlook.com ([fe80::3c69:da1e:3095:ab25%11]) with mapi id 15.20.0973.013; Mon, 16 Jul 2018 17:48:17 +0000
From: "Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com>
To: "Scheffenegger, Richard" <rs.ietf@gmx.at>, "draft-ietf-tcpm-accurate-ecn@ietf.org" <draft-ietf-tcpm-accurate-ecn@ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
Thread-Index: AdQceOJERSLj2vrfRDK99tsOpJm3vgAbKySAABFOwRA=
Date: Mon, 16 Jul 2018 17:48:17 +0000
Message-ID: <VI1PR07MB08800A9BA1D2195D62A1FE32935D0@VI1PR07MB0880.eurprd07.prod.outlook.com>
References: <AM2PR07MB086725AB3E0DFF2CFFAAE07A935E0@AM2PR07MB0867.eurprd07.prod.outlook.com> <25ea555d-8eea-57f1-8652-8dd234441010@gmx.at>
In-Reply-To: <25ea555d-8eea-57f1-8652-8dd234441010@gmx.at>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [92.203.197.39]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB3486; 6:uYH+x5fIxNSJ/kckY9NWv0I0KMwGekAlSNJvMIkHcyrn+XzKIue3xS0jVvk/kqLvFESW3C9TnAU7kGOinDhww0KUY9bFqE0HMnIIjrNcrSxXlcCbPm/f3YwT7TaK+VWrL5mq+dcWs4AZSB49wKa0pPqVKoYdjdgmC0j5OiCKmS9CF4JThZU1Vtbt8f7ybekCIrFI2yXTC9kDNdql80NyOdgLUSjEoX5gvSxgp3Z6kXiHy7mCZpX1Ss43C4lBt2lV1gosEaluLR4WjAt6akLBGbucwRNOR8xMuZ1GDA5S3HwVmuwY87jmn6sOWZIPtNvPBVWMNSgo001XkIzbmBcfk+TABCVR7pB6++5HAgju26u0vQHprBd9kEkZKOtqU89mabOK974rBUtwhspPa3M/aW7vxRQY9n2vahIm/UeHLUrq9ANCoqt+oA9RHHVGvcwoc2Z1e1JKPsinlyqjqtH2QQ==; 5:v8tkh0dF9C6ysKji4Be/TniISv4g7/PprsexSZUgpkLaMjfMEH2ytmdAua3Vge5rYDPlmsxlO3ts7s+nPzsAZ5gL+nytM+q+hOk9lhn/3DYPTlb1/iju9FyeV6HAb2aLuVum2R0DEuUEyMbVMsePZoM7GjJivQQ5V8iYVhQI68M=; 7:ft/fu1FtrLXr+A17Kdci30t5w1HETNSF3PhITWjvLiLRrBA0RqClgIlkU1SJHs+cidi26yVAxBGtiwpTH8gIPY8K3sg0h5qMlDD/B+pd7GDRKAJRKxVBuyA5noGrWgpdWYYKSHqG/eXbXOnsV1Vr7FGeH/pKYhA7LwZGTyLwmPJruB8JerOOGkyQJsgzFTyFVmIXAg4iTDCZudWrZsjnQAzmzB8iEJAhl+WomuNZJbMkhxIbTDVIA7h8U7JcU96d
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 2cff991c-bf37-4508-490b-08d5eb445039
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:(109105607167333); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7193020); SRVR:VI1PR07MB3486;
x-ms-traffictypediagnostic: VI1PR07MB3486:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com;
x-microsoft-antispam-prvs: <VI1PR07MB348661FDB4D6A2981A8E1F8C935D0@VI1PR07MB3486.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(72170088055959)(192374486261705)(82608151540597)(109105607167333);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231311)(11241501184)(806099)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:VI1PR07MB3486; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB3486;
x-forefront-prvs: 073515755F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(396003)(136003)(366004)(346002)(53754006)(13464003)(199004)(189003)(486006)(476003)(6306002)(9686003)(2900100001)(256004)(66066001)(14444005)(186003)(11346002)(446003)(26005)(2201001)(68736007)(3846002)(2906002)(74316002)(6116002)(86362001)(7736002)(229853002)(6436002)(55016002)(305945005)(5660300001)(966005)(478600001)(6246003)(81166006)(33656002)(8676002)(25786009)(53936002)(81156014)(14454004)(5250100002)(6506007)(97736004)(316002)(53546011)(2501003)(102836004)(76176011)(7696005)(8936002)(99286004)(106356001)(105586002)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB3486; H:VI1PR07MB0880.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: D8vzJmSezv7tSsnh/JeOcaDsEfH7BqcfjwKuSAHz24XqOHnYCZBtsSOG83+HV/iPtRaGPxu5qq6U4RxaAHpe+9xaLw9XnISE/Mhah6RGeP7vc19uZxR4bHjpV7+dnimJZXFLRusSb0g8db4BPARYJZFHNy8Eh8cN80qClebk3qAJKeRUuT7+CXdXNpR8Uq+P3036B2A5F6ZXocq1vbyp7+78+htjNJWQxj0fo9JZKP4rBybqGpX0hQHP8nui4WMiymHg52mEzJRuUw7clDENR1bbbETRp4/h5PS/N8jjLEJt5qwWHMrds1/MUDlKRtjofkaMpAfWsfPY3pM++6SAjXueUpxFzmELZl9P8o35vYzTM42bqJk++gDqiL0GUOz/tnvpv8EoNZm4Yordwks3iQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2cff991c-bf37-4508-490b-08d5eb445039
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2018 17:48:17.8077 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3486
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/D2gBhPpEzJhKOGPgzNvjNtXxY-o>
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
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: <https://mailarchive.ietf.org/arch/browse/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, 16 Jul 2018 17:48:25 -0000

Inline...

> -----Original Message-----
> From: Scheffenegger, Richard [mailto:rs.ietf@gmx.at]
> Sent: Monday, July 16, 2018 11:16 AM
> To: Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com>;
> draft-ietf-tcpm-accurate-ecn@ietf.org; tcpm@ietf.org
> Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
> 
> Hi Michael,
> 
> 
> 
> Am 15.07.2018 um 22:54 schrieb Scharf, Michael (Nokia - DE/Stuttgart):
> > Hi all,
> >
> > While reading draft-ietf-tcpm-accurate-ecn-07, I noticed the following:
> >
>  > [...]
>  >
> > Section 7.  Security Considerations
> >
> > [ms] I wonder about the security implications of "confusing" classic ECN and
> AccECN feedback in (passive) network monitoring solutions, most notably if
> packet sampling is used and no per-connection state is applied. At least
> theoretically, passive monitoring of "classic ECN" TCP header flags could be
> used for network monitoring, e.g., to estimate congestion levels in a
> network, no? How would such a (hypothetical) passive monitoring solution
> be able to distinguish the standard ECN feedback from an ongoing AccECN
> experiment, in particular in a sampled packet stream w/o having access to
> the SYN negotiation? Would there be security or safety implications when
> experimenting with AccECN in networks using network monitoring solutions
> that only support ECN as standardized by the IETF?
> >
> 
> For the safety aspect, if a middlebox meddles with the tcp header bits, and
> doesn't forward segments with specific ACE field codepoints, a reasonable
> response would be to resend the second or third retransmission with ECN
> disabled, and disable ECN for the remainder of the session. However, none
> of the large scale measurements conducted so far has found an indication of
> such a middlebox misbehavior to warrant text here. The regular AccECN
> negotiation will capture all known misbehaving middleboxes.

This comment is not about middleboxes; it is about passive network monitoring for traffic engineering.

> As to the passive monitoring - Mirja and Brian will certainly expand on this,
> but sampling ever so often should expose ACE field codepoints with high
> probability, which are unlikely or not possible with RFC3168 ECN (e.g. CWR +
> ECE is very unlikely - pure ACKs are not ECT marked in RFC3168, and
> bidirectional data exchange without stretches of pure acks is not common),
> anything with the former "NS" bit set has never been observed on the public
> internet to my knowledge. To summarize random sampling has at least a
> 5/8th chance to detect AccECN. However, as r.cep (section 3.2) is initialized to
> a value of 5 (101b), and many (short) flows probably rarely encounter a CE
> mark, the chance to detect, by random sampling, the presence of AccECN
> passively is even higher than this.  Short flow with up to 2 CE marks are
> immediately detectable, as the former "NS" bit remains set.

To me, this sort of discussion belongs into the document.

> As to the passive monitoring of the congestion levels - the same problem of
> having only 1 bit signal per RTT applies here too, not? Also, you probably
> don't know where the congestion point (doing the CE marks) is from your
> vantage point, but looking at the TCP header flags to estimate the congestion
> levels is IMHO not the correct approach - for that, you'd want to evaluate the
> IP header "CE" marks, and AccECN does not change that at all...

Agreed, but it may not be easy to figure out if some passive monitoring solution still analyzes the standardized ECN bits in the TCP header.

Michael

> If anything, AccECN should improve the passive monitoring of congestion
> *levels* (on asymetric paths) as now the monitoring point can track each CE
> in the reverse path; formerly, you could only use the stream of ECEs to
> estimate the connection receive window (spin bit), but not the extent of
> congestion in the network...
> 
> This "former use" of the ECE bit could be taken over by a different signal -
> see https://tools.ietf.org/html/draft-trammell-tsvwg-spin :)
> 
> Best regards,
>    Richard
> 
> 
> 
>