|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: R2TDataSN and other recovery mechanismsNo I am proposing we use markers. Julo "Somesh Gupta" <someshg@yahoo.com> on 08/03/2001 05:10:24 Please respond to someshg@yahoo.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: R2TDataSN and other recovery mechanisms Well it does seem that you are proposing that the processing machine go into a "speculative" mode where the processing of the next PDU determines whether we were successfuly able to skip a bad PDU header? I think it is time to start another seperate thread on requirement for more details and rigorous/perhaps formal description of various recovery tools that we have and determine how to use them, and identify any possible holes in them. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > julian_satran@il.ibm.com > Sent: Wednesday, March 07, 2001 5:21 AM > To: ips@ece.cmu.edu > Subject: RE: R2TDataSN and other recovery mechanisms > > > > > Somesh, > > OK - so what? You will get another digest error (if choose a good digest > -:)) and look for the next marker. > > Regards, > Julo > > "Somesh Gupta" <someshg@yahoo.com> on 07/03/2001 04:09:31 > > Please respond to someshg@yahoo.com > > To: Julian Satran/Haifa/IBM@IBMIL, someshg@yahoo.com > cc: > Subject: RE: R2TDataSN and other recovery mechanisms > > > > > Julian, > > The point was not about whether the markers were covered > by digests. The point is about the fact that errors > occured in that range on the TCP stream that were > caught (header digest error) - it does seem likely that > the marker might have an error too? > > Somesh > > > -----Original Message----- > > From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com] > > Sent: Tuesday, March 06, 2001 3:52 PM > > To: someshg@yahoo.com > > Subject: RE: R2TDataSN and other recovery mechanisms > > > > > > > > > > Markers are not covered by digests (they are not supposed to be seen at > > digest formation. > > The layer model appears in the draft. > > > > Regards, > > Julo > > > > "Somesh Gupta" <someshg@yahoo.com> on 06/03/2001 20:20:56 > > > > Please respond to someshg@yahoo.com > > > > To: "Venkat Rangan" <venkat@rhapsodynetworks.com>, someshg@yahoo.com, > > Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > > cc: > > Subject: RE: R2TDataSN and other recovery mechanisms > > > > > > > > > > Venkat, > > > > You are right but this does put some additional requirements > > on the sync and steering layer (assuming we can agree on one > > and that it is not optional). > > > > Consider the marker mechanism as an example. If the marker > > falls within the TCP byte stream region which contains the > > header, and the header digest fails, then do you trust this > > marker or skip to the next marker. Or do we need a sum on the > > marker itself. > > > > We do have various recovery mechanisms in the protocol without > > detailed state machines or other documentation to make sure > > that the mechanisms are really robust and worth including. And > > even more important, that we will have interoperable > > implementations that are implemented to the standard (rather > > than being compliant with some defacto implementation) > > > > I am not saying that these tools do not work, and Julian > > (and other smart people)may even have worked them out. > > However, the proof is not in the document. > > > > Thanks, > > Somesh > > > > > -----Original Message----- > > > From: Venkat Rangan [mailto:venkat@rhapsodynetworks.com] > > > Sent: Tuesday, March 06, 2001 10:00 AM > > > To: someshg@yahoo.com; julian_satran@il.ibm.com; ips@ece.cmu.edu > > > Subject: RE: R2TDataSN > > > > > > > > > Somesh, > > > > > > > When there is a data digest error, further stream parsing is > > > > deterministic. But not when the PDU header digest error. > > > > > > Isn't it true that with Synch and Steering layer, you are able to > > > skip past > > > PDUs with header-digest errors and reach a point where you can begin > > > deterministically processing the stream? (assuming that the > > > headers used for > > > Synch and Steering are in-tact). > > > > > > Of course, in the event that this option is "negotiated out" you > > > don't have > > > this ability. > > > > > > Venkat Rangan > > > Rhapsody Networks Inc. > > > http://www.rhapsodynetworks.com > > > > > > -----Original Message----- > > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > > Somesh Gupta > > > Sent: Tuesday, March 06, 2001 7:23 AM > > > To: julian_satran@il.ibm.com; ips@ece.cmu.edu > > > Subject: RE: R2TDataSN > > > > > > > > > I beg to disagree. If an R2T PDU (header) has bad digest, or any other > > > header has a bad digest - since you always need the PDU length from > > > the header, there is some uncertainty associated with further > > processing. > > > > > > Are you proposing that the processing machine go into a "speculative" > > > mode where the processing of the next PDU determines whether we were > > > successfuly able to skip a bad PDU header? When there is a data digest > > > error, further stream parsing is deterministic. But not when the PDU > > > header digest error. > > > > > > Also the consensus (in my interpretation) was on applications > > > not transfering very large amounts of data using a single command or > > > read/write PDU. > > > > > > > -----Original Message----- > > > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf > Of > > > > julian_satran@il.ibm.com > > > > Sent: Monday, March 05, 2001 5:41 PM > > > > To: ips@ece.cmu.edu > > > > Subject: Re: R2TDataSN > > > > > > > > > > > > > > > > > > > > Somesh, > > > > > > > > 1.The only consensus I heard is not to transfer a large amount of > > > > data with > > > > one PDU. > > > > > > > > 2.With DatasN and Sack we dont need any data in a bad header. > > > > > > > > 3. If an R2T is lost (received at initiator with bad digest) - the > > > > initiator will know that from > > > > the next R2T if the target has several outstanding - very likely at > > long > > > > distances - and will not have to way for a timeout. Other uses are > > > > marginal. Basically it is "part of a command execution" and we can > > > > painless recover > > > > from failures for this case too. > > > > > > > > Regards, > > > > Julo > > > > > > > > "Somesh Gupta" <someshg@yahoo.com> on 05/03/2001 20:40:06 > > > > > > > > Please respond to someshg@yahoo.com > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > > > > cc: > > > > Subject: R2TDataSN > > > > > > > > > > > > > > > > > > > > > R2TDataSN > > > > > ---------- > > > > > Sec 6.7.1 has some new content on how to handle lost R2Ts using > > > > > SACKs. But I noticed that the SACK request (Sec 2.16) has not > > > > > changed to indicate whether the DataSN is a R2T DataSN or just > > > > > a Read PDU DataSN (D bit) > > > > > So do we demux on the read/write operation type? > > > > > And how does this affect PDU loss in bidirectional commands ? > > > > > +++ SACK is ascking for data (DataSN) the target knows > > > > > > > > > > > > > Julian, > > > > > > > > Regarding the R2TDataSN, I have a comments and a > > > > question. > > > > > > > > I think that when a PDU header fails a CRC/checksum check etc, > > > > it is a problem to depend on any information in the header > (including > > > > length fields), thereby making any further processing on > > > > the connection unreliable. > > > > > > > > What scenarios do you envision where the R2TDataSN is useful. > > > > IN Orlando I think there was clear consensus that application > > > > do not try to transfer very large amounts of data using a > > > > single command. > > > > > > > > Thanks, > > > > Somesh > > > > > > > > _________________________________________________________ > > > > Do You Yahoo!? > > > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > > > > > > > > > > > > _________________________________________________________ > > > Do You Yahoo!? > > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Home Last updated: Tue Sep 04 01:05:25 2001 6315 messages in chronological order |