Re: Expectations for FPDU alignment when processing out of order TCP segment

"Caitlin Bestler" <[email protected]>
Newsgroups gmane.ietf.rddp
Message-ID <[email protected]>
Barry Reinhold said:
> This may be a duplicate posting, my apologies if it is.
>
> How would you expect a MPA receiver to handle an out of order TCP
> segment with markers disabled and CRC off? Does it just buffer it until
> the gap is filled?

As noted in John's response, when markers are disabled the only way
to know where a DDP Segment starts is to know where the prior one
started.

To be very technical, it is hypothetically possible to have a gap
still pending in the middle of a segment that you have the start
of. Hence you *could* recognize that you had a valid TCP Segment
and within it a valid DDP Segment, and you *could* process it
of order.

Then all you have to do is figure out how to test it.

Realistically, if you are working without markers you pretty much
have to process in order.

You *could* do a *speculative* analysis, to determine if something
*might* be a DDP Segment. And it the CRC failed it would certainly
be useful diagnostic data.

However a receiver should not "speculate" on placement until it
knows legitimately that something is a DDP Segment. After all,
there is no rule that says a valid DDP Segment could not be the
*payload* that is being delivered within a DDP Segment.

If I recall correctly, Jim Williams posted a proposed alternative to
MPA a bit back that had an excellent description of what a receiver
would have to do if it were to do speculative handling of DDP Segments
to ensure that it had no adverse impact on the ULP.

>
> Also, if CRCs are enabled and we are processing an out of order PDU
> without markers, what is the behavioral expectation of a failed CRC
> check? A matched CRC would be sufficient to determine FPDU alignment,
> but a failed CRC appears only to say that you may not have FPDU
> alignment.
>

The effect of a bad CRC is to terminate the connection. But the receiver
must not take that action until it knows that the bad CRC is indeed
attached to a valid DDP Segment and not merely something that
looks like one.

> That is, if I created a test that produced a gap in the TCP sequence and
> then sent an unaligned FPDU within a TCP segment, followed by the
> missing information I would expect the receiver to: (1) Not drop the
> connection, (2) Advance the ACK through the unaligned segment when the
> missing information was sent.
>
> Is this the correct understanding?

Mostly correct.

In the previously noted case where the starting location of the DDP
Segment could be known legitimately, the receiver MAY process the
DDP Segment as soon as all enclosing TCP segments are validated,
and the MPA checksum is validated.

And at that point it *could* note that there was an MPA error, or
even a DDP layer error, and terminate the connection.

But I doubt that anyone will take heroic efforts to process non-marker
MPA FULPDUs out-of-order. If you want to work out-of-order you will
simply insist on receiving markers.

So techically, an analysis tool that expected no action would be technically
incorrect. But if I were assigning a "bug value" to such a mistake it would
probably be a 1 out of a possible 100.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.