Re: [storm] iSER draft

Caitlin Bestler <cait@asomi.com> Thu, 14 July 2011 05:16 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 01F6321F8B27 for <storm@ietfa.amsl.com>; Wed, 13 Jul 2011 22:16:23 -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 DliB4KPjUGli for <storm@ietfa.amsl.com>; Wed, 13 Jul 2011 22:16:18 -0700 (PDT)
Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) by ietfa.amsl.com (Postfix) with SMTP id C31D821F8588 for <storm@ietf.org>; Wed, 13 Jul 2011 22:16:15 -0700 (PDT)
Received: (qmail 25498 invoked from network); 14 Jul 2011 04:49:34 -0000
Received: from unknown (108.80.57.164) by p3plsmtpa06-04.prod.phx3.secureserver.net (173.201.192.105) with ESMTP; 14 Jul 2011 04:49:34 -0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Caitlin Bestler <cait@asomi.com>
In-Reply-To: <F83812DF4B59B9499C1BC978336D91745EE0279D@TK5EX14MBXC111.redmond.corp.microsoft.com>
Date: Wed, 13 Jul 2011 21:49:32 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <B443B9D1-754C-4D74-B43A-858A6031850A@asomi.com>
References: <BANLkTi=GVHUBdsZiwsRXxETd_rU=F8f85w@mail.gmail.com> <F83812DF4B59B9499C1BC978336D91745EDE207F@TK5EX14MBXC118.redmond.corp.microsoft.com> <971779FD6B314A40B1A3658E521C0D4A@china.huawei.com> <BANLkTik0rG2=orD0S0L3s62gBSJsLapA+w@mail.gmail.com> <F83812DF4B59B9499C1BC978336D91745EE0279D@TK5EX14MBXC111.redmond.corp.microsoft.com>
To: Tom Talpey <ttalpey@microsoft.com>
X-Mailer: Apple Mail (2.1084)
Cc: "storm@ietf.org" <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, 14 Jul 2011 05:16:23 -0000

On Jul 13, 2011, at 8:12 AM, Tom Talpey wrote:

> Yes, understood on the ZBVA/Infiniband issue. Regarding the VA term’s presence in an earlier draft, I did not see it in RFC5046 and I did not review the expired draft, so consider these comments to be on the overall change, not the last revision.
>  
> Let me try a different approach to perhaps make myself clearer.
>  
> First, it seems to me that a “virtual address” has no real meaning to the network protocol. It begins, perhaps, as some value in an address space on the initiator, but it’s not meaningful on the target in this way, it’s only used to request that the remote RNIC perform a transfer to that originally registered remote address. So calling it a Virtual Address as an iSER protocol object seems, to me, an artificial and somewhat leading convention.
>  
> Second, the Virtual Address goes out from the initiator to the target in a Control PDU, but where does it come back? The RDMA Read or Write as depicted in (xx) shows only a Tagged Offset. So, it’s not clear what its protocol meaning is.
>  
> Third, I don’t ever see a Tagged Buffer described by a fully qualified four-tuple. I see it appearing as either { Stag, TO, length } or { Stag, VA, length }, depending on the addressing mode.
>  
> I think the non-ZBVA mode is really just a special case of the existing one, but where the meaning of TO has changed from a small offset to some other token, generated and managed only at the initiator. So, it seems artificial to define it as distinct, and document it as possessing some new properties. Isn’t it just a Target Offset, still?
>  
> Tom.
>  
>  

I agree, so far we have not seen a protocol justification for the need to add "Virtual Address" to the glossary as something distinct from Target Offset
for the purpose of defining an IETF protocol.

I am sympathetic to the interoperability issues raised, but I don't think those can justify something that has *no* justification in the protocol.

If someone could site a class of implementation where there is a real need for this distinction in an iSER adapter, but as far as I can see the adapters have
to be able to translate to TO *anyway* in order to use an RDMA Write or RDMA Read.

Local Interface compatibility with IB can make a *lot* of sense, but why does it have to make its way into the *wire* protocol?

--
Caitlin Bestler
cait@asomi.com
http://www.asomi.com/CaitlinBestlerResume.html