Subject: RE: [rddp] Adaption Indication for TCP - unfortunate choice of ex pression...

From: "Larsen, Roy K" <[email-masked]>
Date: Tue, 10 Dec 2002 17:07:47 -0800

I would like to take back my unfortunate choice of expression on the
worthiness of topics.  It was in no way targeted at any individuals.  My
frustration on MPA in general leaked out and I wished it hadn't.

Again, my apologies.

Roy

> -----Original Message-----
> From: Larsen, Roy K [mailto:[email-masked]]
> Sent: Tuesday, December 10, 2002 1:37 PM
> To: [email-masked]'; [email-masked]
> Subject: RE: [rddp] Adaption Indication for TCP
> 
> 
> Pat,
> 
> You've described end-to-end protocols where both sides have a mutual
> understanding of the semantics of a negotiation.  I have absolutely no
> argument with this approach.  In fact, I believe a formal 
> adaptation-like
> end-to-end protocol for MPA could resolve a lot of issues 
> that have been
> raised such as marker negotiation, graceful transition from 
> streaming to
> framing formats, etc.
> 
> However, this thread was not referring to such mutual 
> understanding.  The
> approaches I read suggested that when one side closes due to 
> confusion that
> the connection is retried on the same port in a different 
> dialect.  This
> strikes me as rather amateurish and unworthy of an IETF form.
> 
> Again, I was asking if anyone can provide any concrete 
> example where an
> application does not deterministically know what dialect the 
> target endpoint
> will be speaking.  If there are no precedents, why would we 
> try to solve a
> problem that doesn't exist? 
> 
> Roy 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, December 10, 2002 1:10 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [rddp] Adaption Indication for TCP
> 
> 
> Roy,
> 
> Some ULPs start a connection with a negotiation where they 
> agree on how they
> will operate. For such ULPs, an RDMA capable instance of the 
> ULP (that is
> one that knows how to run on top of RDMA) may initially 
> connect to a peer
> with RDMA turned off. During the negotiation, it can ask the 
> peer to operate
> over RDMA and if the peer agrees they can both transition 
> into operation
> over RDMA. These mechanisms can allow for the offer of a new 
> capability and
> graceful continued operation if the peer does not understand 
> the offer. 
> 
> For instance, iSCSI has an operational negotiation phase 
> before it enters
> full feature phase. RDMA could be negotiated during that 
> phase and then the
> transition could occur if both agreed. The iSCSI negotiation 
> was already
> constructed to deal gracefully with receiving an offer of a 
> parameter name
> that the peer doesn't understand. The peer responds to that 
> parameter with
> NotUnderstood - so the RDMA capable peer will know that its 
> offer was not
> accepted and it can continue to negotiate non-RDMA operation.
> 
> Some other ULPs use fixed format messages for negotiation in 
> which case a
> reserved bit could be set to request RDMA operation. If the 
> peer doesn't
> support RDMA, it would ignore the reserved bit and return it 
> with a zero
> value. 
> 
> I don't think "dynamically switch transfer methods" applies 
> to this. It is a
> single switch at a defined time agreed upon time with a 
> specified sequence
> of events. "Dynamically" implies switching while in full operation and
> perhaps the capability of going back and forth which is much harder.
> 
> For ULPs that support a negotiation phase, this seems better 
> then creating a
> new set of well known port names and it means that existing discovery
> mechanisms don't need to be modified.
> 
> Pat
>  
> 
> -----Original Message-----
> From: Larsen, Roy K [mailto:[email-masked]]
> Sent: Tuesday, December 10, 2002 9:32 AM
> To: [email-masked]
> Subject: RE: [rddp] Adaption Indication for TCP
> 
> 
> Since the use of DDP/RDMA will not be transparent from a ULP 
> perspective,
> I'm also confused as to the objective of this thread.  A ULP 
> must know,
> through well known ports or a port mapping service, how to 
> find the intended
> endpoint.  It seems logical to me that if a ULP supports two separate
> transfer methods, it will be know by two well known ports or 
> port mapping
> entries.
> 
> Can someone site examples of ULPs that dynamically switch 
> transfer methods
> over the same TCP port?
> 
> Roy
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, December 10, 2002 7:36 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [rddp] Adaption Indication for TCP
> 
> 
> > > That works, although I was thinking of something else to be done
> > > immediately on connection setup - exchange SCTP-like adaption
> > > indications meaning "I can do MPA" as the first bytes on the
> > > connection (details of formatting this are TBD) without 
> (necessarily)
> > > going into MPA mode at that point.  
> > 
> > I don't understand.  If the remote end implements a version 
> of the ULP
> > that has never heard of RDDP, 
> > won't the unrecognized first bytes that are supposed to mean
> > "I can do MPA" simply cause an error and trash
> > the connection?  This is not the desired behavior of falling back
> > to non-DDP flavor of the ULP.  Maybe I am missing something.
> 
> The MPA-enabled sender observes the connection closing and retries
> without the extra first bytes.  It's not the cleanest solution, but
> we're not exactly starting from a clean slate.
> 
> > > A confirming message as the first message to be received in
> > > MPA mode makes a lot of sense. Particularly if packing is
> > > allowed and therefore it does not automatically waste a
> > > distinct transmission.
> > 
> > I thought the objective was to avoid sending anything in 
> > MPA mode without some assurance the remote end
> > was willing and able, in which case the confirming message
> > comes too late.
> 
> That gets to about the same place.  In the failure case where
> the sender mistakenly believes that the receiver supports MPA,
> the result is that the first message in MPA mode should come out
> as gibberish on the far side, and when the sender fails to receive
> a confirming message, the connection probably has to be closed -
> it could be retried without going into MPA mode.  
> 
> > But I admit I am too vague on what the objective really
> > is.
> 
> There isn't a hard and fast objective - the originally expressed
> concern is that if sender and receiver don't agree on whether
> the bytestream is framed, the receiver may do some rather unintended
> things.  The above approaches help to address this by causing
> "fail fast" behavior - that's not as clean as the SCTP adaption
> indication solution (which fails immediately with a clear indication
> of why), but something in this area may be sufficient.  I can't
> say with absolute certainty what will be acceptable, but with
> my WG chair hat on, exploring these sorts of "fail fast" mechanisms
> appears to be productive.  Something to be looked at in the
> details here is how to increase the likelihood that the
> "I'm doing MPA" message really comes out as gibberish at a
> non-MPA receiver in a fashion that does not cause any bad
> ULP side effects.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953 **NEW**     FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> _______________________________________________
> rddp mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rddp
> _______________________________________________
> rddp mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rddp
> _______________________________________________
> rddp mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rddp
> 
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp