Re: [tsvwg] draft-stewart-tsvwg-sctpecn

Randy Stewart <randall@lakerest.net> Fri, 03 August 2012 15:56 UTC

Return-Path: <randall@lakerest.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 3AE5921F8E19 for <tsvwg@ietfa.amsl.com>; Fri, 3 Aug 2012 08:56:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 okcW6VHfgrth for <tsvwg@ietfa.amsl.com>; Fri, 3 Aug 2012 08:56:35 -0700 (PDT)
Received: from lakerest.net (lakerest.net [70.155.160.98]) by ietfa.amsl.com (Postfix) with ESMTP id F2C7321F8E20 for <tsvwg@ietf.org>; Fri, 3 Aug 2012 08:56:34 -0700 (PDT)
Received: from [10.1.1.141] (bsd3.lakerest.net [70.155.160.101]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id q73FqcY0001393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 3 Aug 2012 11:52:39 -0400 (EDT) (envelope-from randall@lakerest.net)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: Randy Stewart <randall@lakerest.net>
In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F0D4E24FC@SACEXCMBX02-PRD.hq.netapp.com>
Date: Fri, 03 Aug 2012 11:52:38 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <955ED31B-9201-43FA-8C8C-13B622DB2D80@lakerest.net>
References: <012C3117EDDB3C4781FD802A8C27DD4F0D4E24FC@SACEXCMBX02-PRD.hq.netapp.com>
To: "Scheffenegger, Richard" <rs@netapp.com>
X-Mailer: Apple Mail (2.1278)
Cc: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "tuexen@fh-muenster.de" <tuexen@fh-muenster.de>, "Matthew Mathis (mattmathis@google.com)" <mattmathis@google.com>, "stevedong@huawei.com" <stevedong@huawei.com>
Subject: Re: [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: Fri, 03 Aug 2012 15:56:36 -0000

Richard:

Hmm

Re-reading the document a bit, I don't see that it does not tell
you to retransmit the chunk in the receiver side (5.3) we state:

"
After transmission of the ECN Echo chunk, usually bundled with the
   SACK, the receiver does NOT discard the ECN Echo chunk.  Instead it
   keeps the chunk in its queue and continues to send this chunk bundled
   with at least a SACK chunk on each outgoing packet, updating it as
   described above if other CE codepoint data packets arrive.  The ECN
   Echo chunk should only be discarded when a CWR Chunk arrives holding
   a TSN value that is greater than or equal to the value inside the ECN
   Echo Chunk.
"

If this is not clear enough please let me know a wording that would make it clearer.

Note that the ECN echo continues to be received until a CWR shows up
with a TSN number at least as big as the TSN sent in the ECN Echo.

R

On Aug 2, 2012, at 7:58 PM, Scheffenegger, Richard wrote:

> 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.
> 
> 

-----
Randall Stewart
randall@lakerest.net