Subject: RE: [Sigtran] M2PA MSU_ACK frequency issue (fwd)

From: "Nitin Vairagare" <[email-masked]>
Date: Tue, 30 Sep 2003 11:59:27 -0500

Tolga,

Different stream queues are only at receiving end. 
Receiver side of SCTP has queue for each incoming stream.
If all the SSN are received for that particular stream 
without gaps then the messages are delivered to the user
immediately.

In some implementations that I have seen, transmitting side of
the SCTP assoc has single outgoing queue. It might be different 
in other implementation.

But we could take advantage of multiple SCTP streams and 
avoid blocking of MSU ACKs (which in turn builds large buffer queues)
with problems like head of the line blocking. 

Regards,
Nitin

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]] 
Sent: Tuesday, September 30, 2003 10:47 AM
To: [email-masked]
Subject: RE: [Sigtran] M2PA MSU_ACK frequency issue (fwd)

Brian,

After thinking a bit more, two questions below....

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
Of
> Tolga Asveren
> Sent: Tuesday, September 30, 2003 10:36 AM
> To: [email-masked]
> Subject: RE: [Sigtran] M2PA MSU_ACK frequency issue (fwd)
>
>
> Brian,
>
> [..snip..]
> > stream 1.  Consider the following:
> >
> >                _______
> >                 | | | |
> >                 | | | |
> >         ------->| | | |------------------------>
> >                 | | | |
> >                _|_|_|_|
> >                                         _______
> >                                        | | | |
> >                                        | | | |
> >         <------------------------------| | | |<---
> >                                        | | | |
> >                                        |_|_|_|_
> >
> > Both peers have 1 second of DATA messages backed up in queue to be
> > transported
> > by SCTP.  When one peer receives a message, it responds immediately.
> > However,
> > because the DATA-ACK goes in stream 1, it will have to wait 1
> > seconds to be
> > delivered to the peer.  The messages received are already 1
> second old, so
> > the
> > DATA-ACK will arrive at the peer 2 seconds after the message
> was sent.  If
> > T7
> > is 1.2 seconds, this link wll fail due to excessive delay of
> > acknowledgement,
> > causing changeover and increased loss of data in ther SS7 network.
If
> > acknowledgements are sent on stream 0, a different queue
> applies and SCTP
[TOLGA]Are we sure for the different transport queues per stream?
> > can
> > deliver DATA-ACKs ahead of the data.  Also the expediting nature
> > for stream
> > 0
> > of some SCTP implementations could be utilized.  In that case the
[TOLGA]What do you mean exactly with  "expediting nature of stream 0"?
Different transport queues for different streams (the above case) or
something different?

_______________________________________________
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: "Tolga Asveren" <[email-masked]>
Date: Tue, 30 Sep 2003 13:10:28 -0400

Nitin,

> From: Nitin Vairagare [mailto:[email-masked]]
> Sent: Tuesday, September 30, 2003 12:59 PM
> To: Tolga Asveren; [email-masked]
[TOLGA] That was my point, to have per stream tranmission queue or not is
implemenattion dependent. Even for receive side, I would think an
implementation with a single queue -or better said which does not allow ULP
to do a receive request on a specific stream- is compliant with RFC2960.
> with problems like head of the line blocking.
[TOLGA]How can you be sure that stream0 performs better than stream1? It
might be the case that you have HOL on stream0 ans not on stream1. ACKing
with unordered delivery seems more promising to me.