[BXXPwg] Re: proposal for 1:N interactions

B. K. Oxley (binkley) at EBS B. K. Oxley (binkley) at EBS" <Brian_Oxley@enron.net
Tue, 29 Aug 2000 08:56:30 -0500


Thus spake Marshall Rose:

>    - within a channel, orderly delivery of frames
>    - between channels, no constraints on ordering of frames
>    - a message number (formerly known as a serial number), may not
>      be reused until an acknowledgement (of some kind) is received,
>      and the msgno space is big (31 bits)

It is conceivable in the long-fat pipe scenario that 2^31 messages
could be in use at the same time by a channel?  I'm hard pressed to
think of an example.  Is there a requirement of sequential message
numbers (I'm sorry if I missed this point in the documents if it has
already been addressed)?  What if I like skipping by arbitrary amounts
between message numbers, say the sequence 2^1, 2^2, 2^3, etc.?

You address this somewhat in the 1:0 case:

>    - 1:0 interactions still require an acknowledgement from the
>      remote side:
>        otherwise, we could run out of msgno's and it's probably
>        needed for end-to-end correctness

Which, again, is a performance issue for long-fat pipes.  In
particular, I am arguing at my company to use BXXP for a project where
we want asynchronous communication between clients and the server, so
that the server can return a delayed response to a request after some
arbitrary processing.  This is equivalent to a long-fat pipe where the
delay is unbounded, perhaps not a case you'd care to consider.  (You
might suggest opening up a new channel for each request, since there
is no requirement of synchronization between channels, but I'd prefer
not to do this for complexity reasons.)

And I think Hudson has raised this point in a different guise (my
emphasis added):

> 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
>         frames.
>
>	or
>
>	* 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).


Cheers,
--binkley


B. K. Oxley (binkley)
Sr. Engineer
Enron Broadband Services
4828 Loop Central Drive #620
Houston, TX 77081

mailto:Brian_Oxley@enron.net
(713) 669-4057 (Office)
(713) 408-7981 (Cell)
(713) 669-0130 (Fax)
http://wwp.icq.com/2739017 (ICQ)