RE: [SUA] yes, more on ASP Congestion
"Tolga Asveren" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Jeff, -----Original Message----- From: [email protected] [mailto:[email protected]]On Behalf Of Craig, Jeffrey Sent: Friday, October 14, 2005 2:07 PM To: [email protected] Subject: [Sigtran] [SUA] yes, more on ASP Congestion Hello All, I've been following the very very long thread regarding SUA ASP congestion. In general I agree with Brian Bidulock: leave the ASP->SG SCON alone, and instead create a new draft to address the general issue of user part congestion and the UA protocols. I'm having a hard time understanding why the following solutions don't work: * congested ASP stops receiving on association [TOLGA]This is pretty much the current model, relying on SCTP congestion mechanism, is not satisfactory for the reasons already mentioned for certain configurations/cases. * congested ASP issues ASP-INACTIVE upon detecting inbound congestion [TOLGA]If one wants to aggregate congestion status on SG, IMHO it could be useful to distinguish between INACTIVE and CONGESTED regarding ASP state in the context of an AS, otherwise SG can never declare SPMC as congested. Furthermore, if congestion state from ASP to SG is used for message distribution purposes on SG, there again is a difference between a congested -together with the degree of congestion- and inactive ASP. * congested ASP issues ASP-DOWN upon detecting inbound congestion [TOLGA]I think this is similar to ASP-INACTIVE. * use MTP3 and M2PA instead [TOLGA] I think the choice of protocol is outside of the scope of this discussion. It seems that there is a problem with existing SUA/M3UA regarding this issue and it is not because of an architectural decisions. If the request were something violating architectural principles of SUA/M3UA., I would have agreed with you. I'm having an especially hard time understanding how overloading the ASP->SG SCON will result in an interoperable solution. Regards, Jeff _______________________________________________ Sigtran mailing list [email protected] https://www1.ietf.org/mailman/listinfo/sigtran