[BXXPwg] Whither serial and seqno?

Greg Hudson ghudson@MIT.EDU
Sun, 23 Jul 2000 21:54:37 -0400


Poking through the old draft-mrose-bxxp-* stuff, it sounds like BXXP
might have been initially designed to work with transports where
frames might be reordered, and still has some stuff left over from
that.  Perhaps Marshall can comment on whether that's the case.

> TCP was the model for these control mechanisms in BXXP, and the two
> reasons for choosing the model was A) they work, and B) they are
> well understood.  We lose the benefit of B if the list must re-hash
> basic constructs.

TCP congestion control algorithms are rocket science.  The flow
control stuff BXXP borrowed is not.  Because BXXP runs on a sequenced
transport, a couple of obviously redundant constructs can be elided,
resulting in less overhead and a simpler protocol.  I will happily
prepare proposed changes if they will be seriously considered,
although they would of course fall under the "discouraged" category of
backwards-incompatible changes to BXXP.

> So, an essential lesson from experience is to be careful on what is
> "deduced from the connection state" because one side or the other
> can screw up that state.  Protocols needs reasonable robustness
> against such failures.  There are painful examples of the need.

This argument is silly applied to this case.  It would imply, for
instance, that SMTP should have put serial numbers on every command
and every response because clients and servers might get confused as
to how they correspond.

>  From the -protocol- draft...

I wasn't asking what the items were; I was asking for design rationale
as to why they are there.  Serial numbers are not needed to match
requests with responses, any more than they are needed in traditional
command-oriented IETF protocols.  The sequence number of a new frame
is trivially computed by adding the lengths of the frames received so
far.  Keeping these redundant constructs does not introduce any
meaningful kind of consistency checking; they simply add make-work for
the sender and introduce unnecessary exception cases for the receiver.
And a bunch of verbiage in the spec.