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

From: "Nitin Vairagare" <[email-masked]>
Date: Tue, 30 Sep 2003 12:28:06 -0500

No, I am not promising that sending it on different stream
will solve the issue. 

As Jeff said... 

There will be an issue of out of order Acks delivered to M2PA
in both cases unordered or different stream.

If there is HOL on stream 1, SCTP will deliver unordered ACK 
ahead of data traffic.  

I think we need to find out a better way so that we will not
have 1000s of MSU buffered in M2PA in absence of data traffic
from receiver side.

Regards,
Nitin

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

Nitin,

> -----Original Message-----
> From: Nitin Vairagare [mailto:[email-masked]]
> Sent: Tuesday, September 30, 2003 12:59 PM
> To: Tolga Asveren; [email-masked]
> Subject: RE: [Sigtran] M2PA MSU_ACK frequency issue (fwd)
>
>
> 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.
[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.
>
> 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.
[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.
>
> 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

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

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 30 Sep 2003 10:47:04 -0700 (PDT)

Nitin,
> Sent: Tuesday, September 30, 2003 1:28 PM
[TOLGA]I would think, ignoring  late arriving ACKs on
receiving M2PA should work(maybe just a problem if one
unlucky ACK keeps retransmitting for long time and
arrives to M2PA after that M2PA sent 2^32 more
messages, which might cause a false acknowledgement) .
> have 1000s of MSU buffered in M2PA in absence of
data traffic
[TOLGA]I think the way in the current draft -ACKing
with empy DATA- is fine, and as far as I can see,
nothing else can be done. But IMO whether ACKs can be
expedited should be thought of.
_______
|_|_|_|_
> > Different transport queues for different streams
(the above case) or

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 30 Sep 2003 12:37:24 -0600

Tolga,

Actually, I was thinking more of ripping the BSN off
of the DATA message and placing it in a separate ACK
message on stream "0", yes, perhaps even unordered.
The Abnormal BSN procedures could be used to handle
the odd misordered ACK.

Whether stream "0" expedites is depdendent on how SCTP
chooses new DATA chunks from multiple streams when
bundling a packet.  If it always starts with stream
"0", stream "0" will be expedited ahead of other
streams.  If it performs a more (or less)
sophisticated balancing algorithm, stream "0" might
not have any expediting nature.

If your SCTP uses a single queue for ordered messages
on the transmit side, then it is reintroducing HOL
blocking at the transmit queue.  That would be rather
foolish and will perform poorly (under congestion)
compared to a implementation that treats individual
streams indepdendently.

The per-stream flow control draft has fallen by the
wayside, but we pretty much agreed that transmit
selection was completely the decision of the
transmitter and did not require any additional
protocol elements for interoperability.

--brian

Tolga Asveren wrote:                                                                 (Tue, 30 Sep 2003 10:47:04)

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