Re: [storm] iSER draft

Caitlin Bestler <cait@asomi.com> Thu, 30 June 2011 03:34 UTC

Return-Path: <cait@asomi.com>
X-Original-To: storm@ietfa.amsl.com
Delivered-To: storm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E2B21F8635 for <storm@ietfa.amsl.com>; Wed, 29 Jun 2011 20:34:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppl0g6Mw3Y4I for <storm@ietfa.amsl.com>; Wed, 29 Jun 2011 20:34:55 -0700 (PDT)
Received: from p3plsmtpa01-08.prod.phx3.secureserver.net (p3plsmtpa01-08.prod.phx3.secureserver.net [72.167.82.88]) by ietfa.amsl.com (Postfix) with SMTP id 306BE21F862A for <storm@ietf.org>; Wed, 29 Jun 2011 20:34:55 -0700 (PDT)
Received: (qmail 30008 invoked from network); 30 Jun 2011 03:34:54 -0000
Received: from unknown (108.80.57.164) by p3plsmtpa01-08.prod.phx3.secureserver.net (72.167.82.88) with ESMTP; 30 Jun 2011 03:34:54 -0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Caitlin Bestler <cait@asomi.com>
X-Priority: 3
In-Reply-To: <971779FD6B314A40B1A3658E521C0D4A@china.huawei.com>
Date: Wed, 29 Jun 2011 20:34:52 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <707F30B0-06DD-4F1A-BBCB-229E9D3794AA@asomi.com>
References: <BANLkTi=GVHUBdsZiwsRXxETd_rU=F8f85w@mail.gmail.com> <F83812DF4B59B9499C1BC978336D91745EDE207F@TK5EX14MBXC118.redmond.corp.microsoft.com> <971779FD6B314A40B1A3658E521C0D4A@china.huawei.com>
To: Michael Ko <Michael@huaweisymantec.com>
X-Mailer: Apple Mail (2.1084)
Cc: storm@ietf.org
Subject: Re: [storm] iSER draft
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 30 Jun 2011 03:34:56 -0000

Let me deliberately mis-paraphrase your rationale here:

	We only need a three-tuple to specify an advertised buffer, but the IETF should define it to be a four-tuple
	in order to make it easier for some host implementations to share code with a non-IETF transport.

That's not much of a rationale for making an IETF protocol more complex than it has to be.

Could you at least be explicit and provide a neutral explanation as to why having a VA *and* a TO could make
a certain class of implementations easier? Something better than "InfiniBand did it that way?"



On Jun 29, 2011, at 2:26 PM, Michael Ko wrote:

> Tom,
>  
> As originally written, the iSER spec always assumes ZBVA (zero-based virtual address).  But when iSER is used in conjunction with transports other than iWARP, there is a need to include the virtual address for the tagged buffer.  Such is the case for Infiniband.  Accordingly, the Virtual Address field has been added to the iSCSI Control Type PDUs (sec. 9.2).  Alex pointed out that the tagged buffer should now be identified by the 4-tuple (STag, VA, TO, and length) instead.  This should be updated everywhere where the term "tagged buffer" is mentioned in the spec.  For example, in sec. 1.1 under Advertisement, the sentence "A typical method would be for the iSER Layer to embed the Tagged Buffer's STag, TO, and buffer length in a Send Message destined for the remote iSER Layer" should be modified to "A typical method would be for the iSER Layer to embed the Tagged Buffer's STag, VA, TO, and buffer length in a Send Message destined for the remote iSER Layer."  BTW, this sentence also answers your question as to whether VA is passed on the wire.
>  
> The Virtual Address is literally the virtual address of the tagged buffer.  The tagged offset is the displacement relative to the beginning of the buffer starting at the virtual address.
>  
> We could rephrase the definition of Virtual Address in sec. 1.1 as follows:
>  
> "Virtual Address (VA) - This is the virtual address of the Tagged Buffer on a Node.  When set to 0, it indicates that a virtual address is not needed to locate the Tagged Buffer."
>  
> Mike
>