RE: M2PA retrasmission buffer

Dario,

The reason for M2PA retransmission buffers is to support MTP3
changeover/changeback procedures. M2PA did not have buffers till
draft-04 (or something around this number). Then buffers have been
introduced.

I agree that this creates some double standard:
a) For M3UA, we assume that SCTP multihoming will provide network/NIF
redundancy
b) For M2PA, we assume even if the M2PA link (or better said the
corresponding SCTP association) has failed, the remote host still could
be there and reachable (otherwise what is the point of
changeover/changeback).

I am in the camp which says M3UA does it right. SCTP multihoming +
proper IP network engineering is the way to address this issue. If you
loose your SCTP association to a remote host, this means it is down
(within a reasonable probabilistic range of course). There are others
which think different. And we argue about this regularly (I would say it
is usually every 3 months or so :-) )

The nice (or funny, depending on how you evaluate it :-) )thing about
the M3UA and M2PA standards is that they do opposite things. This
provides flexibility (or confusion) when people want to pick the
protocol to use.

    Thanks,
    Tolga
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email protected]]
> Sent: Wednesday, April 18, 2007 1:17 PM
> To: Dario
> Cc: [email protected]
> Subject: Re: [Sigtran] M2PA retrasmission buffer
> 
> Dario,
> 
> Dario wrote:
> (Tue, 17 Apr 2007 23:43:43)
> >
> > Hi Brian,
> > so it means that both SCTP and M2PA should buffer sent but not
> acknowledged
> > messages?
> 
> M2PA buffers messagse sent and even acknowledged by the peer SCTP, but
not
> yet
> acknowledged by the peer M2PA.
> 
> > On the other hand, Data Retrieval and Retransmission is not
supported in
> > M3UA.
> 
> Well, really it is.  See draft-bidulock-sigtran-corid-05.txt for an
> example of
> how to use existing mechanisms to effect the same procedures as
> changeover,
> changeback and forced and controlled rerouting.
> 
> --brian
> 
> --
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
> 
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran