RE: [SUA] yes, more on ASP Congestion

Jeff,
 
See my comments below.
 
Thanks for your input.
 
Regards,
Lincoln

________________________________

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.

[lincoln]: This is a perfectly fine solution for me if the WG accepts
it.
 
I'm having a hard time understanding why the following solutions don't
work:
* congested ASP stops receiving on association

[lincoln]: We don't want to stop receiving all traffic.  Just data
traffic.  I'd still like to received management messages on my ASP
(e.g., NOTIFY).

* congested ASP issues ASP-INACTIVE upon detecting inbound congestion
* congested ASP issues ASP-DOWN upon detecting inbound congestion

[lincoln]: See previous comments.  Also, by not disabling the
association and receiving an explicit PEER notification, the SG can take
actions such as reducing traffic by stages.

* use MTP3 and M2PA instead

[lincoln]: Not sure what you are referring to here.  
 
I'm having an especially hard time understanding how overloading the
ASP->SG 
SCON will result in an interoperable solution. 

[lincoln]: I don't believe it would.  But again, I'm not tied to this
solution if others want something else.  Overloading the SCON is easier
to implement although I agree that it was not the original intent of
SCON.  That's why I initially questioned it's use to do ASP congestion.
And I felt that overloading SCON was easier to the WG to stomach than a
completely new message.  But again, as long as there is a single
accepted solution to the problems, it doesn't need to be mine.
 
Regards,
 
Jeff