[tsvwg] draft-stewart-tsvwg-sctpecn

"Scheffenegger, Richard" <rs@netapp.com> Thu, 02 August 2012 23:58 UTC

Return-Path: <rs@netapp.com>
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 A77B211E8159 for <tsvwg@ietfa.amsl.com>; Thu, 2 Aug 2012 16:58:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.134
X-Spam-Level:
X-Spam-Status: No, score=-10.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5O4qvOH9Qyg for <tsvwg@ietfa.amsl.com>; Thu, 2 Aug 2012 16:58:32 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA2811E8150 for <tsvwg@ietf.org>; Thu, 2 Aug 2012 16:58:32 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.77,704,1336374000"; d="scan'208";a="672433901"
Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 02 Aug 2012 16:58:29 -0700
Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q72NwQkF023879; Thu, 2 Aug 2012 16:58:27 -0700 (PDT)
Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.34]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 16:58:26 -0700
From: "Scheffenegger, Richard" <rs@netapp.com>
To: "randall@lakerest.net" <randall@lakerest.net>, "tuexen@fh-muenster.de" <tuexen@fh-muenster.de>, "stevedong@huawei.com" <stevedong@huawei.com>
Thread-Topic: draft-stewart-tsvwg-sctpecn
Thread-Index: Ac1xCpQnt7Qi4CRkRDaO8iAwZyWYDA==
Date: Thu, 02 Aug 2012 23:58:26 +0000
Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F0D4E24FC@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.104.60.116]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, "Matthew Mathis (mattmathis@google.com)" <mattmathis@google.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Subject: [tsvwg] draft-stewart-tsvwg-sctpecn
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 02 Aug 2012 23:58:32 -0000

Hi,


While looking as to how other protocol do ECN feedback signaling, I found that this draft is missing (at least not mentioning) an interesting detail.

The existence of a CWR Chunk indicates, that the feedback signal is supposed to be reliable.

However, the ECN Echo chunk defines the Number of CE marked Packets as 32-bit unsigned int, and does not specify how a receiver should behave it never received a CWR chunk...

The sheer size of the ECN Echo chunk would lend itself to be a simple feedback signal, without any explicit signal from the sender.

Historically, in RFC4960, it appears that this chunk effectively contained only a single bit (no counter; only the presence of the chunk). In order to establish a reliable feedback for at most one ECN signal per RTT, a handshake mechanism (CWR chunk) is required. That mechanism was very much alike what TCP does with ECE / CWR.



IMHO, this draft should be more clear around the mechanism:

If a handshake is required, the 32-bit counter MUST NOT roll over at 2^32-1, but remain at that value until CWR is received.

The sheer size of the counter however makes it highly unlikely that the sender will not receive a signal (before the session collapses for lack of feedback from the receiver). So a handshake-less (CWR chunk optional on the sender?) is also feasible, but then the ECN counter MUST roll over...


As it stands now, the counter rolls over, and is reset via CWR...

Are there any specific reasons for this chimera mechanism? 

Does it allow for special use cases, which cannot be addressed by either handshake or simple counter alone?

I'm very interested in the answers to the last two questions, as I am one of the authors of an Accurate ECN feedback draft for TCP, and TCPM has a milestone to define an appropriate (accurate) feedback mechanism that allows more than 1 bit per RTT... 

Best regards,

Richard Scheffenegger

> draft-stewart-tsvwg-sctpecn-02
> Partially replaces (draft-stewart-tsvwg-sctp-nonce)
> IETF-78 suggested there was interest in this topic.
> Discussed at IETF-83, Paris.
> DUE: ECN is within the TSVWG Charter,
> will call for adoption on the list.
> Please comment on list.