[storm] Updated iSER draft

Mike Ko <Michael@huaweisymantec.com> Fri, 04 December 2009 23:41 UTC

Return-Path: <Michael@huaweisymantec.com>
X-Original-To: storm@core3.amsl.com
Delivered-To: storm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379863A6A6E for <storm@core3.amsl.com>; Fri, 4 Dec 2009 15:41:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.106
X-Spam-Level: **
X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGLq+yphUoeq for <storm@core3.amsl.com>; Fri, 4 Dec 2009 15:41:36 -0800 (PST)
Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 4C0EF3A6A4A for <storm@ietf.org>; Fri, 4 Dec 2009 15:41:36 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KU5005I4J4S1E00@hstga01-in.huaweisymantec.com> for storm@ietf.org; Sat, 05 Dec 2009 07:41:17 +0800 (CST)
Received: from LENOVO6EA8F9DF ([68.65.79.146]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KU500ATEJ4RRG00@hstml02-in.huaweisymantec.com> for storm@ietf.org; Sat, 05 Dec 2009 07:41:16 +0800 (CST)
Message-id: <176FE63F6E624A398CCA995FBE562AFF@china.huawei.com>
From: Mike Ko <Michael@huaweisymantec.com>
To: storm@ietf.org
References: <4B0C76CF.8070905@ieee.org> <C2D311A6F086424F99E385949ECFEBCBCA8E5D@CORPUSMX80B.corp.emc.com> <E15870DC-3DFF-4B8F-82C2-18A5248E132D@gmail.com> <SNT131-ds11E5485BA6BABFE246D4EDA0960@phx.gbl> <AC32D7C72530234288643DD5F1435D53077CB9C0@RTPMVEXC1-PRD.hq.netapp.com>
Date: Fri, 04 Dec 2009 15:41:14 -0800
X-Priority: 3
X-MSMail-priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Subject: [storm] Updated iSER draft
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Dec 2009 23:41:37 -0000

I have just submitted an updated iSER draft to the storm WG.  The following 
are extracted from section 14 on "Summary of Changes from RFC 5046":

1. Removed the requirement that a connection be opened in "normal"     TCP 
mode and transitioned to zero-copy mode.  The allows the spec to conform to 
existing implementation for both Infiniband and iWARP.  Changes were made in 
sections 2, 3.1.6, 4.2, 5.1, 5.1.1, 5.1.2, 5.1.3, 10.1.3.4, and 11.

2. Added a clause in section 6.2 to clarify that the initiator must not send 
more than InitiatorMaxRecvDataSegmentLength worth of data when a NOP-Out 
request is sent with a valid Initiator Task Tag.  Since 
InitiatorMaxRecvDataSegmentLength can be smaller than 
TargetMaxRecvDataSegmentLength, returning the original data in the NOP-Out 
request in this situation can overflow the receive buffer unless the length 
of the data sent with the NOP-Out request is less than 
InitiatorMaxRecvDataSegmentLength.

3. Added MaxAHSLength key in section 6.8 to set a limit on the AHS Length as 
proposed by Alex Nezhinsky.  This is useful when posting receive buffers in 
knowing what the maximum possible message length is in a PDU which contains 
AHS.

4. Added WriteAddressForSolicitedDataOnly key in section 6.9 to indicate how 
the memory region will be used as proposed by Alex Nezhinsky.  Alex argued 
that WSTAG (RKEY+VA for Infiniband) sent by the initiator with a WRITE SCSI 
command already accounts for the offset associated with the solicited data, 
and does not reference the entire data.  The rationale is that the initiator 
sometimes treats the memory regions intended for unsolicited and solicited 
data differently, as they are carried out using different Infiniband 
mechanisms (Send from the initiator, RDMA from the target) that imply 
different registration modes.  In contrast, the model implied by the iSER 
spec creators was that the memory occupied by data is treated as contiguous 
(or virtually contiguous, by means of scatter-gather mechanisms) and 
homogenous region.  Adding a new key will allow coping with current 
implementations.

 5. Added two 64-bit fields in iSER header in section 9.2 for the Read 
Virtual Address and the Write Virtual Address to conform to the Infiniband 
format as proposed by Bob Russell.  This allows one implementation such as 
the OFED stack to be used in both the Infiniband and the iWARP environment.

Proposed Changes To Be Considered

6. Alex Nezhinsky stated that iSER Hello and iSER HelloReply messages are 
not implemented in practice.  He argued that we should update the spec to 
remove the requirement to exchange the iSER Hello and iSER HelloReply 
messages.

Changes To Be Done

Update all diagrams to conform with the expanded iSER header format.

Mike