|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: Marker IntervalsBarry, Sorry - even here an interval is not negotiated but it may create confusion. I've added a dependency (must appear together). The part in appending reads: 01 RFMarkInt Use: IO Who can send: Initiator and Target RFMarkInt=<number-from-1-to-65535>[,<number-from-1-to-65535>] This is a connection specific parameter. The receiver indicates the minimum to maximum interval (in 4-byte words) the receiver wants the markers. In case the receiver wants only a specific value, only a single value has to be specified. The sender selects a value within the minimum and maximum the receiver requires (or the only value the receiver requires) or indicates through the FMarker key=value its inability to set markers. The interval is measured from the end of a marker to the beginning of the next marker. For example, a value of 1024 means 1024 words (4096 bytes of "pure" payload between markers). Whenever FMarker and RFMarkInt are both sent they MUST appear on the same Login Request/Response. Default is 2048. "Barry Reinhold" <bbrtrebia@mediaone.net> on 11-09-2001 18:27:45 Please respond to "Barry Reinhold" <bbrtrebia@mediaone.net> To: Julian Satran/Haifa/IBM@IBMIL cc: "ISCSI" <ips@ece.cmu.edu> Subject: iSCSI: Marker Intervals Ok, If there is not a concept of a range how do I handle the syntax of RFMarkInt as defined in item 20 in appendix D. This syntax is given as: RFMarkInt=<number-from-1-to-65535>[,<number-from-1-to-65535] I have assumed an initiator could send something like: RFMarkInt=1,12 With the semantics being that the marker interval must be between 4 and 48 bytes. The documentation associated with item 20 indicates that I am supposed to take a value within this range or signal my inability, through FMarker=no, to support markers. This negotiation process is pretty open for disagreements on marker intervals. It would appear to me that one would be likely to start a negotiation process by sending FMarker then following it with RFMarkInt and SFMarkInt. The question still remains in my mind as to what behavior the spec. wants when RFMarkInt is not within the range supported by the sender. Options: 1. Terminate the login/connection with a code indicating the situation 2. Send another FMarker with FMarker=no or perhaps FMarker=receive BTW - If marker intervals are "large" the marker can easily point to a PDU that has been processed. In this case the receiver has to read to the next marker which may dump a lot of PDUs and probably leave the connection "stalled". There could be a lot of command PDUs in 8K bytes represented by the default of 2048. I would be interested in hearing from anyone (either on the reflector or in private) who wants to receive markers as to what intevals they think will be optimal/desired. >-----Original Message----- >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >Julian Satran >Sent: Saturday, September 08, 2001 4:58 AM >To: Barry Reinhold >Cc: ISCSI >Subject: Re: Marker negotiation > > > >Barry, > >I was not aware that we allow ranges - only individual values. The range >in the examples are there to indicate a possible range for the value and >for each key there is a selection rule (usually the lower or higher). > >Julo > >"Barry Reinhold" <bbrtrebia@mediaone.net> on 06-09-2001 19:43:54 > >Please respond to "Barry Reinhold" <bbrtrebia@mediaone.net> > >To: Julian Satran/Haifa/IBM@IBMIL >cc: "ISCSI" <ips@ece.cmu.edu> >Subject: Marker negotiation > > > >Julain, > If doing a numerical negotiation - such as for marker intervals - if a >range is offered that is not liked what is the responder expected to do? >Numerical negotiations don't allow for selection of values out of range. > >Example: > >I -> FMarker=send-receive >T -> FMarker=send-receive >I -> RFMarkint=1,12 >T -> doesn't want anything below 1024. What does he do? > >Barry Reinhold >Principal Architect >Trebia Networks >barry.reinhold@trebia.com >603-868-5144/603-659-0885/978-929-0830 x138 > > > >
Home Last updated: Wed Sep 12 19:17:08 2001 6527 messages in chronological order |