Subject: Re: RFC 2960, section 6.5 - response to bogus stream ID

From: David Lehmann <[email-masked]>
Date: Mon, 03 Nov 2003 09:11:07 -0500

Qiaobing Xie wrote:
>>If the app sends data which is accepted by SCTP, it has reason to
>>believe that it will be delivered to the peer user.
> 
> 
> This belief is rather based on a shaky ground by the app sender. If the
> app sender needs to know for sure whether the data reached the app
> receiver, it must then rely an app layer ack, rather to assume SCTP ack
> is the equivalent because it is not.

I disagree.  Apps which do not need to know for sure whether the data
reaches the peer will choose an unreliable protocol like UDP/PR-SCTP. 

One reason people will choose SCTP/TCP is for its reliability, the 
guarantee that no data will be lost, duplicated, or reordered.
Associations/connections which can not provide such reliability
(for whatever reason) are aborted. 

The issue in question allows the association not to be aborted when
data sent by the peer has been dropped.  Both endpoints may never
know that data had been discarded.  IMHO, this problem slightly
diminishes the reliability claims of SCTP.

-- 

David Lehmann                          Ulticom, Inc.
AOL/Yahoo IM: davidULCM                1020 Briggs Road
1-856-787-2729                         Mt. Laurel, NJ 08054   USA

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 3 Nov 2003 09:07:50 -0600

> diminishes the reliability claims of SCTP.

You are missing a vital distinction. Reliable protocols *never* 
guarantee
that the data has been seen and processed by the remote peer. Never.

If you sent the data to the *wrong* stream, instead of a non-existent 
one,
how would you solve your problem? An application layer ack would
detect that mistake. Nothing SCTP can do would address it.

Ditto for sending the data in the wrong format.

Further, requiring an error message requires checking for the error.
If an implementation had a method for providing stream ordering
that had sufficiently low overhead for streams that did not have
held data chunks, and all streams were delivered to the same
destination, might choose to omit checking the inbound Stream
Number. After all, there is no obligation to waste code checking
something that the other side MAY NOT do unless failure to
do so creates a security issue.

If "wrong stream messages" went unclaimed and drained buffers
they might be a strange form of Denial of Service attack. Which
is why the receiving end MAY choose to abort the association.

With most applications, however, it will be the application that
will choose to abort the association. Just as it would if its peer
was sending garbage messages to the "correct" streams.

Ultimately, sending data chunks to non-existent streams is just
like any other form of Upper Layer Protocol violation -- it should
be dealt with by the Upper Layer.

The limit on the number of streams is a *convenience* to the
SCTP layer to *allow* it bound its resources. It should not be
viewed as a mandate for additional error checking.

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 03 Nov 2003 09:13:14 -0600

> diminishes the reliability claims of SCTP.
David:

No protocol is fully reliable. Any application that thinks a TCP or SCTP 
ack means
the data got there is in for a rude awakening when the machine or app 
crashes after the
ack as been sent off.

And your other point about "diminishing the reliability" is also a bit 
off base IMO since
aborting the association throws EVERY data in transit out breaking the 
reliability. As
the spec now reads you, the sender, are told.. you sent a bad datagram 
on Stream N .. Stream
N does not exist. The application can be passed this notification and 
all other VALID data
is reliably delivered.. instead of throwing everything out..

The application, getting the notification (or stack for that matter) can 
then make
decisions on how to proceed.... On top of that, this is rather a moot 
point.. since
anyone seriously developing an SCTP stack is going to send it data on an 
invalid
stream number to make sure that the data is rejected... so I think you 
are arguing
over a nit..

R

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)

---

From: David Lehmann <[email-masked]>
Date: Mon, 03 Nov 2003 10:55:35 -0500

> the data got there is in for a rude awakening when the machine or app 

The surviving app eventually would have received an abort notification
(either due to an ABORT from the peer SCTP or due to no heartbeat acks).

> reliability. 

Getting an abort tells me that there was a problem.
IMO, this increases reliability.

> As

We went through this argument before. :-)

> stream number to make sure that the data is rejected... so I think you 

It is a nit, which is why I agree to stop arguing about it.
I am not insisting on my way.

Someone wrote an opinion, addressed specifically to me, in a public
forum.  I simply responded to that post.  In hind sight, I probably 
should have returned my comment in private email.

--

---

From: "Xiaodan Tang" <[email-masked]>
Date: Mon, 3 Nov 2003 10:57:10 -0500

Maybe this is a little off topic.

I was wondering what kind of "Traditional Services" could be moved to SCTP
to take fully advantage.

For example, is a ftp over SCTP make more sense? Using multi-stream to 
transfer different pieces of a large file could increase the performance? 
Any other idea ?

-Xiaodan Tang

---

From: Sourabh Ladha <[email-masked]>
Date: Mon, 3 Nov 2003 11:59:14 -0500 (EST)

> transfer different pieces of a large file could increase the performance?

Xiaodan,

I have a paper that tries to show the advantages of running ftp over sctp.

Sourabh Ladha, Paul D. Amer, Improving Multiple File Transfers Using
SCTP Multistreaming.

(Available at http://www.eecis.udel.edu/~amer/PEL/poc/index.html#pubs )

-Sourabh

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 03 Nov 2003 11:23:34 -0600

>transfer different pieces of a large file could increase the performance? 
Xiaodan:

I believe that Peter Lei and I have at one time or another made:

1) ssh/openssh
2) mozilla
3) apache
4) ftp

But with a cavet.. we have not taken advantage of SCTP's 
multi-streaming.. just
switched the socket call to use SCTP's TCP model to test out to make sure we
had no surprises :>

Now I know that University of Delewar PEL lab was showing some remarkable
results with FTP (modifying ftp to take advantage of mutli-streams).  
They also
were looking into enhancing mozilla/apache to use streams as well.. 
don't know
how far they got ... I don't have there web site off the top of my head but
google would find it for you.. they have quite a few papers and 
studies.. and a
lot of ongoing research..

I am sure there are other apps that could also benefit from SCTP.. the 
problem I see
consistently is the ole catch-22...

Developer of new app (or old app).. Gee I don't see ALL systems have 
SCTP and I
don't want to deploy something that is not everywhere without having to do
fancy steps with the o/s to get it (translated buy additional software). 
I will instead
jury rig my application to fit TCP, which I fully admit would be better 
to run over SCTP.. but
I will make it fit over TCP anyway until that future day when SCTP is 
everywhere (aka read windoz).

O/S developor (especially at the m-s company) .. Gee I don't see any 
market pressure or demand
from the outside world for SCTP, no applications are demanding it.. so 
why should I
invest in adding the transport stack to my OS?

Now whats the answer? Not really sure but I  think the key
may be in that those O/S developors that don't implement may get
left behind.. go forward push out applicaitons that make sense over SCTP
and eventually the second group will wake up and find they are in a
bad position since they did not start early enough (look out m-s here comes
lk-sctp in 2.6 :->). And then of course the first group will eventually 
switch..
but they will also be stuck with strange things in there protocol that 
could have
been done more efficently.. but that seems to be the way of the world :-0

R

---

From: Marco Molteni <[email-masked]>
Date: Mon, 3 Nov 2003 18:44:43 +0100

On Mon, 3 Nov 2003 10:57:10 -0500

> I was wondering what kind of "Traditional Services" could be moved to SCTP

Not really "traditional", but we did MPEG-4 over partial reliability SCTP
instead of RTP/UDP; our first results where encouraging. We will soon do
further work in this area.

http://www.gufi.org/~molter/papers/mpeg4sctp-molteni-villari-2002-10-24.pdf

Marco