[openib-general] RMPP Requirements

[Hal Rosenstock]

Sean Hefty wrote:
> On Wed, 04 Aug 2004 14:12:14 -0400
> Hal Rosenstock <halr at voltaire.com> wrote:
> 
>> Sean Hefty wrote:
>>> * The access layer needs to know if the RMPP header is in a MAD or
>>> not.  I think that this can be determined by the management class.
>> 
>> Not sure what you mean by "determined by the management class".
>> I think it is at a minimum class and method (at least for SA today).
> 
> 13.6.2.1. If a management class uses RMPP, it shall include the RMPP
> header...in every MAD of that class type. 

Yes, you're right. There is some other non compliance text indicating
that RMPP is on a class, version, attribute basis. This is related to 
whether the RMPP active flag is on or off. That was what confused me.

>>> * It needs to know the offset of the RMPP header into the MAD.  This
>>> seems fixed for currently defined classes.
>> 
>> It is fixed for all classes using RMPP. Not sure what you mean by
>> currently defined classes.
> 
> I was referring to vendor-defined classes, versus classes defined in
> the spec. 

OK. 

>>> * The access layer needs to know what version of RMPP is being used.
>>> This is given in the RMPP header, which would work, provided that
>>> the header doesn't change.
>> 
>> I don't think the position of the version in the header can change
>> without the
>> base version changing. That's not likely any time soon :-)
> 
> Didn't they change the MAD header from 1.0 to 1.1 without changing
> the version?  Hmm... maybe we can't even trust the version number
> then...  

SA class version changed from 1 to 2 between 1.0a and 1.1. In 1.0a
RMPP was limited to SA class. The version numbers can be trusted.

>>> Given this, the access layer should be able to determine if RMPP is
>>> active.
>> 
>> Sure the RMPPFlags,Active can be checked. On the responder side,
>> do we want to make sure that RMPP is allowed/supported on that
>> class/method and possibly attribute ?
> 
> I would think the checks on a receive would be:
> 1) do we have someone to give this to
> 2) did the receiver tell us to look for an RMPP header
> 3) is RMPP active in the received MAD
> 4) invoke RMPP handling
> 
> Checks for send would be:
> 1) did the sender indicate there's an RMPP header in his MADs
> 2) is RMPP active in the MAD to send
> 3) invoke RMPP transfer

As long as we don't want any further checking along the lines
I described as part of #1. Assuming those checks are not done, this would
allow a request to be sent via RMPP and it would be responded
to even though it shouldn't be. So we would be relying on
the requester to do the right thing. I don't think that is a good
idea and it would get caught by a compliance test (some day).

Request/response matching would occur above RMPP.

>>> I don't think it matters which of the three types of transfers are
>>> in use. 
>> 
>> I'm not quite with you yet on this. I can see it for sender and
>> receiver but doesn't someone have to indicate a 2 sided transfer ?
>> Where/how do you see that being handled ?
> 
> I think that the checks listed above are sufficient.

I still don't see how that handles the 2 sided transfer. Is a 
2 sided transfer just a RMPP send followed by RMPP receive ?
Wouldn't this have to be on the same context (transaction ID, etc. tuple) 
at a minimum ? That's the significance of the IsDS flag.

>> I think timeouts need some exposure through the API somehow. In
>> order to handle the transaction timeout properly, it appears that
>> the packet lifetime in both directions needs to be obtained (passed
>> in ?). It also appears that in order to set the response time
>> properly access to the ClassPortInfo:RespTimeValue is needed (which
>> may change) if present. 
> 
> I need to think about this more.  My thought is that the client needs
> to determine the appropriate timeout, either through queries or by
> using 2 seconds as a nice number.  

There are some defaults supplied in the spec (different from 2 seconds)
 for when there is no GS class agent (no ClassPortInfo) and for ttime. 
Should we only support the default or allow for better timeouts ?

> Clients can set the RRespTime directly in the RMPP packet.  

That's good. We might want to help with an encoding routine for this.

> The access layer should only need to
> worry about modifying things like the SegmentNumber and
> PayloadLength.     

Wouldn't the response and transaction time outs occur within RMPP ?

-- Hal