Re: Sigtran extension for network management and association changeover.

Dear Brian,
Thanks for the discussion, comments inline.

Regards
Xiangsong

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


> Xiangsong,
> 
> No, that is not right.  You are coming at this rather late in
> the game.  M2PA first attempted to use SCTP's transport layer
> ack in its functionality but it became impossible.

I don't think so, it seems the M2PA is reusing the functionality
of MTP2, just using BSN to acknowledge the peer's FSN.

> Modifications to SCTP were not seen to be appropriate when an
> application level ack would suffice.  Not even all SIGTRAN
> layers require this capability, and modifications to SCTP would
> force the capability on all applications.

They are for different purpose (vs application level ack) and 
compatible, association changeover is harmless to any application.

> 
> I quite frankly agree with the consensus that was taken by tsvwg
> in these M2PA discussions and am resistant to a draft that would
> go against that consensus now.

I'm very interseted in the *consensus*, will find out the discussion 
and read it.

> 
> The corid draft does not require any changes to protocol
> elements.  See the section entitled "Interworking".  The
> approaches used in this section do no require any changes to the
> protocol or even for the peer to support the procedures.  This

I guess you are refering to section 4.3 Interworking Procedures,
but not section 5.6 Interworking. Section 4.3 says
 "Because the CORID procedures provided here rely upon close
  synchronization of Correlation Number between SPP, if one of the SPP
  does not support these CORID procedures, neither SPP is able to take
  advantage of the full benefits of the procedures."
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?

> approach (similar to the time-controlled changeover and
> changeback procedures of SS7) is used by a number of commercial
> implementations of M3UA.  Standardization has not been necessary
> because the procedures are local, only rely on existing protocol
> elements and procedures, do not rely on implementation of the
> procedures at the peer, are largely implementation related, and
> are performance based implementation options.

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?

> 
> I resubmitted the corid and about 8 or so other extension drafts
> for 5 to 7 years while the working group was active and none
> were taken up as WG items.  For example:
> 
> http://tools.ietf.org/html/draft-bidulock-sigtran-aspcong-01
> http://tools.ietf.org/html/draft-bidulock-sigtran-aspext-05
> http://tools.ietf.org/html/draft-bidulock-sigtran-corid-05
> http://tools.ietf.org/html/draft-bidulock-sigtran-isua-04
> http://tools.ietf.org/html/draft-bidulock-sigtran-loadgrp-05
> http://tools.ietf.org/html/draft-bidulock-sigtran-loadsel-05
> http://tools.ietf.org/html/draft-bidulock-sigtran-m2pa-test-08
> http://tools.ietf.org/html/draft-bidulock-sigtran-m2ua-ss7test-03
> http://tools.ietf.org/html/draft-bidulock-sigtran-regext-04
> http://tools.ietf.org/html/draft-bidulock-sigtran-tua-05
> 

Thanks a lot for the contribution, I will read them carefully.

> The necessary (but not all) protocol elements for corid-05 and
> regext-04 made their way into the UAs.  loadgrp-05 and
> loadsel-05 are not supported in any way, leaving SLS as the only
> rational basis for loadsharing.  The connection id components of
> regext-04 are not supportted, making connection-oriented SCCP in
> SUA useless.
> 
> After 8 years of banging my head on that, I think it unlikely
> that there will be a rally around these concepts now that the WG
> is shut down.  There is no charter, and these types of drafts do
> not seem sufficient to create one.  For example, far more
> important items (the lack of an M3UA MIB, and MIBs for any other
> SIGTRAN UAs) cannot keep open or resurrect the WG.  You can
> likely get more traction in forums that use SIGTRAN such as
> ITU-T and 3GPP.
> 
> My advise (whether you want it or not) is to find procedures
> such as those in the corid Interworking section that fits your
> implementation.  Do not use any proprietary protocol elements.
> Do not require any optional procedure of the peer.  Corid shows
> that it is possible (if not preferred) in the Interworking
> section.  If the corid procedures seem too complex for you, make
> your implementation simpler.  If after that you want to share
> all your work with the IETF, put forth a draft that describes
> your implementation as an INFORMATIONAL RFC.

Thank you very much for your comments and advise!

> 
> I won't even consider reviewing a draft that attempts to provide
> protocol elements or requires changes in procedures at the peer,
> either at SCTP or UA levels; because my first criticism will be
> that it requires protocol elements and requires changes in
> procedures at the peer: neither of which are possible nor
> necessary at this point.

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.
Thanks again,
Xiangsong

> 
> --brian
> 
> 
> Xiangsong Cui wrote:                      (Fri, 05 Mar 2010 10:44:50)
>> Dear Brian,
>> 
>> I have read the corid draft and have some thought.
>> 
>> >http://tools.ietf.org/html/draft-bidulock-sigtran-corid-05 provides
>> >several mechanisms that are completely local and accomplish this
>> >without protocol changes: neither in SCTP nor the UA.  UAs, such as
>> >M3UA, provide CorrelationId/Ack, BEAT/Ack, and ASPTM on data streams
>> >that already accommodate these procedures.
>> >
>> >--brian
>> 
>> In my understanding, the corid draft and my association-changeover draft 
>> are for
>> the same goal, the main difference is corid draft works in UA (or SPP) 
>> layer while my association-changeover draft focuses on SCTP layer.
>> 
>> The detailed differences include:
>> 1, Corid draft modifies UA protocols (section 3 Protocol Elements), such as 
>>    M2UA, M3UA, SUA, ISUA.....
>>    Association-changeover draft only changes SCTP protocol.
>> 2, Corid draft brings many transport functionalities into UA layer, such as 
>> corid (section 4.1.2.1), flow id (section 4.1.2.2), tagging (section 
>>    4.1.3) and buffering
>>    (section 4.1.4). These features bring complex and repeated job into UA 
>>    layer and would make UA hard to work.
>>    Association-changeover draft incorporates SS7 changeover functionality 
>>    in Sigtran,
>>    the peers exchange sequence information, and the sender resends the 
>>    unacknowledged messages.
>> 3, Determining which messages have already been acknowledged?
>>    Corid draft accomplishes it in UA layer (<5>  IMPLEMENTATION NOTE of 
>>    corid draft), it is out of the scope of corid draft but that is really 
>>    difficult.
>>    Association-changeover draft accomplishes it in SCTP layer by TSN, it is 
>>    very easy.
>> 4. Corid draft requires all traffic packets to include id information 
>> (section 4.1.3), which would waste bandwidth of the network.
>>    Association-changeover draft takes normal traffic transport procedure.
>> 5. Corid resends all undetermined messages (including the acknowledged 
>> messages) to the peer, and the messages are determined by the peer node.
>>    Association-changeover resends only the unacknowledged messages to the 
>>    peer.
>> 
>> Are those right?
>> 
>> Thanks and regards
>> Xiangsong
> 
> -- 
> Brian F. G. Bidulock
> [email protected]
> http://www.openss7.org/