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

[Claudio Porfiri <[e-mail]>]

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