Jilien, thanks for respondin. Inline ... On Mon, July 20, 2009 12:03 pm, Julien Laganier wrote: > Hello, > > On Mon, Jul 20, 2009 at 11:00 AM, Mike Eisler<mre-ietf at eisler.com> wrote: >> >> On Sun, July 12, 2009 11:54 am, Michael Richardson wrote: >>> -----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. >> >> My point was that because SCTP gets around connection drops, and TCP >> doesn't, the issue is specific to TCP. Apps that use TCP are used >> to TCP dropping connections. Apps that use SCTP are not used a total >> failure because of the "get around" behavior of SCTP. >> >>> (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. >> >> Note that above is the content of the IESG DISCUSS from Russ. >> >>> >>> I agree that this is the case for SCTP. >>> For TCP, it looks like a normal network failure, do you agree? >> >> I agree. Hence the DISCUSS looks specific to SCTP to me. > > I think that's indeed the case. > >>> 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. >> >> Fair enough. So given that, perhaps connection latching for SCTP >> should be deferred to another work item? > > IIRC, as a result from requesting publication we were asked (during > IETF LC, maybe as a TSV directorate review) to cover SCTP and not only > TCP and UDP. So while we maybe didn't considered all the implications > of specifying SCTP behavior, it is my understanding that not covering > it is not an option on the table. OK. So how about text (specific places to add this and wording, pending if/when we have consensus) that says: For UDP and TCP, the implementation SHOULD provide an unambiguous indication that the connection drop was due to "unlatching" the connection. For SCTP, the implementation MUST provide an unambiguous indication that the connection drop was due to "unlatching" the connection. Rationale: SCTP is a transport that is "multi-homed"; connection drops should thus be rare, and applications using SCTP will be better able to cope with a drop across all end-points with an unambiguous error indicating an unlatch. (Obviously, I am not sure if the verb to "unlatch" is the correct term here). [My responses on this threa dhave been tardy due to holiday and getting reading to go to Stockholm ... and will be boarding the plane for Stockholm in about an hour]. > > --julien > _______________________________________________ > btns mailing list > btns at ietf.org > https://www.ietf.org/mailman/listinfo/btns > -- Mike Eisler, Senior Technical Director, NetApp, 719 599 9026, http://blogs.netapp.com/eislers_nfs_blog/
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.