M3UA retransmissions on T(ack) expiry

[David Laight-3]

RFC 4666 suggests that ASP Up/Down/Active/Inactive be
retransmitted when T(ack) expires.
In my opinion this is completely pointless.

M3UA runs over a reliable transport (usually SCTP) so
the initial message cannot get 'lost' in the network.

Lack of a response has to indicate that something much
more serious is wrong (eg the connected remote system
isn't running M3UA), so the only real recovery is to
disconnect the SCTP connection itself and retry the
connection later - hopefully with different configuration
parameters somewhere.

Resending the messages only leaves to greater problems having
to handle unexpected (duplicate) ack messages if the underlying
problem is that the timeout is too short.

Is there some other reason why the RFC suggusts these messages
be retransmitted?

        David.

Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)  
P Please consider the environment and don't print this e-mail unless you really need to
_______________________________________________
Sigtran mailing list
Sigtran@...
https://www.ietf.org/mailman/listinfo/sigtran

[Chris Benson-2]

David,

I cannot comment on the intention(s) of the authors, but
I note that RFC 4666 Section 4.3.4.1 (ASP Up Procedures)
states that an SGP may consider an ASP locked out for local
management reasons, and must then reply to an ASP Up with
an Error message "Refused - Management Blocked".

At its discretion, the ASP "MAY" resend the ASP Up after
not receiving a positive ASP Up Ack messages within T(ack)
timer period. I have presumed that this is so the ASP can
move to Inactive state as soon as "management un-blocked"
by the SGP with minimal latency (default T(ack) 2 seconds).

The sixth paragraph of Section 4.3.4.1 states that the
ASP MAY [...] resend ASP Up messages until it receives
an ASP Up Ack message. Alternatively, the re-transmission
policy may be delegated to the Layer Manager, which could
choose to implement your proposed SCTP shutdown, and retry.
I think that would be too Draconian, in case the SGP were
just temporarily locking out new APS's during, say an
internal database update.

I only addressed the ASP Up message, but I believe similar
consideration apply, at least to ASP Active requests.

With thanks, from Chris Benson.

Chris Benson, Software Engineer,
Adax Inc., Berkeley, California, USA.
    cbenson@...
    www.adax.com

On Wed, 1 Oct 2008, David Laight wrote:

>>  Date: Wed, 1 Oct 2008 10:28:02 +0100
>>  From: David Laight <David.Laight@...>
>>  To: sigtran <sigtran@...>
>>  Subject: [Sigtran] M3UA retransmissions on T(ack) expiry
>>  
>>  RFC 4666 suggests that ASP Up/Down/Active/Inactive be
>>  retransmitted when T(ack) expires.
>>  In my opinion this is completely pointless.
>>  
>>  M3UA runs over a reliable transport (usually SCTP) so
>>  the initial message cannot get 'lost' in the network.
>>  
>>  Lack of a response has to indicate that something much
>>  more serious is wrong (eg the connected remote system
>>  isn't running M3UA), so the only real recovery is to
>>  disconnect the SCTP connection itself and retry the
>>  connection later - hopefully with different configuration
>>  parameters somewhere.
>>  
>>  Resending the messages only leaves to greater problems having
>>  to handle unexpected (duplicate) ack messages if the underlying
>>  problem is that the timeout is too short.
>>  
>>  Is there some other reason why the RFC suggusts these messages
>>  be retransmitted?
>>  
>>   David.
>>  
>>  Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
>>  Registration No: 1397386 (Wales)  
>>  P Please consider the environment and don't print this e-mail unless you really need to
>>  _______________________________________________
>>  Sigtran mailing list
>>  Sigtran@...
>>  https://www.ietf.org/mailman/listinfo/sigtran
>>  

_______________________________________________
Sigtran mailing list
Sigtran@...
https://www.ietf.org/mailman/listinfo/sigtran