Return-Path: <owner-ips@ece.cmu.edu>
X-Sieve: cmu-sieve 2.0
Return-Path: <owner-ips@ece.cmu.edu>
Received: (from majordom@localhost)
	by ece.cmu.edu (8.11.0/8.10.2) id h0H2kVA17175
	for ips-outgoing; Thu, 16 Jan 2003 21:46:31 -0500 (EST)
X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f
Received: from mail.ivivity.com ([64.238.111.99])
	by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h0H2kRW17170
	for <ips@ece.cmu.edu>; Thu, 16 Jan 2003 21:46:27 -0500 (EST)
Received: by ATLOPS with Internet Mail Service (5.5.2653.19)
	id <Y12VH4RM>; Thu, 16 Jan 2003 21:46:15 -0500
Message-ID: <AEC4671C8179D61194DE0002B328BDD20B98@ATLOPS>
From: Eddy Quicksall <eddy_quicksall@ivivity.com>
To: Carlos Rimola <crimola@silverbacksystems.com>, ips@ece.cmu.edu
Subject: RE: iSCSI: using the C bit
Date: Thu, 16 Jan 2003 21:46:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2BDD2.9A020280"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2BDD2.9A020280
Content-Type: text/plain;
	charset="iso-8859-1"

Ahh, thanks ... I missed that.
 
Eddy

-----Original Message-----
From: Carlos Rimola [mailto:crimola@silverbacksystems.com]
Sent: Thursday, January 16, 2003 8:36 PM
To: Eddy Quicksall; ips@ece.cmu.edu
Subject: Re: iSCSI: using the C bit


At 06:24 PM 1/16/2003 -0500, Eddy Quicksall wrote:


I want to be sure I understand the use of the C bit in a login. It seems to
me that the initiator could split a key into two parts: 1st part at the end
of request A and 2nd part at the beginning of request A+1.
 
e.g., the end of request A (with C bit set) could be "Immediate" and the
beginning of request A+1 could be "Data=yes" (the full key=value pair being
"ImmediateData=yes").
 
If this is done, the target will not process the partial key and may send
his own key saying "ImmediateData=no". But, the initiator has already
constructed the negotiation and request A+1 would violate the protocol
because ImmediateData has already been negotiated.
 
Comments?
 
Eddy


Eddy,

This scenario - the target sending his own key while the Initiator is still
sending partial chunks (by setting C Bit = 1) would be a violation of the
rule specified in 5.2 (Text Mode Negotiation) which applies during Login as
well as Text Req/Resp:

A target receiving a Text or Login Request with the C bit set to 1
MUST answer with a Text or Login Response with no data segment
(DataSegmentLength 0). An initiator receiving a Text or Login
Response with the C bit set to 1 MUST answer with a Text or Login
Request with no data segment (DataSegmentLength 0).


The target can begin sending its own keys only when a PDU with the C Bit set
to 0 arrives.  At this point, all keys will be complete and the above
condition is avoided.

Regards,

Carlos Rimola
Silverback Systems 



------_=_NextPart_001_01C2BDD2.9A020280
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2800.1126" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=814414502-17012003><FONT face=Arial color=#0000ff size=2>Ahh, 
thanks ... I missed that.</FONT></SPAN></DIV>
<DIV><SPAN class=814414502-17012003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=814414502-17012003><FONT face=Arial color=#0000ff 
size=2>Eddy</FONT></SPAN></DIV>
<BLOCKQUOTE>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Carlos Rimola 
  [mailto:crimola@silverbacksystems.com]<BR><B>Sent:</B> Thursday, January 16, 
  2003 8:36 PM<BR><B>To:</B> Eddy Quicksall; ips@ece.cmu.edu<BR><B>Subject:</B> 
  Re: iSCSI: using the C bit<BR><BR></FONT></DIV>At 06:24 PM 1/16/2003 -0500, 
  Eddy Quicksall wrote:<BR>
  <BLOCKQUOTE class=cite cite="" type="cite">I want to be sure I understand 
    the use of the C bit in a login. It seems to<BR>me that the initiator could 
    split a key into two parts: 1st part at the end<BR>of request A and 2nd part 
    at the beginning of request A+1.<BR>&nbsp;<BR>e.g., the end of request A 
    (with C bit set) could be "Immediate" and the<BR>beginning of request A+1 
    could be "Data=yes" (the full key=value pair 
    being<BR>"ImmediateData=yes").<BR>&nbsp;<BR>If this is done, the target will 
    not process the partial key and may send<BR>his own key saying 
    "ImmediateData=no". But, the initiator has already<BR>constructed the 
    negotiation and request A+1 would violate the protocol<BR>because 
    ImmediateData has already been 
    negotiated.<BR>&nbsp;<BR>Comments?<BR>&nbsp;<BR>Eddy</BLOCKQUOTE><BR>Eddy,<BR><BR>This 
  scenario - the target sending his own key while the Initiator is still sending 
  partial chunks (by setting C Bit = 1) would be a violation of the rule 
  specified in 5.2 (Text Mode Negotiation) which applies during Login as well as 
  Text Req/Resp:<BR><BR><FONT face="Courier, Courier">A target receiving a Text 
  or Login Request with the C bit set to 1<BR>MUST answer with a Text or Login 
  Response with no data segment<BR>(DataSegmentLength 0). An initiator receiving 
  a Text or Login<BR>Response with the C bit set to 1 MUST answer with a Text or 
  Login<BR>Request with no data segment (DataSegmentLength 
  0).<BR><BR><BR></FONT>The target can begin sending its own keys only when a 
  PDU with the C Bit set to 0 arrives.&nbsp; At this point, all keys will be 
  complete and the above condition is avoided.<BR><BR>Regards,<BR><BR>Carlos 
  Rimola<BR>Silverback Systems <BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C2BDD2.9A020280--