Re: [storm] iSER draft

[Michael Ko <[e-mail]>]

In RFC 5046, we specifically created the term RDMA-Capable Protocol (RCaP) to refer to protocol stacks that provide the RDMA functionality.  We pointed to iWARP and Infiniband as examples of RCaP in the RFC, and recently RoCE (RDMA over Converged Ethernet) can also be added to the list.  The ideal situation is for iSER implementations to be usable in any RCaP.  This minimizes the development effort for iSER and facilitates the acceptance of iSER.  Bob Russell suggested back in 3/22/2009 to incorporate the use of Virtual Address as this would allow implementations such as the OFED stack to be used for different RCaPs.  The initial iSER draft (draft-ietf-storm-iser-01) submitted to STORM reflected this change request.  Alex suggested further clarfiying the use of Virtual Address to clear up the ambiguity in the -01 version.

Mike
  ----- Original Message ----- 
  From: Caitlin Bestler 
  To: Michael Ko 
  Cc: Tom Talpey ; Alexander Nezhinsky ; [e-mail] 
  Sent: Wednesday, June 29, 2011 8:34 PM
  Subject: Re: [storm] iSER draft


  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
  >