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

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

>>>>> "Mike" == Mike Eisler <mre-ietf at eisler.com> writes:

    Mike> So how about text (specific places to add this and wording,
    Mike> pending if/when we have consensus) that says:

    Mike> For UDP and TCP, the implementation SHOULD provide an
    Mike> unambiguous indication that the connection drop was due to
    Mike> "unlatching" the connection.

    Mike> For SCTP, the implementation MUST provide an unambiguous
    Mike> indication that the connection drop was due to "unlatching"
    Mike> the connection. Rationale: SCTP is a transport that is
    Mike> "multi-homed"; connection drops should thus be rare, and
    Mike> applications using SCTP will be better able to cope with a
    Mike> drop across all end-points with an unambiguous error
    Mike> indicating an unlatch.

  So, if my stack said EUNLATCHED instead of ETIMEOUT, you'd be happy?

  (Of course, if you unplug all the "cables" to any ULP, and there is some
kind of make-dead process in the ULP, then you get ETIMEOUT eventually,
regardless of any wizardry that SCTP provides...)

-- 
]     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");  [