[BXXPwg] Do BXXP serial/seqno help with unsequenced transports?

Greg Hudson ghudson@mit.edu
Mon, 28 Aug 2000 21:18:45 -0400

Something about the serial/seqno issue has been bugging me.  At the
last IETF meeting, there was reportedly consensus to leave those
mechanisms in the protocol, but part of the justification for that
consensus was:

	It was pointed out that the degree of redundancy is dependent
	on the transport mapping, and that different header formats
	for different transport mappings is undesirable for many
	reasons [...]

The implication of this argument is that the underlying transport may
not guarantee sequencing of frames, and that the mapping to that
transport might want to use the serial/seqno information in the frame
headers to sequence frames instead of adding its own information to
each packet or frame.

However, I don't think serial/seqno in their current form actually
achieve the goal of making the header format identical for sequenced
and non-sequenced transports.  The following problems would come up
trying to map onto a non-sequenced transport:

	* Requests on a channel have to be processed in order (or at
	  least "as if" in order).  Serial numbers are not actually
	  ordered, so if whole requests arrive out of order, further
	  information is required to process them in order.

	* Several of the framework's rules for identifying
	  poorly-formed frames assume that frames arrive in the same
	  sequence they were sent (in fact, all of the rules starting
	  from the sixth one).

At the risk of sounding like a shrill outlier attempting to reopen a
closed issue, I would suggest that we either:

	* Mandate that serial numbers arrive in sequence starting at
	  0, and rewrite the framework's rules not to assume that the
	  underlying transport mapping guarantees sequencing of


	* Reconsider the consensus in favor of serial numbers and
	  sequence numbers, given that in their current form their
	  only value is as a consistency check, and given that they
	  may have an impact on 1:0 interactions (you don't know when
	  you can reuse a serial number unless the protocol includes
	  an otherwise unnecessary response).

(For those joining us recently, I have been of the opinion that this
kind of shallow consistency checking is not a worthwhile reason to add
unnecessary mechanisms to a wire protocol; previous IETF protocols
have generally not attached a serial number to commands which must be
delivered in order, nor a sequence number to chunks which must be
delivered in order.  A number of people disagree with me, including
Marshall.  I don't know whether consistency-checking alone would have
been enough of a justification to produce a consensus at the IETF
meeting, since I wasn't present.)