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

[Gorry Fairhurst <[e-mail]>]

MANY, MANY, thanks Claudio!

We rely on people to read and review (or simply note comments) on the 
active WG drafts. Your input is very much appreciated, and I'll strongly 
encourage anyone who has a technical interest in SCTP to review this 
document and offer comments/questions, these are essential to developing 
good standards!

I'm sure the document editors will follow-up on-list, if you have any 
more questions, please ask.

Gorry

On 18/11/2020 08:31, 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
> 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.
>
> 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.
>
>
> 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.
>
> Section 7.3 "Path MTU Discovery"
>     An endpoint SHOULD apply these techniques, and SHOULD do so on a per-
>     destination-address basis.
> In my opinion SHOULD is a MUST.
>
> Section 8.4 " Handle "Out of the Blue" Packets"
> The whole section assumes that a single SCTP Host is taking care of a computing machine,
> whereas it can be better for the implementor to have multiple SCTP Host instances taking
> care of different SCTP Endpoint within the same machine.
> In my opinion for being considered OOTB, an SCTP packet must be addressed to one of the
> SCTP Endpoints belonging to a specific SCTP Host.
> With the current description, whenever a situation requires to have separated SCTP Hosts
> in the same machine, a filtering mechanism is needed to avoid the hosts to mutually abort the
> traffic, and when the filtering mechanism is implemented the behavior is the one I wish
> to have in the host itself i.e. to only take care of the traffic directed towards the
> SCTP Endpoints defined for it.
> In the part
>     8)  The receiver SHOULD respond to the sender of the OOTB packet with
>         an ABORT.
> I think that SHOULD is to be replaced by MAY.
>
>
> Section 16 " Suggested SCTP Protocol Parameter Values"
>     The following protocol parameters are RECOMMENDED:
>
>     RTO.Initial:  1 second
>     RTO.Min:  1 second
>     RTO.Max:  60 seconds
>     Max.Burst:  4
>     RTO.Alpha:  1/8
>     RTO.Beta:  1/4
>     Valid.Cookie.Life:  60 seconds
>     Association.Max.Retrans:  10 attempts
>     Path.Max.Retrans:  5 attempts (per destination address)
>     Max.Init.Retransmits:  8 attempts
>     HB.interval:  30 seconds
>     HB.Max.Burst:  1
>     SACK.Delay:  200 milliseconds
>
> The timers used depend on the actual network, there are cases where
> in order to fulfil the requirements, they need to be set one order of
> magnitude below the values recommended. (SIGTRAN and RAN).
> I'd suggest not to state absolute values, but to provide a criteria
> for selecting those values.
> In the signaling networks the ratio is
> RTO.Max = 4 * RTO.Min
> RTO.Initial = 2 * RTO.Min
> HB.interval = 20 * RTO.Min
> SACK.Delay = RTO.Min / 5
>
>
>
> Best regards,
> Claudio Porfiri
>
>
>
> Ericsson
>   
> Claudio Porfiri
> System Developer
>   
> Developer
> BNEW DNEW NSV PPA RAN Infra Architecture
> Mobile: [phone]
> [e-mail]
>   
>   
> Ericsson
> Isafjordsgatan 14E
> 164 80,Stockholm
> Sweden
>   
> Our commitment to Technology for Good and Diversity and Inclusion contributes to positive change in
> the Networked Society.
> Follow us on: Facebook LinkedIn Twitter
> Legal entity:ERICSSON AB registration number 556056-6258, registered office in
>   This communication is confidential. Our email terms
> www.ericsson.com/en/legal/privacy/email-disclaimer