|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Unsolicited Data.Hello, All that is said below is ok but I cannot understand one thing here ----- why would initiator choose not to send unsolicited immediate data when it has negotiated for IntialR2T= Yes?? Sanjeev ----- Original Message ----- From: "Ayman Ghanem" <aghanem@cisco.com> To: <ips@ece.cmu.edu> Sent: Wednesday, June 06, 2001 6:48 PM Subject: RE: Unsolicited Data. > That section was modified. Julian posted the revised text here: > > http://ips.pdl.cs.cmu.edu/mail/msg04647.html > > -Ayman > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > Sent: Wednesday, June 06, 2001 9:36 AM > > To: 'ips@ece.cmu.edu' > > Subject: RE: Unsolicited Data. > > > > > > > > The current spec states that the F bit is "set to 1 when the > > immediate data > > that accompany the command are all the data associated with this > > command. It > > is an error if the Length and Expected Length do not match and this bit is > > set to 1". > > > > I interpret this as there is no more data to follow and not that the > > initiator has opted not to use the unsolicited data feature. > > Therefore the > > spec needs to be modified to indicate that if unsolicited data has been > > negotiated (i.e. InitialR2T=no), then the initiator MUST send unsolicited > > data of length = min( FirstBurstSize, ExpectedTransferLength ) minus any > > immediate data sent). > > > > Matthew Burbridge > > NIS-Bristol > > Hewlett Packard > > Telnet: 312 7010 > > E-mail: matthewb@bri.hp.com > > > > > > -----Original Message----- > > From: Ayman Ghanem [mailto:aghanem@cisco.com] > > Sent: Tuesday, June 05, 2001 6:31 PM > > To: ips@ece.cmu.edu > > Subject: RE: Unsolicited Data. > > > > > > If the initiator decides not to send immediate or unsolicited data when it > > has negotiated to do so, then the initiator must set the F-bit in the > > command PDU. This prompts the target to send R2T. > > > > I still agree that the spec should indicate that the initiator > > MUST use the > > resources it has negotiated. If it has negotiated the option to send > > immediate data or unsolicited data then it should do that to the limits > > allowed. If it has negotiated a PDU length, it must not send data > > PDUs less > > than the negotiated limit except for last one. While most > > implementation may > > do that for performance reasons, I would prefer defining this in the spec. > > > > -Ayman > > > > > -----Original Message----- > > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > > Sent: Tuesday, June 05, 2001 11:58 AM > > > To: 'ips@ece.cmu.edu' > > > Subject: Unsolicited Data. > > > > > > > > > I'm not sure if this has been discussed before but it is causing some > > > confusion. The statement below implies that if immediate data has been > > > negotiated then the initiator MAY use it. > > > > > > "If ImmediateData is set to no and InitialR2T is set to no then the > > > initiator MUST NOT send unsolicited immediate data but MAY send one > > > unsolicited burst of Data-OUT PDUs." > > > > > > Therefore the target must wait for the initial burst of unsolicited data > > > before issuing the first R2T (if there is subsequent data). If the > > > initiator decides not to send it then the target must timeout and > > > issue the > > > R2T for the initial data. Can the spec be changed to state that if > > > unsolicited data has been negotiated, then the initiator MUST use it. > > > > > > Thanks > > > > > > Matthew Burbridge > > > NIS-Bristol > > > Hewlett Packard > > > Telnet: 312 7010 > > > E-mail: matthewb@bri.hp.com > > > > > > > > >
Home Last updated: Tue Sep 04 01:04:33 2001 6315 messages in chronological order |