[BXXPwg] Whither serial and seqno?
Mon, 24 Jul 2000 10:19:24 +0900
At 12:48 PM 7/23/00 -0400, Greg Hudson wrote:
>Why are serial and seqno present in BXXP request and reply headers?
>As far as I can tell, the serial number serves no protocol function
>and the sequence number can easily be deduced from the connection
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.
One might pursue a line of debate about the need for ALL of this mechanism,
on the theory that the underlying TCP transport takes care of reliability
It turns out that TCP, itself, was developed in response to learning from
that error, with respect of network-level transport. The early Internet
(Arpanet) used a high quality mechanism to make these assurances. They
worked well, but not perfectly. In addition, BXXP is intended to be able
to operate over other transports, some of which might not provide in-order
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.
From the -protocol- draft...
>2.5 Flow Control
> Although the underlying transport service imposes flow control on a
> per-connection basis, if multiple channels are simultaneously in use
> within a connection, BXXP must provide a mechanism to avoid
> starvation and deadlock. To achieve this, BXXP re-introduces
> mechanisms used by the TCP: sequence numbers and window-based flow
> control. Briefly, each channel has a sliding window that indicates
> the number of payload octets that a peer may transmit before
> receiving further permission.
> Every payload octet sent in each direction on a channel has an
> associated sequence number. Numbering of payload octets within a
> frame is such that the first payload octet is the lowest numbered,
> and the following payload octets are numbered consecutively.
>2.2 Messages and Frames
> The sequence update message is used to flow control request and
> response messages, ...
>220.127.116.11 Frame Header
> The serial number must be a non-negative integer (in the range
> 0..32767) and have a different value than all other outstanding
> request messages (regardless of channel number).
> The sequence number must be a non-negative integer (in the range
> 0..4294967295) and specifies the sequence number of the first octet
> in the payload, for the associated channel.
serial number uniquely labels outstanding REQs and
seqno counts bytes in the sequence of corresponding REQs or RSPs.
As to details of use:
> There are several rules for identifying poorly-formed frames:
> o if the header starts with "RSP", but the serial number does not
> refer to an outstanding request message;
> o if the value of the sequence number doesn't correspond to the
> expected value for the associated channel (c.f., Section 2.5.3);
> If a frame is poorly-formed, then the connection is closed without
> generating any response.
So, serial numbers are used to match an RSP to a REQ.
Further detail on seqno:
BXXP is full duplex. That means that two flow control mechanisms are
needed. One for each direction. With respect of flow control, REQ is the
consumer is one direction and RSP is the consumer in the other. The
consumer debits the window. SEQ gives credits.
> 2.7 Peer-to-Peer Behavior
> As a consequence of the peer-to-peer nature of BXXP, serial numbers
> are unidirectionally-significant. That is, the serial numbers in
> "REQ" messages sent by a BXXP initiator are unrelated to the serial
> numbers in "REQ" messages sent by a BXXP listener.
In terms of making correlations, note:
>seq = "SEQ" SP channel SP ackno SP window CR LF
>ackno = seqno
>2.5.4 Processing SEQ Messages
> o an acknowledgement number, that indicates the value of the next
> sequence number that the sender is expecting to receive on this
> channel; and,
> o a window size, that indicates the number of payload octets
> beginning with the one indicated by the acknowledgement number
> that the sender is expecting to receive on this channel.
This is a substantial amount of text in the draft, defining and explaining
these functions. Hence it will be helpful to hear what was unclear about
Best of all would be specific suggestions for changes to the text.
Dave Crocker <email@example.com>
Brandenburg Consulting <www.brandenburg.com>
Tel: +1.408.246.8253, Fax: +1.408.273.6464
675 Spruce Drive, Sunnyvale, CA 94086 USA