Re: Sigtran extension for network management and association changeover.

Dear Brian,

Please see in line.

Thanks, Xiangsong

----- Original Message ----- 
From: "Brian F. G. Bidulock" <[email protected]>
To: "Xiangsong Cui" <[email protected]>
Cc: <[email protected]>
Sent: Friday, March 05, 2010 4:54 PM
Subject: Re: [Sigtran] Sigtran extension for network management and association changeover.


> Xiangsong,
> 
> Please see comments below:
> 
> Xiangsong Cui wrote:                      (Fri, 05 Mar 2010 14:57:56)
>> 
>> I don't think so, it seems the M2PA is reusing the functionality
>> of MTP2, just using BSN to acknowledge the peer's FSN.
> 
> Check M2PA before draft 4.

I will check that, but I don't understand its relation with our dicussion,
in you previous mail, " M2PA first attempted to use SCTP's transport
layer ack in its functionality but it became impossible."
How does the impossibility impact association changeover?

> 
>> 
>> They are for different purpose (vs application level ack) and 
>> compatible, association changeover is harmless to any application.
> 
> Additional complexity and performance impact is not harmless.

Firstly, the changeover does happen in very special situation, maybe 
less than 0.01% probability, even there is some impact, it is very little.
Comparing with corid approach (each message tagging and buffering, 
etc.),  is it a heavy load?
Secondly, exchanging a chunk pair and updating the buffer queue with
the selceted acknowledged information, will those bring burden to SCTP?
these are basic operations in SCTP.
I think this is much less the quasi-transport function in SPP layer.

> 
>> In fact, if the peer doesn't support CORID, the only benefit relies on
>> the buffer of local SPP. However, most UA SPPs don't provide buffering
>> function, so what can these UA SPPs get in this situation?
> 
> Standards compliant UAs must buffer to support AS-PENDING state.

We are talking changeover, which does only happen in initiating-active state.
I don't think it is appropriate to expand the AS-pending operations 
(e.g. buffer) to active state.

> 
>> 
>> I can't agree changeover is a local feature. If you only want 
>> time-controlled changeover, you may use SCTP Receive Unsent 
>> Message primitive defined in RFC4960, ignoring the sent but not 
>> acknowledged messages, why buffer the unsent messages in UA 
>> layer?
> 
> No you cannot because you risk message duplication which is 3
> orders of magnitude worse than message loss for SS7.

I don't understand your comment here, if you retrieve unsent messages
and resend them, how does the peer get duplicated message?

> 
>> 
>> 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.

Regards, Xiangsong

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