Re: [btns] Q: How to deal with connection latch breaks?

[Michael Richardson <mcr at sandelman.ottawa.on.ca>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Mike" == Mike Eisler <mre-ietf at eisler.com> writes:
    >> The last DISCUSS on draft-ietf-btns-connection-latching-10
    >> concerns what the WG thinks is the best way for ULPs to handle
    >> connection latch transitions to the BROKEN state in the _absence_
    >> of connection latching APIs for applications (or when apps are
    >> not aware of such APIs).

    Mike> Isn't this DISCUSS specific to SCTP? 

  I don't think so. 
  I think it's just that SCTP tries to get around other network
connection failures by switching to working end-points, while TCP and
UDP do not, so those applications are already more suspectible to
network failures.

  (First, if you are using channel binding, then you have to be aware of
it, so it is possible that we haven't thought through the non-channel
binding case well enough)

    Mike> I am unsure that the SCTP section defines behavior which is
    Mike> consistent with application expectations.  The last paragraph
    Mike> of 5.4 implies that the whole connection terminates if one of
    Mike> the latches breaks.  This has an impact on the semantics of
    Mike> the application socket API.  While connection latching is
    Mike> transparent when everything is working, there are new failures
    Mike> that ripple to the application.  That is, the application will
    Mike> observe different behavior on a connection with and without
    Mike> latching.

  I agree that this is the case for SCTP.
  For TCP, it looks like a normal network failure, do you agree?

  I think that how the latch breaks when the SA breaks depends upon
whether there are in fact multiple SAs, (the simple NxM approach), or if
the connection latch object is represented as a the N+M object, with
underlying SAs negotiated as needed.

    Mike> Perhaps the second approach is what should be used for
    Mike> SCTP. However, as the last sentence above notes, the first
    Mike> approach is used in the rest of the document. I gather what
    Mike> Russ is saying is that approach might not be appropriate for
    Mike> SCTP and he wants to know if the WG thoroughly considered it.

  I think that we did not consider it enough.

    Nico> a) The ULP MAY/SHOULD/MUST pretend that the equivalent of a
    Nico> TCP reset occurred and the connection latch is transition to
    Nico> the CLOSED state (and destroyed/cleaned up);

    Nico> b) The ULP MAY/SHOULD/MUST act as though bits aren't moving
    Nico> and let ULP and/or application-layer timeout processing decide
    Nico> if and when to close the connection (and underlying connection
    Nico> latch).

    Nico> (b) means potentially hanging forever, but that's generally
    Nico> true now with existing ULPs.

    Nico> The I-D says (b), with "SHOULD".

    Nico> I'd be just as happy with (a), SHOULD, (b) MAY.  I would not
    Nico> be happy with (a), MUST, nor with (b), MUST.

    Nico> Comments?

  Tell me why the connection latch broke?

  I do not like layers that kill connections unlaterally because *they*
think they know what my application's timeout is.  

- -- 
]     Y'avait une poule de jammé dans l'muffler!!!!!!!!!        |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
]    h("Just another Debian GNU/Linux using, kernel hacking,    ruby  guy");  [

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBSloxWICLcPvd0N1lAQJ85Qf+MyRCh4x7Rt/EDvqh4haa2jaVqGnadnOA
I3K2CbROKibly3QgRa6wN51nKWuPWyFcs1/dk8PzjRa6L/wnSL505cFTu30tVJ2j
89B1ykdodfXfTmyxR3j0rMysP13dHaiL+CizZiu/B9w/chhExYSuE/Jyw7SHy0uH
jbBJV2lXHRgD8dWYQ1qey+fLmjwp/HhVtZm4+epMhlsECsFIGmZktkiW9UjeTakh
6rXJmmaF7lNAzq4eGJTKjNSQQSy+bq+b1UOR0sYJguNC0W8yH5xX/g3/lBLPxVH9
yb+3X+6dUsW8zRXgJ9w7gSAhbJ0FvN7VxInZ9vzCkt97eLk7I37QnA==
=Y4Mx
-----END PGP SIGNATURE-----