Subject: RE: [Sigtran] M2PA v6: Two Out of Three Valid BSN

From: "May, Howard" <[email-masked]>
Date: Mon, 7 Oct 2002 09:57:15 +0100

Anshoo,

Brian has suggested a requirement that would be a reason for preserving the 2/3 procedure.  My understanding is M2PA may be used not to offer MTP2 services directly to an MTP2 User but rather convert existing MTP2 messages into M2PA messages.  Preserving the  2/3 procedure supports transparent copying of the MTP2 SNs into M2PA SNs.

It is not clear to me at the moment whether this is an appropriate reason for deciding M2PA Procedures.  I am concerned that  we are introducing new requirements to M2PA that have not been considered during the rest of the design process.  Perhaps the  Authors could comment on this?

Howard

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 05 October 2002 23:00
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sigtran] M2PA v6: Two Out of Three Valid BSN
> 
> 
> Anshoo,
> 
> No.
> 
> --brian
> 
> [email-masked] wrote:                                  
>                    (Sat, 05 Oct 2002 16:26:28)
> > 
> > 
> > 
> > Hi,
> > 
> > Seems like there is an agreement on the list regarding this 
> issue now.
> > Can I safely presume that M2PA v7 would have the text for 
> sending the Link to
> > out of service whenever an out of sequence BSN is received?
> > 
> > Regards
> > Anshoo.
> > 
> > ----- Original Message -----
> > From: "Tolga Asveren" <[email-masked]>
> > To: <[email-masked]>
> > Sent: Friday, October 04, 2002 8:11 PM
> > Subject: RE: [Sigtran] M2PA v6: Two Out of Three Valid BSN
> > 
> > 
> > > Howard,
> > >
> > > > -----Original Message-----
> > > > From: May, Howard [mailto:[email-masked]]
> > > > Sent: Friday, October 04, 2002 10:13 AM
> > > > To: [email-masked]
> > > > Subject: RE: [Sigtran] M2PA v6: Two Out of Three Valid BSN
> > > >
> > > >
> > > > Tolga,
> > > >
> > > > I'm not quite sure I followed all your arguments but suspect
> > > > we might have some level of agreement.
> > > >
> > > > Would you at this stage support changing the procedure to
> > > > failing the link on the first occurrence of an invalid BSN?
> > > [TOLGA] What I explained till now is just a guess to 
> explain the reason
> > > behind that procedure in MTP2. If that is true, and if 32 
> bit checksum is
> > > good enough, I wouldn't feel uncomfortable with that change.
> > > >
> > > > Regards
> > > >
> > > > Howard
> > 
> > DISCLAIMER: This message is proprietary to Hughes Software Systems
> > Limited (HSS) and is intended solely for the use of the individual
> > to whom it is addressed. It may contain  privileged or confidential
> > information  and should not be circulated or used for any 
> purpose other
> > than for what it is intended. If you have received this 
> message in error,
> > please notify the originator immediately. If you are not 
> the intended
> > recipient, you are notified that you are strictly 
> prohibited from using,
> > copying, altering, or disclosing the contents of this 
> message. HSS accepts
> > no responsibility for loss or damage arising from the use 
> of the information
> > transmitted by this email including damage from virus.
> > 
> > 
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 7 Oct 2002 04:05:57 -0600

Howard,

Introducing negative acknowledgements as well would allow PR-SCTP to
be usable with M2PA.

--brian

May, Howard wrote:                                                                    (Mon, 07 Oct 2002 09:57:15)
> Anshoo,
> 
> Brian has suggested a requirement that would be a reason for preserving the
> 2/3 procedure.  My understanding is M2PA may be used not to offer MTP2
> services directly to an MTP2 User but rather convert existing MTP2 messages
> into M2PA messages.  Preserving the  2/3 procedure supports transparent
> copying of the MTP2 SNs into M2PA SNs.
> 
> It is not clear to me at the moment whether this is an appropriate reason
> for deciding M2PA Procedures.  I am concerned that  we are introducing new
> requirements to M2PA that have not been considered during the rest of the
> design process.  Perhaps the  Authors could comment on this?
> 
> Howard
> 
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 7 Oct 2002 06:39:48 -0600

Howard,

As you seem to have a problem with this, here is another reason
for 2 out of 3, (rather than the first BSN) and a general problem
regarding BSN treatment.  Consider the following:

An M2PA link aligns and goes into service.  Several data packets
get stuck in the network resulting in link failure (and LSOS is sent
and received successfully on stream 0).  The link realigns and goes
back into service (using stream 0).  The "stuck" packets from the
previous in-service are now delivered.

How is the receiver of the MSUs to tell the difference between MSUs
belonging the old in-service session and MSUs belonging to the new
in-service session?  By resetting the FSN/BSN when a link goes into
service?  Then the link will fail on the first abormal BSN unless
the 2 out of 3 is used.

As stuck packets are common in the network and SCTP will faithfully
deliver them late, this situation must be accomodated.

--brian

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 07 Oct 2002 07:33:57 -0700

When the M2PA link fails, close the SCTP association
and start a new association.

-- 
// Jakob Heitz. Tel:510-747-2917
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 7 Oct 2002 14:10:41 -0600

Jacob,

Jacob Heitz wrote:                                     (Mon, 07 Oct 2002 07:33:57)
> and start a new association.

Yes, we used to do that, but it is rather drastic for several reasons and
might not accomplish what is expected.

First off, if dropping the association and restarting it actually results
in a new association, the congestion window will have closed and the
association will be back in slow start.  A full alignment procedure intended
to take the association out of slow start will be required.

Secondly, as the link may have failed due to lost packets, it is reasonable
to assume that the ABORT from the aborting side may be lost and the new
INIT will result in tie-tags and no new association will be formed.  In this
case the SCTP receiver has the option of keeping data from the old
association and the problem still persists.

--brian

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 07 Oct 2002 13:25:40 -0700

> to take the association out of slow start will be required.

An M2PA link failure is equally drastic. It should
never happen in a network that is properly engineered
to carry an M2PA link.

No.

A new SCTP association will be formed, regardless if
the old one is still there. Then a new M2PA link will
be formed. It will come up with the same interface
ID as the old one and look like a duplicate link.
Your implementation must handle the duplicate link
case anyway (presumably, kill the old one, or kill
both of them and start afresh).

Given that M2PA link failure is an extraordinary
event, this reaction not too drastic.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 7 Oct 2002 15:37:09 -0600

Jacob,

Jacob Heitz wrote:                    (Mon, 07 Oct 2002 13:25:40)
> both of them and start afresh).

Not true.  M2PA does not have an interface id.  You have two
choices: orderly shutdown (which could pospone indefinitely
and still deliver late packets), or abort.  If the sender
aborts and the ABORT is lost, the receiver might not know that
the sender has aborted the association and interpret the next
INIT as a restart scenario under RFC 2960 5.2.4 A):

  "Any SCTP DATA Chunks MAY be retained (this is an implementation
   specific option)."

--brian

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 07 Oct 2002 14:42:34 -0700

"Brian F. G. Bidulock" wrote:
> Not true.  M2PA does not have an interface id.

Then how is an M2PA link identified ?

> You have two

even if the VT is different ?

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 7 Oct 2002 16:24:08 -0600

Jacob,

Jacob Heitz wrote:                        (Mon, 07 Oct 2002 14:42:34)
> Then how is an M2PA link identified ?

Where in the M2PA draft is an interface id mentioned?

It is the identify of the incoming or outgoing SCTP association
which defines the link (IP address, port, etc.).

> even if the VT is different ?

Local and peer VT doesn't matter for case 5.2.4. A)
(See table on Page 63 RFC 2960).

--brian