Subject: RE: [Sigtran] SG-SG : starting traffic

From: "Bep Verberk" <[email-masked]>
Date: Thu, 30 May 2002 11:22:35 -0400

I also don't like to see TAL. I had a number of questions about
TAL in the draft such as.
-Need to mention the timeouts if TAL never received.
-Should just refer to the MTP Restart procedure in Q704.
-What about in an ANSI network where MTP Restart is different
and includes a TRW message ?

The reductionist in me says why implement "MTP Restart like" 
behavior at all in SG-SG. Simply either assume everything
is available and get updated with response mode DUNAs,
or assume everything is unavailable and send DAUDs.
I prefer the first (nobody needs to point out that this
will result in some traffic being sent that is discarded).

Bep 

> -----Original Message-----
> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Thursday, May 30, 2002 11:23 AM
> To: [email-masked]
> Subject: [Sigtran] SG-SG : starting traffic
> 
> 
> Brian,
> 
> >>I would rather get rid of TAL.  There is no reason why an 
> SG can't use
> >>ASPUP/DN, ASPAC/IA and DAUD for MTP3 restart in a similar fashion to
> >>M3UA.  The only minor difference is that MTP3 restart 
> should be handled
> >>by a peer-to-peer arrangement rather than a MTP3/MTP3-User 
> arrangement.
> [TOLGA] I also want to get rid of TAL. But why just SSNM is 
> not enough? If
> possible, I would like to use just SSNM for SG-SG 
> communication. My proposal
> is, after SCTP association is established:
> a) Either each SG announces available/restricted PC list to its peer
> b) or each SG asks with DAUD for the PCs it is interested in 
> to its peer
> 
> So again no TAL. The only reason, we have TAL is, because SGs were
> announcing unavailable/restricted PCs and everyhting else was 
> considered as
> available, so, we needed a message to mark end of this announcement.
> >>That is:
> >>
> >>	SG goes ASPUP.
> >>
> >>	SG does not require MTP3 restart if it has not isolated from
> >>	the SS7 or IP networks.
> >>
> >>	SG needs to assume that all destinations are available at the
> >>	beginning of the procedure (rather than unavailable as in the
> >>	backhaul case).
> >>
> >>	SG requests update of routes by issuing DAUD to peer.  Peer
> >>	responds with only unavailable (DUNA) destinations.  (Note
> >>	that routes cannot be congested when no traffic is flowing
> >>	to them).
> >>
> >>	After a time equivalent to T19, T20, T21, the SG starts traffic
> >>	with ASPAC.
> [TOLGA] Why do we need the timers and ASPAC?
> >>
> >>The difference here is that DAUD is issued before ASPAC (instead of
> >>after in the backhaul case), destinations are assumed available and
> >>uncongested (instead of unavailable as in the backhaul case).
> >>
> >>Voila.  No TAL.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
>

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 30 May 2002 11:40:47 -0400

RE: [Sigtran] SG-SG : starting trafficBep,
  -----Original Message-----
  From: Bep Verberk [mailto:[email-masked]]
  Sent: Thursday, May 30, 2002 11:23 AM
  To: 'Tolga Asveren'; [email-masked]
  Subject: RE: [Sigtran] SG-SG : starting traffic

  [TOLGA] No timeout is necessary in my opinion. Our assumption is SCTP is
reliable and no message will be lost. But one can still be picky and put a
timer.
  -Should just refer to the MTP Restart procedure in Q704.
  -What about in an ANSI network where MTP Restart is different
  and includes a TRW message ?

  [TOLGA] The reason not to have something corresponding to TRW is, because
we don't have timer for TAL, so no need to extend the timeout value. But we
will get rid of TAL, so there is no point to discuss those details.

  [TOLGA] But it will really result in some traffic to be discarded :-) I
agree to get rid of TAL. But in my opinion just SSNM should be enough.

  Bep

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 30 May 2002 10:46:25 -0500

Bep,

Bep Verberk wrote:                                            (Thu, 30 May 2002 11:22:35)
>    will result in some traffic being sent that is discarded).

Well, now that's the problem: traffic discard.  It is hard to meet
MTP3-User expectations while discarding traffic.  Also, do not
underestimate the amount of traffic that can be thrown at a restarting
node: particularly if the reason that it went down in the first place
was due to a mass calling event.

The MTP3 restart procedure was added to SS7 to correct instable restart
conditions, and to avoid message loss from experience in the field.
As the stimulus is the same for both SS7 or IP transport, it would be
foolish to assume that similar instabilities would not result if no
equivalent procedure was provided for.

--brian

>    > From: Tolga Asveren [[1]mailto:[email-masked]]
>    > [2]https://www1.ietf.org/mailman/listinfo/sigtran
>    >
> 
> References
> 
>    1. mailto:[email-masked]
>    2. https://www1.ietf.org/mailman/listinfo/sigtran

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