IETF Logo Mail Archive

Re: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04

Michael Welzl <michawe@ifi.uio.no> Thu, 16 March 2017 08:58 UTC

Return-Path: <michawe@ifi.uio.no>
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 146BB12709D; Thu, 16 Mar 2017 01:58:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 akfaJpo65ja9; Thu, 16 Mar 2017 01:57:59 -0700 (PDT)
Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A88C127076; Thu, 16 Mar 2017 01:57:59 -0700 (PDT)
Received: from mail-mx02.uio.no ([129.240.10.43]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <michawe@ifi.uio.no>) id 1coREL-0000fz-Sg; Thu, 16 Mar 2017 09:57:57 +0100
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx02.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from <michawe@ifi.uio.no>) id 1coREL-000F3l-0b; Thu, 16 Mar 2017 09:57:57 +0100
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <58CA5242.4050802@erg.abdn.ac.uk>
Date: Thu, 16 Mar 2017 09:57:56 +0100
Cc: Praveen Balasubramanian <pravb@microsoft.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "draft-ietf-tcpm-dctcp@ietf.org" <draft-ietf-tcpm-dctcp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <733029B7-2373-446A-8269-309AC421FA43@ifi.uio.no>
References: <58C66BB3.1000003@erg.abdn.ac.uk> <CY4PR21MB027775A417785976A70C6B11B6260@CY4PR21MB0277.namprd21.prod.outlook.com> <0B589CBD-EE0D-46CD-88EC-9569ABECDED0@ifi.uio.no> <58CA5242.4050802@erg.abdn.ac.uk>
To: "<gorry@erg.abdn.ac.uk> Fairhurst" <gorry@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.2104)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx02.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no;
X-UiO-Ratelimit-Test: rcpts/h 18 msgs/h 11 sum rcpts/h 19 sum msgs/h 12 total rcpts 52776 max rcpts/h 54 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.010, RP_MATCHES_RCVD=-0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 16098758921EEC4830192B66ECFB45869D4EAA93
X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 11 total 12639 max/h 21 blacklist 0 greylist 0 ratelimit 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/Wl8MmEZwZ2axxfvxaGHZ59ACE_w>
Subject: Re: [tcpm] WGLC comments for draft-ietf-tcpm-dctcp-04
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 16 Mar 2017 08:58:01 -0000

> On 16 Mar 2017, at 09:52, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> 
> On 16/03/2017, 08:26, Michael Welzl wrote:
>> Hi,
>> 
>> I haven't read the draft since long ago (one of the first versions), but I just read this dialogue and I have only one comment, so I'm removing everything else:
>> 
>> 
>>> ---
>>> 
>>> 3.4.  Handling of SYN, SYN-ACK, RST Packets
>>> 
>>>   " The switching fabric can drop TCP packets that do not have the ECT
>>>    set in the IP header.  If SYN and SYN-ACK packets for DCTCP
>>>    connections do not have ECT set, they will be dropped with high
>>>    probability.  For DCTCP connections, the sender SHOULD set ECT for
>>>    SYN, SYN-ACK and RST packets."
>>> 
>>> - I'd take the position that the fabric can and will drop any packets under overload, as per RFC7567. I'd prefer to explicitly state that to avoid a misconception that ECT eliminates all drop (rather than nearly all drops).
>>> 
>>> 
>>>>> Change this to : " If SYN and SYN-ACK packets for DCTCP connections do not have ECT set in the IP header, they will likely be dropped by the switching fabric under load. For DCTCP connections, the sender SHOULD set ECT for SYN, SYN-ACK and RST packets."
>> To me, "will likely be dropped by the switching fabric under load" doesn't sound quite right - as if they would most probably be dropped whenever there is any form of load (no matter how much). I would suggest to change this to "...they are more likely to be dropped by the switching fabric under load."
>> 
>> Cheers,
>> Michael
> I agree with Michael, but also I don't see it is correct for transport protocolsto need a very specific network behaviour. The choice of which packets are dropped is a design choice of the AQM: If we were to see FQ-Codel or FQ-PIE (for exmaple) deployed, then a common behaviour would be to separately queue new flows (even if non-ECT) - Switch design can change - I therefore think we should not be assuming a specific switch behaviour, but also I do think the ID does not need to go there ....  because I suspect the clause could perhaps be written differently...
> 
> - I'd suggest to change to:
> "SYN and SYN-ACK packets for DCTCP connections set the ECT(0) codepoint in the IP header, this ensures they receive the same treatment as other DCTP packets when forwarded by a switching fabric under load. For DCTCP connections, the sender SHOULD set ECT for SYN, SYN-ACK and RST packets."

This is just an ACK to say that I agree.

Cheers,
Michael

v2.23.0 | Report a Bug | By Email