[rbridge] Fwd: In-order delivery not an issue?

[James Carlson]

ravikumarb writes:
> What you are saying is perfectly fine with IP and TCP. But Ethernet is a layer 2 (link layer) protocol. In steady state, Ethernet always delivers packets in order. There are occasional packet losses but not out-or-order packet delivery.

Agreed, though we're also talking about bridging here, and out-of-
order is at least remotely possible when failures and reconfigurations
are considered.

As long as we don't have to consider recovery from "failure," with
"failure" defined as anything that changes the computed paths in the
network, I think requiring in-order delivery is fine.  In fact, it'd
likely require extra work to achieve out-of-order under those
conditions.

> 802.3ad mandates in-order delivery for packets belonging to a conversation. In similar lines, TRILL can maintain in-order deliver *only* for packets belonging to a CONVERSATION (by taking the same path), which in our case can loosely be defined as packets from a Source to Destination machine.

802.3ad does mandate it for a conversation, and it seems reasonable
that for the narrow case of ECMP we should recommend it to the extent
possible, but there are multiple issues here.  One is that 802.3ad
doesn't quite define what constitutes a "conversation" except in
circular terms via the definition in 1.4.94: you must keep those
packets in order because they're packets that are kept in order.

(It even seems to equivocate on that point by setting one of the goals
as a "low risk of duplication or misordering," and not just "none.")

The underlying issue, though, is that it's really not feasible to
mandate an absolute here.  We don't have the same simple peer-to-peer
signaling situation that is in 802.3ad, so the same type of "Marker
PDU" mechanism is impractical; the streams are split across multiple
paths, not just multiple links.  Instead, for folks who implement
multipath at all (it's not a required part of the implementation),
they'll need to do whatever they feel is necessary to satisfy the
markets they go into.  That might mean avoiding or disabling ECMP, or
selecting a single path among the available ones on which to send all
"unknown" type packets, or perhaps applying some of the insights in
RFC 2992 to minimize pain.

Given that implementors *must* understand their markets and the
intended use of what they're producing and any additional constraints
that may impose in order to produce competent products (the RFCs alone
are never enough), and that multiple reasonable answers are possible
here, I don't think it's a good idea to nail this issue down in this
document.  A warning about the possible effects of ill-considered
reordering behavior might be reasonable, but constraining the solution
set doesn't sound like a good plan to me, particularly in an IETF
document.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677