Subject: Re: wglc FOR draft-ietf-tsvwg-sctp-strrst-09 started

From: Kacheong Poon <[email-masked]>
Date: Mon, 04 Apr 2011 13:50:44 +0800

On 03/31/11 11:11 PM, t.petch wrote:

> No, reset is what I have in mind, but the IETF is a bit short
> of transport layer protocols with which to illustrate my point:-(
> so these are (more or less) application layer doing a similar job.
> For example, how many of the BGP restarts (with consequent
> ripple effects throughout the Internet) prior to Graceful
> Restart were caused by TCP problems which a proper
> TCP reset (not the current 'kill the connection') would have
> obviated?  I do not know of any research into that issue
> but if you look at BGP prior to Graceful Restart, then when
> anything went wrong, it more or less had to take the connection
> down and begin all over again with ripple effects etc.  So a TCP reset
> of the kind proposed for SCTP could have been quite beneficial.
> (Usual caveat about my lack of familiarity with the deployed
> use of SCTP).

Can you be more specific about the TCP issue above?  If
I am not mistaken, the BGP graceful restart is because the
other side has restarted, maybe because of an app crash.
This is not about TCP getting out of sync, which I think is
what your idea of a TCP "reset" may be useful.  It is an
issue above the transport layer.  So I am not sure a
transport layer "reset" can help.

> Remember too that the SCTP association may have underlying state
> as part of security which may be expensive or time consuming
> to re-establish which would be unnecessary if all the problem is
> is with SSN/TSN, which is also part of the SCTP state.  (I think
> that implementation error is the most likely cause of getting knotted,
>   as I put it, not an attack, although the latter cannot be ruled out).

I am not aware of any special state which the SCTP stack
needs to keep.  Can you give some examples?  I agree that
TSN/SSN can get out of sync if there is a bug in the stack
or because of an attack.  But under these situations, it
is actually better to tear down the association.  Besides
the reason that the same problem can happen again, there
may already be data loss/corruption of the original
association.  It is better to notify the app that something
bad happens.

-- 

					K. Poon.
					[email-masked]

---

From: "t.petch" <[email-masked]>
Date: Mon, 4 Apr 2011 18:30:52 +0200

Kacheong

One last time; we are not communicating, I suspect because we have different
experiences and may be we will never have enough of them to
communicate.  You want 'why', protocol details, and to me they are an
irrelevance, I should not be trying to persuade you with them.  I see almost
everything deficient in the ability to perform partial resets which makes
the cost of a failure much higher than it need be so any additional such
function - eg in SCTP - is automatically a good thing; end of story.

My (frequent) experience is of two systems separated by a (wide area) network
(by definition erratic and unreliable even before malicious interventions
are taken into account), getting out of synch, with only way to
recover a full restart when much is lost that need not have been
had there been a partial restart, a reset or various flavours of reset.
So adding that to SCTP is obviously a good idea; end of story.

I am sure the Microsoft knew that a well designed and well implemented
system would not need partial resets; millions of users know better (blue
screens of death, power on resets anyone?) and so Windows has steadily gained
partial restarts, preserving the 'state' (eg database) that has been built
up over days or weeks of running (I suspect that application designers,
meanwhile,
have got an awful lot smarter at checkpointing and restarting).

My experience is that (almost) every piece of software, (almost)
every protocol could be improved by more partial restarts, resets.
When I am a user of a system and it hangs, and I ring the help desk
it is usually
'have you rebooted the system?'
'no, that would cost me at least half an hour's work to reinstate where I am'
'you must reboot before we investigate further'
'sigh'

You look at protocols I have pointed you to and you do not understand.
Perhaps RFC3478 is the easiest. It concerns an MPLS router and
routers can work or fail.  Wrong, they can part work and part fail.  This
RFC addresses the case where the router is forwarding millions of pps
at light speed using a FIB built up over days or weeks.Then something
goes wrong with the signalling such that LDP no longer works and so needs
restarting so that the FIB can go on being updated.  Why? an irrelevance
 - could be a bug in the SNMP code, could be an obscure never thought
 of race condition, ... - all irrelevant.  The important thing is to preserve
the forwarding while restarting the LDP part.

I expect there are or will be comparable applications with SCTP, one
part slowly building up an 'operational database' that another
part uses.  If an application designer chose a single association
for both parts, well they might soon learn to use separate associations
so that a lock up on the former does require destruction of the latter.
Adding a partial reset to SCTP would stop that hassle.  Good idea;
end of story.

Of course, when a system locks up repeatedly, as happened for
me as a user in the early hours of each Thursday morning in
February, then the help desk, or the support behind them,
notices, investigates and puts in a cure or prevention.  In the
meantime, the partial resets that on that occasion were
available saved me and others work.  What was the problem?
I am curious but ultimately, I don't know, don't care, cannot
afford to make it my responsibility; end of story.

Tom Petch