Subject: RE: [Tsvwg] SCTP Sockets Mapping - Closure of TCP-style SCTP sock ets

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 18 Jun 2001 15:28:47 -0700

I agree Brian. Likewise, I think the fact that SCTP has no
undirectional/half closed states does not preclude the usefulness of
shutdown() to perform a graceful shutdown in a similar manner to TCP.
Preserving a similar shutdown()/close() behavior to TCP should make it a lot
more intuitive to port applications from TCP to SCTP.

I'm sure that shutdown() for TCP is used by most applications for graceful
shutdown rather than for initiating steady-state unidirectional/half-closed
TCP states in any case.

I see problems in specifying SD_RECEIVE & SD_BOTH (because the remote
application would receive acknowledgement for data that was not actually
delivered to the application) but SD_SEND can still be useful for graceful
shutdown at the application layer.

Robert.

-----Original Message-----
From:	Brian F. G. Bidulock [mailto:[email-masked]]
Sent:	Monday, June 18, 2001 10:47 PM
To:	[email-masked]
Subject:	Re: [Tsvwg] SCTP Sockets Mapping - Closure of TCP-style SCTP
sockets

Mike,

On Mon, 18 Jun 2001, Mike Bartlett wrote:

[snippage]

> 1. Allow an application optionally to decouple socket closedown from
> locally-initiated association shutdown, both for graceful and non-graceful
> shutdown.
> 2. Allow an application to receive data and/or notifications after it has
> made a call to close(), and possibly after the call to close() has
> completed.
> Of these choices I much prefer the first.  What do other people think?

I agree with (1); however, I don't believe that close() should be
completely decoupled from graceful or ungraceful shutdown.  In TCP
implementations it is common to RST a closed socket which has
outstanding data to be sent at the time that the socket is closed.
Otherwise, they could hang around forever.  The user has gone away.
Similarly, when SCTP TCP-style sockets close() if there is outstanding
data to be sent, the association should ABORT (there is no user and
the other end could keep the association alive indefinitely).  If
there is no outstanding data, SHUTDOWN should be sent and, if data
is delivered from the peer, ABORT performed (there is no user to
deliver any received data to.)  The shutdown() mechanism can easily
be adapted to perform graceful shutdown.  Although it would not act
the same as TCP's semantics, I hear that few applications really use
shutdown() anyway.

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 18 Jun 2001 21:11:09 -0500

Robert,

Just a few more thoughts...

I agree with your comments, however, I implemented SD_RECEIVE
and SD_BOTH so that when the receiver has been shutdown, receipt
of further (non-duplicate) DATA chunks will result in an ABORT
rather than a SACK.  That way the receiving application can
really say that it doesn't want to receive any more data!  Also,
receipt of a SHUTDOWN or SHUTDOWN ack is equivalent to a
SD_RECEIVE and SD_SEND sends a SHUTDOWN.

On close() if data remains in the write queue an ABORT is sent
and the socket is closed immediately (but we could probably wait
for SO_LINGER).  If there is no data in the write queue a
SHUTDOWN is attempted, but with SD_RECEIVE set (so, if data is
received after the SHUTDOWN is sent, the association will be
aborted).  If the graceful shutdown doesn't complete within a
short period (SO_LINGER), the association is aborted.  As with
TCP, this is to keep bound sockets from hanging around using up
port numbers.

This way, if you do a close() with no data in the write queue
and with the other end having no more data to send, the close()
will result in a graceful shutdown.  If there is data
outstanding in either direction, the association will soon
abort.  So, shutdown(fd, SD_SEND) is the best way to gracefully
shutdown an association, (which is, sadly, backwards from TCP).

Perhaps not so strangely, SD_BOTH has the same semantics as
close(), but the socket still exists.  If SD_RECEIVE has the
semantics I implemented above (ABORT if data arrives), this has
exactly the same effect as close() without socket destruction.
This would be an ideal way to shutdown as socket which was about
to perform retrieval (no parallel in TCP, really).  SD_RECEIVE
is still useful, in that if DATA arrives, the association is
ABORTed and the application receives EPIPE/SIG_PIPE to indicate
the loss of connectivity.

The close() semantics of generating an ABORT and not perfoming a
graceful shutdown in these situations is ncessary so that the
peer application receives EPIPE/SIG_PIPE in the same circumstances
as TCP would provide EPIPE/SIG_PIPE.  Otherwise, an application
such as FTP could send a large amount of data into the network
before recognizing that the connection had been shut down.

The complications is partly due, not to SCTP's lack of
half-close, but because SCTP's close is reversed from that of
TCP.  When TCP sends FIN, it say "don't send me any more data".
When SCTP sends SHUTDOWN or SHUTDOWN-ACK it (quite rhetorically)
says "I'm not sending you any more data".  It still takes both
sides to shut down in SCTP and the association can be hung in
the middle by a peer who continues sending data and refuses to
send SHUTDOWN-ACK.  This leaves, in many circumstances, ABORT as
the only way to definitively shut down an association.  It is
sad that SCTP did not follow TCP's elegant mechanism, the
half-open socket byproduct of which has been studied and solved
and is already largely handled in the OOTB response.  SCTP's
creators were certainly not thinking of the socket interface
when choosing this innovation.

--Brian

On Mon, 18 Jun 2001, Fairlie-Cuninghame, Robert wrote:

>    Preserving a similar shutdown()/close() behavior to TCP should make it
>    a lot more intuitive to port applications from TCP to SCTP.
>    
>    I'm sure that shutdown() for TCP is used by most applications for
>    graceful shutdown rather than for initiating steady-state
>    unidirectional/half-closed TCP states in any case.
>    
>    application would receive acknowledgement for data that was not
>    actually delivered to the application) but SD_SEND can still be useful
>    for graceful shutdown at the application layer.
>    
>    Robert.
>    

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

---

From: Kacheong Poon <[email-masked]>
Date: Mon, 18 Jun 2001 21:45:33 -0700 (PDT)

> SD_RECEIVE and SD_SEND sends a SHUTDOWN.

I assume SD_RECEIVE means shutdown(SHUT_RD).  The above is a
reasonable thing to do in the stack.  But why an app wants to do
a shutdown(SHUT_RD) is questionable.  Can you suggest an example,
can be TCP or SCTP app, which this is useful?

> TCP, this is to keep bound sockets from hanging around using up

The above is not what an app expects from a TCP socket.  As mentioned
in my previous mail, closing a socket with outstanding unsent data
should not mean an ABORT (or TCP RST).  This should only be done
when SO_LINGER interval is set to 0.  And if SO_LINGER is set to a
positive value, only the close() should return with an error.  SCTP
and TCP should continue to deliver the unsent data.

> shutdown an association, (which is, sadly, backwards from TCP).

Is shutdown(SD_SEND) the same as shutdown(SHUT_WR)?  I think SHUT_WR
is defined in XPG4.  The half-close in TCP (a graceful shutdown) is
done exactly by shutdown(SHUT_WR).

> when choosing this innovation.

The above description of TCP FIN and SCTP SHUTDOWN is not quite
correct.  In TCP, sending a FIN means that one side is done with
sending data, not "don't send me any more data."  As a matter of
fact, this is how TCP half-close is done.  Sending a FIN signals
the other end that it is done with sending the request.  So the
other end can start replying.

In SCTP, sending a SHUTDOWN means 2 things.  The sender is done
with sending and the receiver should not accept new data from the
app.  So with both TCP FIN and SCTP SHUTDOWN, the sender is done
with sending data.  But it is the no new data from app in the
receiver of SHUTDOWN which makes adding a comparable meaning to
shutdown() difficult.

If people think that we should add shutdown() to the socket
extension, we can do that.  But it will not have similar meaning
as with TCP.  shutdown(SHUT_WR) can trigger a SHUTDOWN chunk.  And
the app can still receive data from the socket.  But the data
received can only be data sent by the other side before the
SHUTDOWN chunk is received.  So in a certain sense, the app cannot
know what data is to be received after shutdown(SHUT_WR) unless it
has some app level protocol to coordinate this.  The receiver of 
SHUTDOWN will get 0 as the return value of read (recv()/...) call.  
After that, the receiver should probably close() the socket.

I believe the above semantics is actually in the version 0 or 1
of the draft (before it was renamed to *-tsvwg-sctpsocket-*).  It
was removed because of the different meaning from TCP and we want
to avoid confusion from app programmers.

							K. Poon.
							[email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 19 Jun 2001 00:55:37 -0500

Kacheong,

Well, it looks like I had the FIN thing backwards; however,....

shutdown() is not part of TCP.  It is part of the sockets
interface which is just as applicable to OSI and other protocols
as TCP.  SCTP should not change the semantics of this socket
call.  From XPG XNS 5.2 the "shutdown() function disables
subsequent send and/or receive operations on a socket".  The
effects on subsequent operations on the socket are clear.  An
attempt to perform write() or send() or sendmsg() when the
socket has been shut down for write must return EPIPE.  An
attempt to perform read() or recv() or recvmsg() when the socket
has been shut down by the peer must return 0.

I see absolutely no reason to change the semantics of the
existing API of the socket interface for SCTP.  Any change in
semantics is bound to be confusing to sockets programmers who
have taken the time to learn the existing way of doing things
(not just for TCP but for all other protocols supported by the
socket interface).  (If you hope to change XPG XNS or POSIX with
an IETF draft, I will see you at the IEEE balloting ;)

I think that efforts would be better spent determining how the
existing socket API maps onto SCTP, rather than attempting to
change the socket interface for SCTP's sake alone.

shutdown() should perform exactly as it does for other protocols
in terms of the API semantic.

If an implementation wishes to send SHUTDOWN in response to a
shutdown(SHUT_WR) that's ok.  If the peer receives a SHUTDOWN,
it COULD return EPIPE to write(), send() and sendmsg() and
signal SIG_PIPE.  What's the matter with that?  How is it
confusing in comparison to TCP?  TCP uses the same socket
semantics...

Both socket users expect EPIPE when they can't write and 0 when
they can't read data.  This will be the effect of shutdown()
(unless someone tries to modify the definition).  Portability of
programs is not acheived by altering the sockets interface for
every new protocol.

--Brian

(I still think it COULD allow the data to be written.  RFC 2960
says that "endpoint MUST NOT accept any new send request from
its SCTP user".  Yet, the document only "sketches the API which
should exist at the boundary between the SCTP and the SCTP user
layers." It is fairly slipperly to attempt to enforce a MUST on
a sketchy thing.)

On Mon, 18 Jun 2001, Kacheong Poon wrote:

[snip]

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

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 19 Jun 2001 17:01:02 -0700 (PDT)

> an IETF draft, I will see you at the IEEE balloting ;)

No, this is exactly what we are trying to avoid.  For instance,
instead of playing with the bind() call (since the second param is
a pointer, we can do a lot of things with it for binding multiple
addresses), we opted for adding a new call sctp_bindx().  As I
stated previously, the major reason is to avoid giving app programmers
the impression that SCTP supports exactly what TCP does.  This is
the confusion I talked about.  We can make shutdown(*) a no-opt in
SCTP level, and just keep the socket semantics.  But then some apps
will break and the user may not be aware of it right away.  I think 
this is another way to look at the issue.

Note also that we always try to make sure that if an app wants to
be ported from TCP to SCTP and it does not need to use all SCTP's new
features, the only change needed is to replace IPPROTO_TCP with
IPPROTO_SCTP in the socket() call.  If it uses the wildcard for address
binding, the fault detection machanism is automatically enabled.  But 
because of the difference in shutdown semantics, those apps which use
shutdown() will not get the same thing as in TCP.  So we want to find 
a way to get around this.  This is why the current draft has shutdown()
disallowed.  Apps will get an error immediately.

> programs is not acheived by altering the sockets interface for

As I mentioned previously, we are open to adding the shutdown()
call back.  One way is to make shutdown() a no-opt in the SCTP
level.  But what you mentioned above is not quite correct.
With the current SCTP shutdown requirement, shutdown() cannot have
the same semantics as with TCP.  The reason, as stated before, is that
apps expect to be able to send() (write()/...) after recv() (read()/
...) returns 0.  We just cannot have that according to the current
spec.  That means those apps cannot be ported to SCTP without
a lot of changes (probably adding a app level protocol to signal
the end of sending instead of using SCTP for that).

More comments are welcome to decide what the right way is.

							K. Poon.
							[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 19 Jun 2001 17:16:01 -0700 (PDT)

I want to ask one question relating to the current SCTP shutdown() socket
semantics discussion.  SCTP has the exact same 3-way handshake when an
association shutdowns as with TCP.  What is the reason behind not allowing
the same TCP half-close semantics?

From an SCTP stack implementation point of view, all implementors need
to do is to remove the check for accepting new app data and the check
to generate SHUTDOWN-ACK when all unsent data at the time of getting the
SHUTDOWN chunk is acknowledged.  When the app signals that it is done
with sending, send out the SHUTDOWN-ACK chunk.  Basically, there is
very little change.  If the app chooses to have the current shutdown
semantics, it can stop sending after the shutdown notification comes up
and signal to the SCTP stack that it is done with sending.  Then the
app will get back the current shutdown semantics even after the change.

So what is the reason of not allowing this?  If this is allowed, the
SCTP shutdown() call will have the exact same meaning as with TCP.  It
means that even those rare apps which use half-close can be ported to
use SCTP with just a protocol field change in socket() call.  And for
those apps which require the current SCTP shutdown semantics, they can
still do so.  It seems to me that it is only a matter of some wording
changes in the SCTP RFC.  Or is there a bigger problem?

							K. Poon.
							[email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 19 Jun 2001 19:25:10 -0500

Kacheong,

It is not the case that TCP apps expect to be able to do
send() after recv() returns 0.  recv() retruns 0 when the
connection is disconnected, and a TCP app cannot expect
to send() and recv() returns 0 in that case.  A TCP app
will get EPIPE/SIG_PIPE.  It is not different from the
possible SCTP case.

On Tue, 19 Jun 2001, Kacheong Poon wrote:

[snip]
> The reason, as stated before, is that

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 19 Jun 2001 19:28:45 -0500

Kacheong,

See the bottom of my last note to which you replied.  It outlines
the same thing and the "sketchiness" of the MUST in RFC 2960.

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

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 19 Jun 2001 18:08:53 -0700 (PDT)

> the same thing and the "sketchiness" of the MUST in RFC 2960.

Correct me if I am wrong in understanding your note.  It seems to
me that you were suggesting the "sketchiness" of the API.  But 
actually there is more than that in the RFC.  Besides new data,
it also specifies when the SHUTDOWN-ACK chunk is sent out.  This
means that even though stack implementors want to be a little
bit "fuzzy" about accepting new data, it has to obey when the
SHUTDOWN-ACK is sent.  Otherwise, the app may break because there
can be a timing requirement in the app.

Anyway, the question I was trying to ask was the reason why SCTP
does not support the same close down semantics as TCP even when SCTP
has the same close down 3-way handshake.

							K. Poon.
							[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 19 Jun 2001 18:19:42 -0700 (PDT)

> will get EPIPE/SIG_PIPE.  It is not different from the

In the context of what we are discussion (use of shutdown(SHUT_WR)
to do TCP half-close), the app indeed expects to send after recv()
returns 0.  You can check the code of, say, rsh.  Note that with
TCP, recv() returning 0 does not necessarily mean that the socket 
is disconnected.

							K. Poon.
							[email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 19 Jun 2001 20:28:16 -0500

Kacheong,

> TCP, recv() returning 0 does not necessarily mean that the socket 

My point is that it doesn't necessarily mean that it is still
connected either.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 19 Jun 2001 20:41:11 -0500

Kacheong,

> has the same close down 3-way handshake.

There is no way for the sending of the SHUTDOWN to enforce this
behavior.  The SHUTDOWN sending will continue acking data with
SHUTDOWN or SHUTDOWN SACK combinations until it receives a
SHUTDOWN-ACK.  This is already identical to TCP's behavior on
the SHUT_WR side.

The receiver of the SHUTDOWN must not let the ULP send any new
data, but the interpretation of what new data constitutes is really
up to the implementation.  Data which is buffered in the socket
app could be considered queued data, resulting in the same semantic
as TCP.  It is clear that the receiver of the SHUTDOWN must not
send SHUTDOWN-ACK until all queued data is acknowledged.

The originial discussions of shutdown in SCTP were centered around
trying to avoid a half-close situation; however, SCTP was forced
to deal with the situation because of possible loss of a SHUTDOWN-ACK
message.

If the shutdown sequence is prolonged by delaying a SHUTDOWN-ACK
to acheive compatibility with TCP semantics, the restart procedures
will not be as effective.  This is because SCTP does not accept
INIT restarts while shutting down.  Nevertheless, if the peer
restarts, while an association is in this half-closed state, the
OOTB handling should close the association very rapidly.

I don't see any real technical problems with making SCTP operate
in this TCP-compatible mode.  Sounds like a useful socket option.

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

---

From: Randall Stewart <[email-masked]>
Date: Tue, 19 Jun 2001 21:21:02 -0500

> has the same close down 3-way handshake.
Kacheong:

I would have to go back through the mail archives of sigtran to
be able to answer this. I just don't remember off the top
of my head. I do remember we discussed this and we could only
come up with one application that used this "half-close" 
feature of tcp... i.e. rsh. On top of that I don't think any
of us in sigtran ever thought that there would be a need to 
move rsh (which more fits a byte oriented transfer than
a message oriented one) to SCTP :/

Now Brian may be right in that you can NOT detect, from the
peer's side, that you are not compliant to the spec. But give
me about 5 minutes with both implementations and I can
write a test program that will show that one side is
non-compliant. Not that it ever stopped some companies ("where
do you want to go today") from putting out a non-compliant 
implementation mind you :0

Maybe I will get the ambition up to go dig through the archives
and look at the old debate... after I finish working on 
the paper work I have to get done ... sigh.. I am rather
buried right now... 

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

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 20 Jun 2001 14:20:12 +0200 (CEST)

> the same TCP half-close semantics?

The 3-way handshakeis not identical as far as I know.
In TCP the receiver of the FIN can send an ACK to indicate that the
FIN has been received without sending a FIN itself.
This is possible since the FIN is defined to occupy one byte in the
TCP sequence space.
There is no equivalent in SCTP.

> So what is the reason of not allowing this? 

For one the sender of the SHUTDOWN would time out and retransmit the shutdown 
until the SHUTDOWN-ACK is received. I haven't checked if the spec says that
it should also give up after some number of reransmits.

  Erik

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 20 Jun 2001 08:16:29 -0500

Erik,

> it should also give up after some number of reransmits.
If the receiver of the SHUTDOWN continues sending data, the SHUTDOWN
is merely resent in the same fashion as a SACK and the timer is
cancelled.  It is true that if there is a period that the SHUTDOWN
receiver has no data to send that the sender of the SHUTDOWN will
start retransmitting the SHUTDOWN, however, it would be possible to
send duplicate DATA chunks to keep the sender from going through
this behavior.

--Brian

---

From: Shyamal Prasad <[email-masked]>
Date: 20 Jun 2001 08:48:22 -0500

"Kacheong" == Kacheong Poon <[email-masked]> writes:

    Kacheong> I want to ask one question relating to the current SCTP
    Kacheong> shutdown() socket semantics discussion.  SCTP has the
    Kacheong> exact same 3-way handshake when an association shutdowns
    Kacheong> as with TCP.  What is the reason behind not allowing the
    Kacheong> same TCP half-close semantics?

Kacheong,

In around March last year the consensus was that the TCP half close
was not a "useful" feature to include in SCTP. We went through very
similar debates, and personally I'd love to have it in SCTP, but a
consensus is a consensus ;-)

Cheers!
Shyamal

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 20 Jun 2001 16:13:04 +0200 (MEST)

Brian,

> send duplicate DATA chunks to keep the sender from going through

You're observing that the current spec, which as far as I recall the discussion
about a year ago, was explicitly designed not to support half-open connections,
does not directly prevent an implementation that wishes to provide half-closed
semantics. I don't think that is necessarily a good thing ...

If there is really WG consensus that SCTP should (have) support(ed)
half-closed then I think in the interest of spec clarity as well
as interoperability it would make sense to carefully specify how this works 
including thinking about interoperability with the current proposed standard.

   Erik

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 20 Jun 2001 12:13:12 -0500

Lloyd,

Power failures and crashes are handled by SCTP already.
This is the normal case if the crash occurs after the
SHUTDOWN is sent but before the SHUTDOWN ACK is received.
SHUTDOWN retransmission or HEARTBEAT will be treated as
OOTB when the other end comes back up (if ICMP doesn't
drop the association anyway) and the association will
terminate.

--brian

On Wed, 20 Jun 2001, Lloyd Wood wrote:

> On Wed, 20 Jun 2001, Brian F. G. Bidulock wrote:
> 
> > I don't think that SCTP really needs half-close semantics.  I was
> > just making an observation that, although the intention was not to
> > support them, they are supported anyway.  It is not necessary to
> > send duplicate DATA packets as I describe, the SCTP sender is not
> > released from the obligation of sending HEARTBEAT to ensure RTT
> > calculation just because it has sent a SHUTDOWN.  It is the obligation
> > of the sender to send HEARTBEAT and clear error counts for the
> > destination and association should it not receive anything upon which
> > it can calculate a RTT.  This is another observation ;)
> 
> What happens in the event of power failure/crashes at one end?
> 
> L.
> 
> worried about failure modes.
> 
> <[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 20 Jun 2001 11:42:47 -0500

Erik,

If SCTP really wanted to preclude a half-close situation, the sender
of the SHUTDOWN should be required to start a timer after the expiry
of which the association should ABORT, or some such procedure which
could enforce the situation.

--Brian

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

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 20 Jun 2001 18:09:46 +0100 (BST)

L.

---

From: Randall Stewart <[email-masked]>
Date: Wed, 20 Jun 2001 13:55:19 -0500

> What happens in the event of power failure/crashes at one end?

To add to what Brian said... 

An endpoint will only allow so many heartbeats to be missed. So if
the crashing machine does not come up for a while (or it is in
California under a long rolling blackout :/) missing a threshold
number of HB's will cause the association to fail. If it does
come up, as Brian said, an ABORT will be sent back since the
restarted machine will not recognize the association.

The SHUTDOWN-ACK must show up (or some other packet) or else
the SHUTDOWN will get retransmitted to the threshold and then
the association fails..

Some implementations may also put a limit as to how long
they will await the SHUTDOWN-ACK. Hmmm I think this may
be added to the shutdown states of the reference implementation.
It sounds like a good safety valve to catch implementations
that DON'T stop accepting user data ....

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 20 Jun 2001 14:26:49 -0500

Lloyd,

We just expained that if the box goes away or crashes, SCTP
will already timeout.  Shortening this timing would be a
matter of tuning SCTP's existing protocol parameters.  A
separate timeout is not necessary.

Following along the lines of what you are saying, however,
a malicious endpoint could open a bunch of associations and
ignore SHUTDOWNs, holding may associations open with little
effort on the part of the malicious endpoint.  Possible
DoS attack, perhaps, on servers that are too brittle.

--Brian

On Wed, 20 Jun 2001, Lloyd Wood wrote:

> On Wed, 20 Jun 2001, Randall Stewart wrote:
> 
> That's exactly the 'half-close' problem http servers had for TCP;
> badly-behaved clients would go away/crash, and open connections would
> build up and up and up on the webserver until the machine fell over.
> 
> timeout limits are essential here.
> 
> L.
> 

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

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 20 Jun 2001 12:42:24 -0700 (PDT)

> a message oriented one) to SCTP :/

If I remember correctly about the discussion last year, it was
all about the original ungraceful shutdown.  I remember people
saying that while SCTP does not need to support the half-close
semantics of TCP, it is still better to have a graceful shutdown.
Then people came up with the current scheme.  But no one (I was
puzzled yesterday when I thought about this) asked why half-close
should not be supported given that SCTP now does what TCP does
at close down.

The current SCTP scheme is asymmetrical.  One end forces the other 
end to stop sending new data.  TCP's FIN is symmetrical in the sense
that one side only tells the other side it will stop sending new
data.  The semantics is clearly different.  The half-close behavior
"seems" to be a by-product of TCP's meaning of FIN.  So the question
is why does SCTP need such an asymmetrical shutdown?

							K. Poon.
							[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 20 Jun 2001 13:06:39 -0700 (PDT)

> SHUTDOWN-ACK.  This is already identical to TCP's behavior on

There is no way to "enforce" the other end to do anything...  It is
outside of our control...  We are talking about protocol design
here...  If one side decides not to comply with the protocol, well...

> send SHUTDOWN-ACK until all queued data is acknowledged.

I believe this API issue should be discussed in another thread.  There
is a reason why I started a new thread to discuss the protocol issue...

I think you are actually "stretching the words" in the RFC.  What my
question is not about stretching the words.  It is very clear in
the RFC that if there is no data in the queue, a SHUTDOWN-ACK must be
sent.  I started this thread to discuss this issue, not about stretching
the words or about protocol implementation correctness enforcement...
I want to understand the rationale behind SCTP's asymmetric close down 
semantics

I agree with you that the wording in the RFC may not be precise enough.
But let's not discuss that issue in this thread.

> to deal with the situation because of possible loss of a SHUTDOWN-ACK

By half-close, do you mean half-open?  They are 2 different things...

> OOTB handling should close the association very rapidly.

Can you explain the above effectiveness concern?  After stating that
concern, you immediately pointed out the SCTP will detect restart
rapidly...  So is your concern about something else?

> in this TCP-compatible mode.  Sounds like a useful socket option.

Again, while I happen to work with socket, there are other SCTP
APIs.  I think we should not talk about a specific API issue while
discussing the protocol...

							K. Poon.
							[email-masked]

---

From: Shyamal Prasad <[email-masked]>
Date: 20 Jun 2001 15:11:05 -0500

"Kacheong" == Kacheong Poon <[email-masked]> writes:

    Kacheong> better to have a graceful shutdown.  Then people came up
    Kacheong> with the current scheme.  But no one (I was puzzled
    Kacheong> yesterday when I thought about this) asked why
    Kacheong> half-close should not be supported given that SCTP now
    Kacheong> does what TCP does at close down.

Kacheong,

I always have wanted to quote myself, so I went and looked in the
archive ;-)

    "Shyamal" == Shyamal Prasad <[email-masked]> wrote
       Fri, 12 May 2000 14:11:52 -0500

    Shyamal> (just watch out for some hacker kid exclaiming a few
    Shyamal> years down: "What were these guys smoking?  I can't
    Shyamal> believe they never put in a half close" ;-)

It's hardly been a year, and it isn't even a hacker kid ;-)

Cheers!
Shyamal

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 20 Jun 2001 13:18:54 -0700 (PDT)

> It's hardly been a year, and it isn't even a hacker kid ;-)

Hey, are you an oracle (-:

							K. Poon.
							[email-masked]

---

From: Randall Stewart <[email-masked]>
Date: Wed, 20 Jun 2001 15:38:11 -0500

> It's hardly been a year, and it isn't even a hacker kid ;-)

Shyamal:

Maybe I am just slow today.. but I am not sure
what NOT having a 1/2 close does that is so bad.

1) If the guy is opening a bunch of connections
   and refusing to close.. by Brian's little tricks that
   violate the spec... how is this different than allowing
   a 1/2 close.

2) If your worried about an attack, what is different in
   this than just going ahead and holding up a bunc of
   open connections? Same problem right? I have tied up
   a bunch of resources...

3) If the peer does agree to close, and sends the S-A the
   session ends. If it restarts during the shutdown sequence
   its all covered... either the ABORT will clean it up OR
   the peer will send the SHUTDOWN getting no answer until
   the association fails...

I must be missing something here because I don't get it..

R

---

From: Shyamal Prasad <[email-masked]>
Date: 20 Jun 2001 18:08:16 -0500

"Randall" == Randall Stewart <[email-masked]> writes:

    Randall> Maybe I am just slow today.. but I am not sure what NOT
    Randall> having a 1/2 close does that is so bad.

Randall,

No, nothing slow about your reasoning. You are correct in that not
having a 1/2 close is very acceptable. 

    Randall>  [....use cases deleted....]
    Randall> I must be missing something here because I don't get it..

You're probably not missing much, it's mostly an opinion.

The reason I like 1/2 close is that it provides a way for one end of a
connection to tell the other "I am finished with sending you any data
I have to send you" without adding any application layer messages at
all, while still having efficient communcation in the other
direction. With SCTP today, to do something like that, I would need to
invent an application level message with "EOF" type meaning.

One can argue forever about the usefulness of this feature. I just
prefer semantics that are more "complete" (have the maxium feature set
for a given cost).  Between "have half close" and "not have half
close" for the same cost I would have gone for including half
close. It's just an opinion, and IMHO it does not matter anymore: SCTP
does not support half close, it's a done deal as far as I am
concerned.

All in all, SCTP without half close does not keep me up nights or
anything...... ;-) 

Cheers!
Shyamal

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 20 Jun 2001 20:10:20 +0100 (BST)

L.

---

From: Randall Stewart <[email-masked]>
Date: Wed, 20 Jun 2001 19:46:11 -0500

> invent an application level message with "EOF" type meaning.

But I think the base level thing here is no one uses this 
wonderful feature :->

> does not support half close, it's a done deal as far as I am

We might want to (down the road) formalize the "closing of the hole"
so to speak. Add an overall guard timer, say for 20 seconds or
something.. that when/if it goes off no matter if you are
getting packets or not .. you abort the association... 

Or some such other... Something to think about in idle moments
which I don't have many of right now ;/

> All in all, SCTP without half close does not keep me up nights or

Nor me :/
R

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 20 Jun 2001 18:15:59 -0700 (PDT)

> build up and up and up on the webserver until the machine fell over.

This is the FIN-WAIT-2 timeout many implementations have.

							K. Poon.
							[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 21 Jun 2001 11:06:12 +0200 (MEST)

> support them, they are supported anyway. 

Since you claim that they are "supported" can you point me at the
sections in the RFC that specify what an implementation does to handle
half-closed?

I think you are saying that an implementation can be tricky and
implement non-standardized half-closed for SCTP and if it is done carefully
enough it might still interoperate with standard SCTP.
I DON'T think this is how we ensure interoperability in the IETF.
At a minimum there should be a spec on how to implement any optional
half-closed semantics in SCTP so that two vendors that both implement this
actually can interoperate.

  Erik

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Jun 2001 08:48:48 -0500

Erik,

I eagerly await your draft. ;)

--Brian

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