[BXXPwg] Whither serial and seqno?

Dave Crocker dcrocker@brandenburg.com
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
>state.


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 
and sequencing.

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 
delivery.

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...

Framework:

>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.


Definitions:

>2.2 Messages and Frames
>...
>    The sequence update message is used to flow control request and
>    response messages, ...

and

>2.2.1.1 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.

So,
         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

and

>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 
the text.

Best of all would be specific suggestions for changes to the text.

d/


=-=-=-=-=
Dave Crocker  <dcrocker@brandenburg.com>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA