Re: [tsvwg] Comments on draft-ietf-tsvwg-rfc4960-bis-08

Marcelo Ricardo Leitner <> Wed, 02 December 2020 23:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3A1F3A0ADA for <>; Wed, 2 Dec 2020 15:46:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0ok1yOsa-kdR for <>; Wed, 2 Dec 2020 15:46:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::844]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EE5C73A0AB7 for <>; Wed, 2 Dec 2020 15:46:48 -0800 (PST)
Received: by with SMTP id v11so111353qtq.12 for <>; Wed, 02 Dec 2020 15:46:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=2doDJMbsizzwtGyMjkJdBChqciKNE9cPCMIT9YVwOd0=; b=htl46t4riqKLNLnK5y4lKSKBqvBnl6tRn31KKlZfMehI6Kdcx3zdPBXvIisCK5jtEc wnE+YXF6VtrCWTgT/Y0LjWZwXRVJbesRclpbyVKWo/on/I4HgzQ9dLX9IjaHY28UtK8q NS1vPKWKheFoPBlj0U2BCvL+/xoX9zToGmVTTlloba9H7N6JbHz+C0lhE81+1nwYQGVu RS4M4OwEYtePDiXk3lcH2ijQ/iKr30tPUZgWEQ5ERmO1IrrN0WlhLip8QBJevT/v7nzp WC27+Ufbn+xeiOF1JpXg6aTLTVhviJ5KgKdV/F5GBZ4svR0p79ao3C5XBS/jx5j2r2/0 eXew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=2doDJMbsizzwtGyMjkJdBChqciKNE9cPCMIT9YVwOd0=; b=lJr3ij+ByZ1QYl+1DRnXTVcjKBuvHVvvsCyoqzk6P++YLIjlq4bSjx7ej8qynARDYW 6dVMAG0KCveoQvsF6jWp5DJEVL5jbinwa4d8u05GiakMHOhGEwY8KqfQdkv44egreuOY rsQ6Yd+bDuHJ/pW3HsU7030nyQg/0pKwieyIn0XrkPqnmrNRAX8rLI29pTplo2Q8TIjz u9rySgkOzbfnrq+raZ+I8D+vR71LVKrb0Hlg91kjBNd6oh0DM/ZTTFcueHdzQTEcxqHV hWTpEgPME+IF5+xQjzU49hmXoQxUhzuaR3mw/QpIsz4HLE2D9xhPvRlStSH5rFbkIK5m F2hQ==
X-Gm-Message-State: AOAM530Jjm/eHq7jZWJx/ZsQ8PSgrRBWZyShVVhCagvuiqLAYmmdyeRT j1A1bdhcgOkv0wm+owtfZPU=
X-Google-Smtp-Source: ABdhPJxYQfEupMnHMEE3omNAvbyuxnpw9raW+P6+mC7e0/NfUFb4EzeBczLClX1BmPMLibL8aCq5LA==
X-Received: by 2002:ac8:48c1:: with SMTP id l1mr646684qtr.341.1606952807880; Wed, 02 Dec 2020 15:46:47 -0800 (PST)
Received: from localhost.localdomain ([]) by with ESMTPSA id c27sm232014qkk.57.2020. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Dec 2020 15:46:47 -0800 (PST)
Received: by localhost.localdomain (Postfix, from userid 1000) id 959BDC59FB; Wed, 2 Dec 2020 20:46:44 -0300 (-03)
Date: Wed, 02 Dec 2020 20:46:44 -0300
From: Marcelo Ricardo Leitner <>
To: Claudio Porfiri <>
Cc: "" <>
Message-ID: <20201202234644.GA944292@localhost.localdomain>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-rfc4960-bis-08
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Dec 2020 23:46:51 -0000


On Tue, Dec 01, 2020 at 08:07:53AM +0000, Claudio Porfiri wrote:
> Hi, 
> here are my comments on the draft:
> Generic:
> About chunks and timers, I'd wish to observe that having a t3-rtx timer on per chunk is
> computationally expensive, and that I don't see how it's possible that chunks being 

Where more exactly the RFC is giving that understanding?
I often read: "...if the T3-rtx timer of that address..." indicating
that it is, actually, per transport.

> bundled in the same SCTP packet can be lost independently.
> An effective implementation would have a T3-rtx timer on per SCTP packet and tie 
> all the transported chunks.
> About implementation of rx-buffer: it should be written somewhere that there MUST be 
> independent rx-buffers on per Association. This come from having observed that 
> implementations exist that share the same rx-buffer among all the Associations 
> (and endpoints) and advertise the arwnd with the full shared buffer size.
> The clear side effect is that a zero-window situation for an Association causes
> zero-window case on all the other Associations.

I second this. Can't see a reason for shared buffers, actually.  Even
if it is to fine grain control how much memory is being used, doesn't
seem like a good idea.

This is kind of covered by the description of a_rwnd in INIT and INIT
ACK chunks, like in [1] snippet below, but a clearer statement is
"During the life of the *association*, this buffer space SHOULD NOT be
lessened (i.e., dedicated buffers taken away from this association);"

The shared buffers can trigger from the zero window situation Claudio
mentioned to obscure cwnd instability. Linux supports both flavors
today, while the support for dedicated buffers was introduced back in
2005 (initial implementation was to use shared ones, and is the
default today).


> In section 6.1 "Transmission of DATA Chunks", part A, it's written:
>        If the sender continues to receive SACKs from the peer while
>        doing zero window probing, the unacknowledged window probes
>        SHOULD NOT increment the error counter for the association or any
>        destination transport address.  This is because the receiver
>        could keep its window closed for an indefinite time.
> Actually, when a fault happens at the SCTP User, the indefinite time of zero-window
> situation may cause a deadlock situation, I have observed that problem in the reality.
> It would be good suggesting for the implementor to have a supervision for zero-window
> situation that allows aborting the Association when that state lasts too long.

Not sure if that supervisory algorithm should be bound to the assoc
state. The assoc is fully functional here, other than the fact that
the user is sleeping on it. Likewise for TCP connections.

> In section 6.4 "Multi-Homed SCTP Endpoints"
>    By default, an endpoint SHOULD always transmit to the primary path,
>    unless the SCTP user explicitly specifies the destination transport
>    address (and possibly source transport address) to use.
> In situation where the primary path is not stable, this can cause traffic bouncing
> between paths. There are cases where cost is different per path, thus the SCTP adopter
> wants to use the primary path as soon as possible (i.e. when the path is IPSec encapsulated
> and the bandwidth on secondary IPSec tunnel is less than on the primary),
> but when the paths have the same cost, moving the association due to t3-rtx expiration
> towards another path would make the Association to use the path with better quality.
> That's why I'd change SHOULD with MAY and give the implementor a chance for deciding.

That puts the 'primary' concept at risk IMHO.

Best regards,