IETF Logo Mail Archive

Re: [tsvwg] [tcpm] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt

"Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> Fri, 26 July 2019 15:19 UTC

Return-Path: <4bone@gndrsh.dnsmgr.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E8112011F for <tsvwg@ietfa.amsl.com>; Fri, 26 Jul 2019 08:19:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 Mo7AIpGq7GZC for <tsvwg@ietfa.amsl.com>; Fri, 26 Jul 2019 08:19:43 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96441200FF for <tsvwg@ietf.org>; Fri, 26 Jul 2019 08:19:43 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x6QFJbSJ029301; Fri, 26 Jul 2019 08:19:37 -0700 (PDT) (envelope-from 4bone@gndrsh.dnsmgr.net)
Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x6QFJb2P029300; Fri, 26 Jul 2019 08:19:37 -0700 (PDT) (envelope-from 4bone)
From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Message-Id: <201907261519.x6QFJb2P029300@gndrsh.dnsmgr.net>
In-Reply-To: <F1C80B2C-CCAB-4E19-BAF7-F13052D7A9F2@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Date: Fri, 26 Jul 2019 08:19:37 -0700
CC: "Scheffenegger, Richard" <rs.ietf@gmx.at>, tsvwg@ietf.org
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/MCqQL7q50N_UUU9PKvt5whn_8oA>
Subject: Re: [tsvwg] [tcpm] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jul 2019 15:19:46 -0000

> > On 26 Jul, 2019, at 9:03 am, Scheffenegger, Richard <rs.ietf@gmx.at> wrote:
> > 
> > Regarding the SCE signaling, my main feedback would be that the
> > immediate ACKing when the receiver observes a ECT1 (or a change of state
> > from CE to non-CE in the case of DCTCP) is brittle.
> 
> I think that may have been a poor choice of wording in the tcpsce draft, and doesn't adequately describe what we've actually implemented.  There was some time pressure, which didn't give me the opportunity to properly review what Rod had written.

*Sigh*  Quoting from the draft:
4.1.  Single ACK implementation

   Upon receipt of a packet an ACK is immediatly generated, the SCE
   codepoint is copied into the ESCE codepoint of the ACK.  This keeps
   the count of bytes SCE marked or not marked properly reflected in the
   ACK packet(s).  This valid implementation has the downside of
   increasing ACK traffic.  This implementation is NOT RECOMMENDED, but
   useful for experimental work.

I must re-iterate ":NOT RECOMMENDED:".

Shall I upgrade that to "MUST NOT BE IMPLEMENTED?" to squelch the
conversation around a valid experment?  Shall I not leave those that
are wanting to do non ack colapsed, immediate ack now type things as
discussed during the tcpm session with even a proposal of a bit to
say "please ack now"?

> 
> The actual requirements are that the number of bytes acked with the NS (ESCE) bit set are roughly equal to the number of payload bytes that arrived with an SCE mark.  Precisely how the receiver achieves that permits some flexibility.  Simple implementations may find that an immediate-ack of SCE-marked packets offers adequate performance.
> 
> The Linux receiver actually immediately flushes any pending acks up to the *previous* segment when the state of the SCE marking *changes*, allowing consecutive packets with the same SCE state to be coalesced by the normal delayed-ack logic.  The ack volume is then inflated only slightly compared to an unmarked connection, and may actually involve fewer acks than a connection involving CE marks or losses (during which delayed acks are temporarily disabled).


This other valid implementation is discussed in 4.2 and 4.3.

>  - Jonathan Morton
-- 
Rod Grimes                                                 rgrimes@freebsd.org

v2.23.0 | Report a Bug | By Email