Re: Sigtran extension for network management and association changeover.

Dear Brian,


----- 原邮件 -----
发件人: "Brian F. G. Bidulock" <[email protected]>
日期: 星期五, 三月 5日, 2010 下午9:26
主题: Re: [Sigtran] Sigtran extension for network management and association changeover.
收件人: Xiangsong Cui <[email protected]>
抄送: [email protected]

> Xiangsong,
> 
> Xiangsong Cui wrote:                      (Fri, 05 Mar 2010 17:41:20)
> > >>As you said in your draft, local implementation is not engough
> > >>for the expected benefit, and we do wish a feasible solution 
> for 
> > >>the high-performance Sigtran network.
> > >
> > >No, that's not what I said.  Local implementation is not enough
> > >for the _full_ benefit.  Nevertheless there is still _benefit_
> > >to be had by one or both ends performing the Interworking 
> Procedures.> 
> > *We* expect the higher benefit. Before the huge Time-Bandwidth 
> Product,> time-controlled changeover is near to non-changeover, 
> because there are
> > too much sent but unacknowledged messages, undetermined in the 
> floating way.
> 
> Then you do not want SS7 either.  International SS7 and many national
> variants (e.g. ETSI) permit an MTP implementation to _always_ use
> time-controlled changeover instead of sequenced changeover.  (This
> includes satellite links by the way.)  This is because there are
> cases where message missequencing can occur when changing over.  It
> was never the intention of SIGTRAN to improve upon SS7 in this way.
> If you try to use SIGTRAN in an environment where even traditional SS7
> will not work, it is likely to fail.

I can't agree this logic, we prefer sequenced changeover not means
we are against time-controlled changeover, we just expect better
result, on the basis of time-controlled changeover.

> 
> There are implementors in this WG that swear by the time-controlled
> method, and that is one of the reasons why the corid draft never
> moved forward.

I think it is because you are designing a peer-to-peer adaption, 
however, user adaption has been widely applied in the network,
and it is very difficult to update the complex implementation.
There is not any relation to time-controlled changeover.

> 
> An example where sequenced changeover will not work is where the 
> failedassociation has a long delay and the alternate association 
> has a short
> delay.  See other examples in section 1.4.5 in the corid draft.
> 
> Because SCTP does not know anything about the traffic flows 
> driving its
> streams, messages received last on the failed or deactivated 
> associationmight be processed after the first messages received on 
> the new association, 
> resulting in significant message mis-sequencing.  Again, message 
> discardor message delay is better than mis-sequencing for SS7, so 
> time-controlled
> or flushing (BEAT/ACK) approaches are better in this regard.
> 
> I don't think that you have thought this out.

It is not as you thought, if you read the draft you would find that
sequence delivery has been considerred in the draft.

Regards, Xiangsong

> 
> --brian
> 
> -- 
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/
>

_______________________________________________
Sigtran mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sigtran

begin:vcard
n:Cui;Xiangsong
fn:Xiangsong Cui
version:2.1
email;internet:[email protected]
end:vcard