Subject: RE: [Tsvwg] Re: M2PA: User Level Acknowledgements

From: [email-masked]
Date: Tue, 6 Nov 2001 12:57:52 +0200

Hi all!

> Tom,
> 
> I think that TSV has fairly addressed this issue and has
> indicated that GAP ACKs with no gap is illegal, that
> a_rwnd = 0 cannot be permitted to stop data flow (zero

	Brian, as far as I know, this is not the final conclusion regarding
the a_rwnd... If you set it to 0, and you don't acknowledge any new DATA
chunk received, this will stop data flow, as the sender will be spending his
time just retransmitting a single not acknowledged TSN every RTO until the
receiver decides whether it continues accepting new data opening the a_rwnd,
or it tears down the association...

	You might not be reading some other people's mails... or you might
not want to understand them... :-0. You are right that the sentence in
section 6.2 of RFC 2960 should be changed, and that's what you were asking
for (actually, I'm not that sure what you are asking for), but it seems that
as soon as your wish was fulfilled you just don't want it anymore...

	If I'm right (not sure), both the gap ack *or* the a_rwnd change is
enough for that problem you have... Thanks to your comments I think we have
been able to solve the problem (tell us if not)... but I'm not sure you
really want to solve any problem... :-0

	BR Iván Arias Rodríguez

> window probes), that artificially dropping a_rwnd is not
> advisable, and that if ULP wants to withhold acks it needs
> its own acks to withhold.
> 
> The situation with SCTP-level acks means also that neither
> TSN nor Stream Sequence Number can be used by M2PA as BSNT
> for changeover.
> 
> Please place sequence numbers and acks in the M2PA protocol:
> I will prospose text if you would like.  This has the side-
> benefit that multiple logical SS7 links can be placed each
> in a separate stream in a single M2PA association and take
> full advantage of SCTP's HOL blocking avoidance for improved
> MTP performance under noise and delay.
> 
> Comments?
> 
> --brian
> 
> 
> Brian F. G. Bidulock wrote:               (Wed, 25 Jul 2001 06:33:34)
> > Tom,
> > 
> > I still see that you don't understand that M2PA needs
> > user level acknowledgements which SCTP does not provide.
> > The draft as it stands cannot handle Receive Congestion
> > or Remote Processor Outage conditions correctly.
> > 
> > It will be necessary to put a sequence number on M2PA
> > data messages and pass back an ACK at the M2PA level
> > to fix this.  SCTP will not help.
> > 
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/tsvwg
> 

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 05:15:14 -0600

Ivan.Arias-Rodriguez,

[email-masked] wrote:        (Tue, 06 Nov 2001 12:57:52)
> or it tears down the association...

The receiver is allowed to acknolwedge.  This would break MTP conformance.
It is pretty clear from the discussion that SCTP cannot require the
receiver to not acknowledge probes even though it continues to advertize
a_rwnd = 0.  This is not sufficient for M2PA's needs.  The conclusion
appears quite final to me.  The transmitter is permitted to send new
data with a_rwnd = 0 and the receive is permitted to acknowledge it with
a_rwnd = 0.  This will not change.

> as soon as your wish was fulfilled you just don't want it anymore...

What we were looking for a statement which say that the receive MUST NOT
acknowledge new data while advertising a_rwnd = 0.  What has been achieved
is only that the receiver MAY NOT acknowledge new data while advertising
a_rwnd = 0.  No, M2PA did not get what it needed here or with GAP ACK.

> enough for that problem you have...

The a_rwnd change has not come about.  It would take a guarantee to the
ULP that data will not flow while artificially adversiting a_rwnd = 0.
There are no such guarantees in the works.

> Thanks to your comments I think we have been able to solve the problem (tell
> us if not)...

We have solved a problem (oversight in RFC pertaining to zero window
probes) but have provided no solution to M2PA.

> but I'm not sure you really want to solve any problem... :-0

M2PA can solve the problem with sequence numbers and acks.  At least it
doesn't have to work about reordering.  It is just that there are many
that are lithe to include it in M2PA.

--brian

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

---

From: Randall Stewart <[email-masked]>
Date: Tue, 06 Nov 2001 06:23:16 -0600

Ivan:

  comments below...

> really want to solve any problem... :-0

The base problem I think that Brian has is he cant DEPEND on the
new probes being dropped. A implementation MAY still accept the
data when the rwnd=0. What he wants to do is instead
send the data to a seperate association. Now what I don't
understand in this is that eventually the rwnd will get
set back to postive and all that data that was inqueue
at the sender will come forward. It has to be dealt
with. Either that or you must abort the association.
Which in that case why not abort() the association
instead of doing rwnd=0..

Very strange.

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 6 Nov 2001 06:35:13 -0600

Randall,

Randall Stewart wrote:                                    (Tue, 06 Nov 2001 06:23:16)
> The base problem I think that Brian has is he cant DEPEND on
> the new probes being dropped. A implementation MAY still
> accept the data when the rwnd=0.  What he wants to do is
> instead send the data to a seperate association.

Bingo!

> Now what I don't understand in this is that eventually the
> rwnd will get set back to postive and all that data that was
> inqueue at the sender will come forward.

Treatment of inqueue data is completely under the control
of the implementation and already adressed by MTP3 procedures.
If the failover occurs, this data is flushed (by the
application) on recovery.

> It has to be dealt with.

It is dealt with and the application is free to do with it as
it chooses.

> Either that or you must abort the association.  Which in that
> case why not abort() the association instead of doing rwnd=0..

The reason for not aborting the association is because the
thing which cause the a_rwnd = 0 may clear in the next 2 ms.
The cost of aborting the association for transient events
is too great.  It is not until the condition persists that
it is treated as a failure, but data must be held at the
transmitter in the mean time.

> Very strange.

It's just how SS7 works.

--brian

> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

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