Subject: Re: [Tsvwg] SCTP applicability statement

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 5 Nov 2001 17:51:08 -0600

Qiaobing,

Quite frankly I agree with you.  I would prefer an application level
sequence number, ack, queuing and retransmission.  Or, basically what
you term buffer management.  I have proposed on several occasions that
M2PA and other use a sequence number tagging and acknowledgement to
conquer this difficulty.  M2UA does have a Correlation Id/Ack which can
be used to the purpose of flow control an buffer management between M2UA
peers.

We started discussing this back in May under the subject "M2PA:
Acknowledgement Problem".  (Probably even further back.) I proposed that
an sequence number and ack be added to M2PA to achieve this flow
control.  We also went through a lot of discussion on TSV regarding the
retrieval of messages using the SCTP sockets draft.

The advantages of an application level flow control is that it permits
application flow control to be completely independent of SCTP
parameters.  It will be difficult enough tweaking SCTP parameters,
buffer sizes, RTO.min, max, retrans maxes, and other characteristics of
SCTP to best suit the network over which it is running without messing
it all up with application flow control.

If TSV can say that "SCTP can't (or won't) do this" then there are other
solutions at the application layer with a wider range of benefit.

The level of resistance in SIGTRAN to placing application level flow
control in the xA has boistrous:

	"till now we don't have sequence number at m2pa
	level.  and it doesn't make any sense to make queue
	at m2pa level."

	"Talking of queues at M2PA level suggests that we
	are trying to mimick MTP2, which in my opinion is
	incorrect as we already have reliable service from
	SCTP as transport protocol for M2PA."

	"I see no value addition to the M2PA Stack by adding
	Seq.  Numbers, moreover i see an additional
	overhead."

	"Since M2PA has an Already proven and reliable
	medium.  I do not find any positive traits by adding
	SSn to the M2PA Stack."

	"I also think that ACK functionality at the m2pa
	level is redundant overhead."

	"Why can SCTP not withold its ACKs?"

	"Is there some reason why the SCTP spec could not be
	modified so that it allowed the ULP to withhold
	ACKs?"

	"I think the problem should be addressed at the SCTP
	level.  Today we have a requirement in M2PA,
	tommorrow the same may come up in some other layer.
	Also SCTP-SCTP reliability is useless if
	SCTPULP-SCTPULP reliability is not guaranteed."

	"Is there a previous thread where m2pa level
	buffering of user messages was discussed and a
	conclusion made that support at SCTP level is
	insufficient or not necessary?"

	"..."

And on, and on: I just went back on one short thread.

Either SCTP supports this capability or it doesn't.  Please pick and for
mercy sake write it in the AS.  I prefer that TSV say "No: SCTP does not
support this (it has enough on its plate), it is the application's
responsibility to institute application flow controls to the degree
necessary to provide redundancy across associations."

--brian

Qiaobing Xie wrote:                                      (Mon, 05 Nov 2001 17:10:38)
> "Brian F. G. Bidulock" wrote:
> ...snip...
> > 1)  Withhold acknolwedgements at ULP control for intervals longer
> >     than several seconds without aborting or otherwise degrading
> >     an SCTP association.  RFC 2960 says that all new DATA messages
> >     MUST be acknowledged and sets upper bounds (usually 200ms) on
> >     any acknowledgement.
> 
> Brian,
> 
> It seems to me that if you use a ULP level acknowledgment, this problem
> goes away, right? If so, all you are trying to do is to push more app
> specific functions down into SCTP so that the ULP can get simplified. I
> think that is wrong.
> 
> -Qiaobing
> 
> 
> ---
> 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/

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

---

From: David Lehmann <[email-masked]>
Date: Tue, 06 Nov 2001 08:44:04 -0500

> necessary to provide redundancy across associations."

Amen!

> > specific functions down into SCTP so that the ULP can get simplified. I

Amen again!

-David