headers
David Laight | 1 Oct 2008 11:28

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
Permalink | Reply | 1 comment |
headers
Chris Benson | 2 Oct 2008 00:05

Re: M3UA retransmissions on T(ack) expiry

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lukas Alig | 2 Oct 2008 14:33
Picon
Favicon

Statistics in M3UA

Hi,

 

Are there any RFCs or other specifications available for collecting statistics for M3UA as well as for SCTP?

 

Any help welcome.

 

Lukas Alig

 

_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
Permalink | Reply | 0 comments |
headers
Ronald Nsubuga | 2 Oct 2008 15:03
Favicon

Re: Statistics in M3UA

Hello Lukas,

Have taken a look at these links? Could they be having what you are looking for?



Regards

On Thu, Oct 2, 2008 at 3:33 PM, Lukas Alig <lukas.alig <at> datazug.ch> wrote:

Hi,

 

Are there any RFCs or other specifications available for collecting statistics for M3UA as well as for SCTP?

 

Any help welcome.

 

Lukas Alig

 


_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran




--
Regards,

Ronald Nsubuga,
skype: nsptash

"I don't speak for anybody but myself - that's enough trouble"
_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
Permalink | Reply | 1 comment |
headers
Lukas Alig | 2 Oct 2008 16:01
Picon
Favicon

Re: Statistics in M3UA

Ok, thanks, will have a look

 

Regards,

Lukas

 

Von: Ronald Nsubuga [mailto:nsubugr <at> itxpertz.net]
Gesendet: Donnerstag, 2. Oktober 2008 15:04
An: Lukas Alig
Cc: sigtran <at> ietf.org
Betreff: Re: [Sigtran] Statistics in M3UA

 

Hello Lukas,

 

Have taken a look at these links? Could they be having what you are looking for?

 

 

 

Regards

 

On Thu, Oct 2, 2008 at 3:33 PM, Lukas Alig <lukas.alig <at> datazug.ch> wrote:

Hi,

 

Are there any RFCs or other specifications available for collecting statistics for M3UA as well as for SCTP?

 

Any help welcome.

 

Lukas Alig

 


_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran




--
Regards,

Ronald Nsubuga,
skype: nsptash

"I don't speak for anybody but myself - that's enough trouble"

_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
Permalink | Reply | 0 comments |
headers
Hecht Martin | 7 Oct 2008 16:53
Favicon

M2PA Send ACK Timer

I implemented M2PA about four years ago and at that time I used a timer for ack’ing a received user data message when no user data messages where pending transmission.  I used a 200ms timer and sent the empty user data message when the timer expired.

I am now updating the M2PA to the RFC level and would like to know if this timer is no longer used.

Thanks,

Martin


Martin Hecht
Engineering

Signaling Core Group
Comverse
Office: +856 608-2712
martin.hecht <at> comverse.com
www.comverse.com

_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
Permalink | Reply | 1 comment |
headers
Brian F. G. Bidulock | 7 Oct 2008 18:25
Favicon

Re: M2PA Send ACK Timer

Hecht,

No, I don't believe that a timer is necessary.  What I do is
when there is a received MSU to acknowledge, I check if there
are MSUs queued for transmission in the TB and the L2 state
machine is sending MSUs, and the RTB is not full, in which case
I defer sending a separate ack to piggyback on the outgoing MSU.

There was even some discussion a while ago that indicated that
delaying acks harmfully interacts with the T7 timer and the L2
state machine.  This was captured in the RFC in section 4.2.1:

   When there is a message to acknowledge, M2PA MUST acknowledge the
   message with the next User Data message sent.  If there is no User
   Data message available to be sent when there is a message to
   acknowledge, M2PA SHOULD generate and send a User Data message with
   no data payload, without delay.  ...

--brian

Hecht Martin wrote:                           (Tue, 07 Oct 2008 10:53:29)
> 
>    I implemented M2PA about four years ago and at that time I used a
>    timer for ack'ing a received user data message when no user data
>    messages where pending transmission.  I used a 200ms timer and sent
>    the empty user data message when the timer expired.
> 
>    I am now updating the M2PA to the RFC level and would like to know if
>    this timer is no longer used.
> 
>    Thanks,
> 
>    Martin
> 
>    Martin Hecht
>    Engineering
> 
>    Signaling Core Group
>    Comverse
>    Office: +856 608-2712
>    [1]martin.hecht <at> comverse.com
>    [2]www.comverse.com
> 
> References
> 
>    1. mailto:martin.hecht <at> comverse.com
>    2. http://www.comverse.com/

> _______________________________________________
> Sigtran mailing list
> Sigtran <at> ietf.org
> https://www.ietf.org/mailman/listinfo/sigtran

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/
Permalink | Reply | 0 comments |
headers
Ben Davis | 9 Oct 2008 10:12
Picon

(no subject)

Hi experts,

Did IETF specified any adaptation of Q.752 to Sigtran ?

Ben

PS: "ITU-T Q752 = Monitoring and measurements for Signalling System No. 7 networks"
_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
Permalink | Reply | 4 comments |
headers
Ronald Nsubuga | 9 Oct 2008 12:34
Favicon

Re: (no subject)

Hello Ben,

On Thu, Oct 9, 2008 at 11:12 AM, Ben Davis <bendavissigtran <at> gmail.com> wrote:
Hi experts,

Did IETF specified any adaptation of Q.752 to Sigtran ?


There no clear pointers indications IETF adapting it BUT it's been implemented OR included by the respective vendors I think basing on the ITU standard.


--
Regards,

Ronald Nsubuga,
skype: nsptash

"I don't speak for anybody but myself - that's enough trouble"
_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
Permalink | Reply | 0 comments |
headers
Valerie Gastaud | 13 Oct 2008 16:30
Favicon

Routing Context clarification

Hello,
 
I'd like to get the advice from the list on the following question:
 
I believe it's very clear from the RFC 4666 that when multiple Routing Keys are used across a common association, the Routing Context MUST be sent to identify the traffic flow, assisting in the internal distribution of Data messages. This implies that the routing context must be sent in the ASPAC message and in the subsequent DATA messages for this RK. 
 
However in the case where there is only one Routing Key used across an association, it is specified that the routing context is optional and can be negotiated between the AS and SG (sent in the ASPAC message).
What is not clearly specified then is if the routing context MUST be sent in the DATA message as soon as it has been sent in the ASPAC message or if the routing context can be sent in the ASPAC message and not in the DATA messages.
 
What is the your advice on this point?
 
Valerie
 
_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
Permalink | Reply | 4 comments |

Gmane