Subject: [Tsvwg] Re: [Sigtran] SCTP: What about the status of flow control in units of messages per-association ?

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 31 Jan 2002 12:59:56 -0600

Bernward,

I believe TSVWG is responsible for these drafts.  Your
questions will probably get better answers there.  I have
forwarded this reply to [email-masked].

--brian

Meyknecht Bernward wrote:                               (Thu, 31 Jan 2002 19:03:35)
> 
> Dear all,
> 
> I'm wondering what's the status of the proposed Message Based Flow Control on 
> per-association basis for SCTP (setting flow limits in units of bytes or 
> also in units of messages). Cannot find it in the actual drafts.
> 
> I know the stream related flow control has been discussed and may now be out 
> of discussion, but I think the message based flow control on per-association base 
> still makes sense for our message based SCTP's and should work as 
> proposed in the former drafts.
> 
> What do you think?
> 
> Shouldn't it be included into the actual draft?
> 
> By the way: The abstract section in draft-ietf-tsvwg-addip-sctp-04.txt still 
> mentions the flow limit extensions per-association and per-stream.
> 
> 
> Best regards,
> 
> Bernward
> 
> 
> Siemens AG Muenchen
> ICN WN CC NA J14
> 
> 
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sigtran

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

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

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 31 Jan 2002 13:47:21 -0600

Hi, Bernward,

There were some extensive discussions about what SCTP flow control
really means at the London IETF meeting (if I remember it correctly). We
sort of came to the conclusion that there is still some research work
needed to define a truly effective stream-based flow control function
inside SCTP. What we proposed before is actually a flow limiting
mechanism and its usefulness became a little unclear to us after some
further analysis. 

-Qiaobing

---

From: Randall Stewart <[email-masked]>
Date: Thu, 31 Jan 2002 13:45:57 -0600

Bernward:

The flow limit/control feature has been removed from the
add-ip draft and a hook put in for the eventual building
of such a feature (outside of the base SCTP protocol).

Phil Conrad (who is copied on this email) is working on
this.. Phil any progress? 

And it looks like you point out a bug in my editting out
of the flow control.. I missed the abstract.. sigh.. oh
well there is always -05 :>

R

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 31 Jan 2002 15:23:48 -0600

Phillip,

For signalling application (SIGTRAN UAs) we had a long discussion
on TSV concerning application flow control and hacking the rwnd.
The result of those discussions was the concensus that an application
should not muck with rwnd (i.e., set it to zero) in an attempt to
acheive application flow control.

The two SIGTRAN UAs which are most sensitive to flow controls are
M2PA and M2UA.  M2UA has a Correlation Id and Correlation Id Ack
which can be used on a per link (stream) basis to acheive application
congestion and flow control.  The next version of the M2PA draft will
include sequence numbers or a similar mechanism for application
congestion and flow control independent of SCTP.  The opensource
implementation of M2PA at http://www.openss7.org/ provides such
application congestion and flow control in anticipation of draft-04.

The remaining SIGTRAN SS7 UAs: M3UA, SUA (and the proposed TUA) have
access to the acknowledged data service provided by the RFC2960
SCTP-ULP API and present in some implementations (such as the
opensource implementations of SCTP at http://www.openss7.org/ )
Using the acknowledged data service it is not possible to acheive
full application level congestion and flow control (for which a
proposal for the same Correlation Id and Ack procedures of M2UA
were proposed for M3UA and SUA.)   Nevertheless, the acknowledged
data service does provide for per stream flow control for application
threads competing for cwnd and rwnd without the need for additional
protocol in SCTP.

To summarize, I don't believe that association flow controls would
provide any benefit to SIGTRAN SS7 UAs that could not be, perhaps
more easliy, accomplished in the UA protocols themselves.

The other alternative which has oft times been discussed is to
open a separate SCTP association for each stream of traffic,
and to not use SCTP's streams at all for unbalanced stream loads.
Some think this drastic, some think it suitable.

I would put it to you that even addip is not necessary: an
implementation which uses verification tag, port number and local IP
address only can easily detect when a peer sends from a new IP address
and include its address in its destination list.  Deleting IP addresses
can easily be accomplished by treating aborts on a per-destination
basis rather than a per-association basis.

--brian

Phillip T. Conrad wrote:                                  (Thu, 31 Jan 2002 15:22:54)
> At 07:03 PM 1/31/2002 +0100, Meyknecht Bernward 
> <[email-masked]> wrote:
> I had started some work on implementing all of the limits (byte and 
> message) per stream, and per association; this was work in the reference 
> implementation found at (sctp.chicago.il.us.)   However, I suspended this 
> work because the concept itself ran into some serious "concern" at the 
> London IETF.      In particular, there was concern that extra control 
> traffic would have to be added to make these limits work properly 
> (specifically, delivery acknowledgements), and that this control traffic 
> would pose an unacceptable burden on the protocol.
> 
> After further reflection, I decided to let it drop for now pending further 
> research that I hope will, at some point in the future,  provide some real 
> data to either
> 
> (a) show that one or more of these limits are useful and/or necessary, and 
> the the control traffic does not introduce a significant penalty or else
> 
> (b) show that I was wrong and the critics were right. i.e. to show that 
> this stuff is better done in application layer protocols, not in SCTP 
> itself.     (Note that if the application handles these extra limits, there 
> is still a need for signalling bits.. we've just moved the signalling bits 
> from one layer to another.  But an argument can be made (and was made) that 
> the needs for these limits are application specific enough that they do not 
> belong in SCTP.
> 
> For my part, my main motivation for pursuing per-stream flow limits was to 
> ensure that messages could not be indefinitely postponed (through the 
> scenario listed at the bottom of this message), and in a larger sense to 
> allow the application some control over the competition for window space 
> (and hence bandwidth) among multiple streams.     Through some discussions 
> at the London IETF, a different fix for the indefinite postponement problem 
> was suggested, and slated for inclusion in the implementer's guide (though 
> I'm not sure whether it made it or not... I need to check.)
> 
> In the meantime, if there are some good reasons to bring back the 
> association level message limit, I'd be glad to ressurrect the deleted text 
> and dust off the deleted source code, and try to make these 
> work.   However, since I'm a "transport guy" and not a "telephony 
> signalling guy" I need some help from the sigtran community to "make the 
> case for this" or any other additional flow control limits (beyond the base 
> protocols rwnd and cwnd) that we want to see included as extensions.
> 
> If someone else can make a compelling case for why these limits are needed, 
> and convince the opinion leaders in the two working groups (sigtran and 
> tsv) I'm happy to do the grunt work on the ID language, implementation 
> (i.e. patches for one or both of the two open source implementations) and 
> testing.
> 
> Thanks,
> Phill Conrad <[email-masked]>
> Asst. Professor, Temple University, Philadephia PA
> http://netlab.cis.temple.edu
> 
> 
> **********************************************************************
> **********************************************************************
> **********************************************************************
> 
> PS: Here's the original scenario that I suggested as a motivation for 
> per-stream flow limits.
> 
> Consider for example, an application that strictly alternates between 
> writing 400-byte messages to stream 0 and 1300-byte messages to stream 
> 1.   Suppose now that the application process consuming the messages is 
> temporarily suspended due to a context switch, and the sending application 
> fills up the available per-association rwnd buffer space.   If the messages 
> are consumed by two different threads at the receiving application, it is 
> possible that the window will open up space 800 or 1200 bytes at a 
> time.  In this situation, there is nothing in RFC2960 that would prevent an 
> implementation from always being "greedy", and choosing from among the 
> packets at the head of each stream one that will fit in the currently 
> available min(rwnd,cwnd) space.    In fact, because of concern about head 
> of line blocking, some folks insisted that this is exactly what an 
> implementation SHOULD do!  I argue, on the contrary, that a greedy approach 
> can result in head-of-line blocking for the *larger* chunks at the expense 
> of smaller ones, similar to what happens with a "shortest job first" 
> strategy for scheduling jobs.
> 
> Per stream flow control fixes this by reserving flow control space for each 
> individual stream.   It allow an application to ensure the progress of each 
> stream, at the expense of reduced throughput (if the window/rtt < 
> bandwidth*delay product), and at the expense of a minimum packet size on 
> each stream (equal to the per-stream byte limit.)   Note that as an 
> extension, it is an entirely optional feature, and would not restrict 
> applications that do not choose to use it in anyway.
> 
> However, a more lightweight fix was suggested for this 
> problem.  Specifically, it was suggested that language be added to the 
> implementer's guide to ensure that the order in which messages are 
> submitted to SCTP by the Upper Layer Protocol must be preserved as the 
> initial sending order (note that this does NOT re-introduce head-of-line 
> blocking of the type that multiple streams in SCTP is designed to prevent; 
> it is still possible to deliver chunks out of sequence at the *receiver*, 
> for example, when a chunk with a lower TSN from an *unrelated* stream is 
> lost. )    This was agreed to by several folks during a discussion at the 
> London IETF, though I don't know if it ever made it into the implementer's 
> guide.   (I should check on this.)
> 
> ptc
> 
> 

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