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

[Marcelo Ricardo Leitner <[e-mail]>]

Hi,

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
welcomed.
"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).

1.https://www.ietf.org/archive/id/draft-ietf-tsvwg-rfc4960-bis-08.html#section-3.3.2-12.4.1

> 
> 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,
Marcelo