Subject: RE: [Sigtran] SUA v14 doubt in SCON

From: [email-masked]
Date: Thu, 12 Sep 2002 07:22:15 +0300

Hi Tolga,

> >      Can they Inform each other about the local IP congestion to
> > other side ?
> [TOLGA] What do you mean exactly by "local IP congestion"? 
> Congestion of
> association on the local SCTP? If so, I don't think it is necessary to
> report this to the peer with SCON.

The intention is not to use SCON for IP layer congestion - it is not clear
that all SCTP implementations would report congestion information up
to SUA.

John
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: [email-masked]
Date: Fri, 13 Sep 2002 09:06:10 +0300

Hi Tolga,

> [TOLGA] I don't know, whether IPSP model of SUA will be similar to what we
> currently have in M3UA (based on M3UA-IG) or not. Assuming that it will be,
> AS will define the traffic at both ends in IPSP case. In such a case there
> won't be a need for AffectedPC in SCON for IPSP communication, RC will be
> enough.

Agreed.

John

---

From: [email-masked]
Date: Sat, 14 Sep 2002 12:14:28 +0530

Hi Brian, Tolga,

As per SUA v14, SCON message can be used between IPSPs and existing SCON message
allows the same to be used by implementation in case of point code based routing
keys are being used, but syntax of SCON message does not permit this message to
be used when IP address based routing keys are being used.
I could not understand how SCON in IPSP scenario is applicable if point code
based routing keys are used and is not applicable when IP address based routing
keys are being used ? Are  you suggesting that SUA specs should be updated to
say that SCON can not be used in case of IPSPs ?

About usage of ECN, My understanding of ECN is that, routes encountering
congestion set the ECN bit in IP header and SCTP implementation receiving such a
IP packet sends back ECNE chunk to the peer end. Are you suggesting that SCTP
implementation after detecting local congestion can/should send ECNE chunk to
peer end ?  Can you also please share what other IETF mechanisms you are
referring to ?

Best Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 09/13/2002 09:40:11 PM

Please respond to [email-masked]

To:   Yogesh Gahlaut/HSS@HSS
cc:   [email-masked], [email-masked], [email-masked] (bcc:
      Sandeep Mahajan/HSS)

Subject:  Re: [Sigtran] SUA v14 doubt in SCON

Yogesh,

SCON is used to indicate SS7 network congestion only.  It is not useful
in the IPSP case.  In the IPSP case, IETF mechanisms are more applicable:
such as ECN.

--brian

[email-masked] wrote:
(Fri, 13 Sep 2002 14:33:17)
>
>
>
> Hi John and Tolga,
>
>   I also agree with this ...
>  But in SUA draft 14, SCON has  affected point code as a mandatory parameter
and
> RC as optional parameter.
>
>  So what could be solution to this probelm ?
> Can we have an invalid value for the affected point code which can be ignored
at
> the peer side ?
> or some other solution ?
>
> Comment on this.
>
> Regards
> Yogesh
>
>
>
>
>
> [email-masked] on 09/13/2002 12:36:10 PM
>
> To:   [email-masked], [email-masked]
> cc:    (bcc: Yogesh Gahlaut/HSS)
>
> Subject:  RE: [Sigtran] SUA v14 doubt in SCON
>
>
>
>
> Hi Tolga,
>

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/