Re: Sigtran extension for network management and association changeover.
Xiangsong Cui <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Dear Brian, ----- 原邮件 ----- 发件人: "Brian F. G. Bidulock" <[email protected]> 日期: 星期五, 三月 5日, 2010 下午9:06 主题: Re: [Sigtran] Sigtran extension for network management and association changeover. 收件人: Xiangsong Cui <[email protected]> 抄送: [email protected] > Xiangsong, > > Diversion of traffic does not always occur as a result of > association failure. It can also result from: > > deactivation of an AS at an ASP (ASPIA, ASPDN) > deactivation of an AS at an SGP (unsolicited ASPIA Ack or ASPDN Ack) > activation of an AS at an ASP or SGP (ASPAC, ASPAC Ack) Deactivation is the courtyard of AS-pending buffer, changeover is unnecessary at this time. UA layer can deal with that. And, does activation need changeover? > > In these cases where the association has not failed, and because > retrieving unsent messages is only defined for SCTP after > association failure, these approaches will risk loss and > duplication. > > SCTP acknowledgements only acknowledge that the SCTP peer > received a portion of a message. They do not acknowledge that > the UA peer received the message at all. For example, the UA > peer could close a failed association, losing all messages in > the receive buffer. I agree this point, but this doesn't impact association changeover. Association failure may be terminal/endpoint error/failure or connection error/failure. If it is connection error, the ULP of course can restore the messages cached in the receive buffer queue (in the terminal) of the failure association, no message lossing. If it is the termainal/endpoint error, some messages would be lost. This situation is very similar to MTP2. If it is a link error, sequenced chaneover is OK, but if it is the MTP2 terminal error, MTP3 can not retrieve the sequence number, and only time-controlled changeover can be appllied. messages lossing can not be avoided. > > Withholding SCTP acknowledgement until the message is actually > read from the receive buffer by the ULP is not something that > tsvwg wanted to do. I agree this. Putting another layer of end-to-end > acknowledgement in SCTP to acknowledge on a per-stream basis is > not necessary for most other applications. Instead of > performing this layering, an application layer acknowledgement > from ULP-to-ULP is more appropriate. This is the concensus that > was reached. I am wonderring at this point. Do you mean user adaptation is unappropriate and we need peer-to-peer adaptation? If that is yes, I agree your corid draft is appropriate for that (note local implementation is almost helpless because of the huge TBP), while association changeoveris is only for user adaptation. > > When SCTP detects a restart condition, it is permitted by the > SCTP specification to discard all queued (send and receive) > messages. Once an SCTP restart has occurred, the SCTP can no > longer acknowledge messages from the previous association; > however, the UA can. Restart is another issue, not in the scope of association changeover. > > SCTP does not stop messages from being placed into the receive > buffer that cannot be acknowledged to the far end (e.g. because > the association has already failed). > > A UA level acknowlegement (Correlation Id/Ack) and flushing > (BEAT/ACK) handles all these cases, and in particular the ones > where the association has not failed. Yes, but maybe "A PA level" (peer-to-peer) is more exact. 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
c00111037.vcf
(text/x-vcard, 108 B)
begin:vcard n:Cui;Xiangsong fn:Xiangsong Cui version:2.1 email;internet:[email protected] end:vcard