[openib-general] Re: Some Initial RMPP Wire Observations

[Hal Rosenstock]

On Tue, 2005-05-03 at 16:55, Sean Hefty wrote:
> Hal Rosenstock wrote:
> > Short RMPP messages (less than 1 MAD's worth) have first bit set but not
> > also last in RMPPFlags.
> 
> Can you re-check this?  I'm able to successfully receive short segments, 
> and the receive code looks for the last bit to check for completion.

This was caused by a bad status in the sent segment so you can chalk
this up to user error...

> > Also, if the initial RMPP send had bad status, that status is maintained
> > in the RMPP response (ACK) by the receiver side (SA GetTable). Is this
> > getting "reflected" ? Should such a send be ACKed ? Also,
> > AttributeOffset is not being cleared in that ACK.
> 
> ACKs are formed by copying the headers of the received DATA MAD.  Right 
> now there are minimal checks done to verify that the MADs are properly 
> formatted, but adding these isn't overly difficult.

OK that answers the ACK formatting but not whether an ACK is correct in
this case.

o13-21.1.15 states that if a status code is received with an RMPPType
value other than those it applies to, the Receiver shall discard the
packet, terminate the protocol,and issue an RMPP ABORT packet with
status code "Illegal Status".

The receiver flow diagram for MAD OK indicates other checks are
appropriate.

Bottom line: I'm not 100% sure about this. It's probably OK to do either
but I'm not sure what good or harm it does to send an ACK with a bad
status.

> Should the AttributeOffset be cleared in the ACK?  I wouldn't have 
> thought that RMPP would have changed the common MAD header information.

AttributeOffset is in the SA header. It's only present in a DATA packet.
It says otherwise ignored on IBA 1.2 p. 884 line 31. Most of these
(ignore on receive) say transmit as 0 but this one doesn't so you are
right that it shouldn't need to be changed.

> > In a multisegment RMPP send, the middle segments have their PayLoad
> > lengths set to whatever the user initially set this to. While it should
> > be ignored by the receiver, it would be better if these were sent as 0.
> 
> The spec indicates that the payload length is ignored for the middle 
> segments, so I just left the field untouched.  There doesn't appear to 
> be a requirement to clear it.  (Doing so is trivial if needed.)

Both true.

> > In the last segment, it appears that the pad is not cleared. This again
> > shouldn't matter but I didn't dig out what the spec says here.
> 
> Not sure which field you're referring to here.

I'm referring to the transferred data beyond the end of the payload
length in the last segment. I'm not sure there is a requirement to do
anything with this on the transmit side.

>   The payload length 
> should be set to the number of valid bytes sent in the last packet.

Right so the receiver shouldn't look past this and any non 0 bytes don't
matter. (It just makes it look like real data is present there).

> > Is there a restriction on the message size ? Up to what size have you
> > tested this ? I don't seem to get an ACK back when I send with a
> > PayLoadLength of 0x6E0 but do get one with 0x370. Any idea if this is a
> > problem with the sending client or a problem in the RMPP receiver code ?
> 
> There's no restriction unless there's a bug.  I've tested MADs up to 
> 100,000 bytes, including sending a response.  Not sure what the issue is 
> that you're seeing.

OK. That's good to know. I will look harder to try to find out what is
going wrong. Probably another user error...

Thanks.

-- Hal