[BXXPwg] Draft Minutes of last week's meeting

Keith McCloghrie kzm@cisco.com
Sun, 6 Aug 2000 01:03:06 -0700 (PDT)


Here's a draft of the minutes of last week's meeting.

Keith.
-------------

BEEP Working Group

Minutes of meeting at Pittsburgh IETF (August 2000)

Agenda

  - review of agenda
  - review of BEEP: design, framework, and TCP-mapping - Marshall Rose
  - prepared presentations
     - Issues List - Marshall Rose
     - Mapping LDAP onto BEEP - Kurt Zeilenga
  - suggestions/comments from the floor
  - disposition of Internet-Drafts
  - wrap-up

First session (Thursday 4th August)

As an introduction, Keith McCloghrie reviewed the charter and
milestones for the WG.  Marshall Rose then presented a review of BEEP,
the rationale for its design choices, the framework for the protocol,
and its mapping on top of TCP.   In addition to clarifying questions,
several suggestions were made during the presentation:

- it was suggested that some transport mappings will be able to get
  indications of network congestion (e.g., via "Congestion Manager"), and
  therefore that it would be useful for the interface between the
  framework and a transport mapping to allow the transport mapping to
  pass up an indication of network congestion.

- for security, it was asked whether it's possible to start TLS first,
  and then run BEEP over top of it, rather than not being able to start
  TLS until after some BEEP messages have already been exchanged.
  Marshall clarified that it's not currently possible, but he would think
  about whether it could be made possible.  Marshall also clarified that
  it's not possible to do encryption on a per-channel basis, i.e., that
  negotiation of encryption applies to all channels.

Marshall then presented a list of issues that had been raised on the
mailing-list prior to the meeting.  He listed the issues in five
categories: Framing, Profiles, Channel Management, Reporting and TCP
mapping.

A) Framing Issues

1. Serial/Sequence numbers - BEEP's inclusion of serial and sequence
numbers in its message header format could be viewed as redundant
information.  However, they ensure that the communicating applications
will detect situations in which they become unsynchronized.  That is,
sequence and serial numbers provide robustness in the form of catching
application-programming errors.  In addition, Marshall cited his
practical experience of catching such errors during interoperability
testing of BXXP implementations.  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, e.g., because it complicates encoding and parsing.  Therefore,
the consensus of the meeting was to keep the serial and sequence numbers
as-is.

2. Invalid RSPs - the framework does not specify what happens when a
channel gets an invalid RSP.  It was agreed that an invalid RSP on
channel zero should cause the whole session to be aborted.  However, it
is unnecessary to abort the whole session for an invalid RSP on a
non-zero channel; rather, it is only neccesary to abort the individual
channel.   Therefore, the consensus of the meeting was to generate a
diagnostic message, and to shut down a non-zero channel on which an
invalid RSP was received.

3. MIME headers only in first frame of a message - the framework does
not explicitly explain this requirement.  It was observed that the
scope of these MIME headers is limited, and so, it's unlikely that they
could be large (e.g., larger than the size of a frame).  Nevertheless,
they enjoy a "free ride" from a flow-control perspective, because they
are part the header, not part of the payload, and therefore not subject
to flow-control.  Therefore, the consensus of the meeting was that the
framework document does need to add explanatory text about this issue.

4. REQs and RSPs - the framework requires that each REQ have one and
only one RSP.  Discussion of this issue led to several examples of
applications which have a different requirement:
   - a logging application, which does not need an application-level
     acknowledgement for each log message it sends; this was described
     as the "1-to-0" requirement (one REQ with no RSP).
   - a status reporting application, where a request for status invokes
     multiple periodic responses, e.g., a RSP providing status every 10
     seconds; this was described as the "1-to-N" requirement (one REQ
     with many RSPs).
Several mechanisms were suggested to address these requirements.  It was
proposed that a solution should avoid the sending of useless/redundant
messages.

Second session (Friday 5th August)

Kurt Zeilenga gave a presentation of issues he had found in
investigating how to map LDAP on top of BEEP.  He stated the primary
issue as being the number of situations where LDAP interactions are not
one REQ to one RSP.  In particular, he gave "persistent search" as an
example of a 1-to-N requirement, and "unsolicited responses" as an
example of a 1-to-0 requirement.

Marshall then continued to present the Issues List.

4. REQs and RSPs (continued) - The consensus of the meeting was to
accept the "1-to-0" and "1-to-N" requirements, and to request
volunteers to work offline on a solution, and then send to the
mailing-list.  Joe Touch volunteered to prepare a proposal.

B) Profile Issues

1. Default Content Type - should a profile be allowed to specify a
default Content Type.  By having a default, an application would not
have to send a Content Type every time it opened a channel, which could
save, say, 40 bytes.  On the other hand, always having the Content Type
explicitly specified would simplify the task of a "debugger" being used
to capture all exchanges on the BEEP session by capturing packets "on
the wire".  Thus, this issue is a trade-off between "reducing the
number of bits on the wire" versus "ease of debugging".  A show of
hands determined that there was no consensus in the meeting on which
choice was better.  Thus, this issue was deferred for discussion on the
mailing list.

2. Default Character Set - should an XML-based profile be allowed to
specify a default character set.  One suggestion was to discourage the
use of anything other than UTF-8.  However, it was pointed out that the
argument in favour of UTF-16 is that Asian characters can be
represented in only 2 bytes in UTF-16 instead of 3 bytes in UTF-8
(although other considerations cause the overall length of encodings
to even out overall).  The consensus of the meeting was for all
XML-based profiles to have a default of UTF-8, i.e., not to allow each
profile to have its own default.  However, if an XML-based profile
needs to specify an alternative character set, it should use a
Content-Type header to do so.

C) Channel Management Issues

1. Closing Channels - should the framework allow channels to be
closed.  Such a mechanism will be useful for the transport mappings to
know traffic has ceased on a channel (so that buffers can be released),
and the closing of a channel will allow its re-use.  Having a Close
Channel will also provide the means to send diagnostic information and
to shut-down a non-zero channel (see the "Invalid RSPs" issue above).
This led to discussion of allowing more than 255 channels.  When
running over TCP, channels will be able to be re-used faster than TCP
ports can be re-used (because of TCP's TIME-WAIT state).  Therefore,
the size of the channel number space should be larger than the number
of TCP ports.  Thus, it was suggested that a channel number be up to 31
bits wide.  However, it was also suggested that the minimum number of
concurrently open channels supported by an implementation need only be
257.  The consensus of the meeting was to introduce a Close Channel
mechanism able to include diagnostic information, to allow 31 bits of
channels number with a minimum of 257 concurrently open channels.

2. Piggybacks - an XML-based profile is allowed to include an encapsulated
message as part of channel creation.  This piggybacking capability saves
a round trip time, and that was thought to be a good thing for some
transport mappings, e.g., T/TCP or UDP.  However, implementations should
not send an "unreasonable" amount of data in the <start>.  The consensus
of the meeting was to retain piggybacks, and to add text to the
specification reminding profile designers that initialization elements
should be reasonable in size.

D) Reporting Issues

1. Error code - should channel-0 as well as the SASL and TLS channels
use three digit error codes.  It was agreed that the hierarchical model
of the three digit codes was good, and that having textual messages for
humans in addition to the machine-readable 3-digit error codes was
good.  The consensus of the meeting was for no change.

E) TCP Mapping Issues

1. Silly Window Syndrome - should the TCP mapping document include text
similar to RFC 1122 to explain SWS.  The consensus of the meeting was
to cite RFC 1122 and to explain the context of how it applies to BEEP,
i.e., the same except for retranmissions.

2. Shrinking the Window - should the TCP mapping document include words
similar to RFC 1122 on allowing the window's right-hand edge to move
only to the right.  The consensus of the meeting was to cite RFC 1122
and to explain the context of how it applies to BEEP, i.e., the same
but there's no "congestion window".

Suggestions from the Floor

It was suggested that having the channel number in RSP messages would
simplify an implementation.  The alternative perspective was that the
channel number of a received RSP is easy to obtain through looking up
the RSP's serial number.  The ability of a debugger capturing "on the
wire" packets was again cited as being simpler if it did not have to
see as many packets, nor keep as much state.  Thus, the consensus of
the meeting was to include the channel number in the RSP message.

This led to the suggestion that the serial number no longer needs
to be unique per session, only unique per channel.  It was observed
that this would make it simpler for multi-threaded implementations.
Therefore, the consensus was that message serial numbers only need to
be unique within a channel.

Disposition of Internet Drafts

It was observed that the design document, draft-mrose-bxxp-design-00.txt,
is written as Marshall and Carl's rationale for the design of BXXP,
which is the starting point of the Working Group's effort.  Thus, it is
not appropriate for it to become a standards-track document, nor for it
to be a WG document.  Instead, it was agreed that the authors be
thanked for their input and allowed to publish it in whatever way they
wish, e.g., the WG would be quite happy for it to be published as an
Informational RFC.

The framework and TCP-mapping documents, draft-mrose-bxxp-framework-01.txt
and draft-mrose-bxxp-tcpmapping-01.txt, were adopted as WG documents, and
Marshall will update them based on the consensus of the WG.  The consensus
of the WG will be as recorded in the minutes and as modified by discussion,
if any, of the minutes on the mailing-list.

Marshall explained that the initial attempt at a SCTP-mapping document,
draft-mrose-beep-sctpmapping-00.txt, needs further work.  As such it
will be adopted as a WG document, but could have significant revisions
at a later date.

The WG welcomed Joe Touch's offer to start work on a transport mapping
document for BEEP over "multiple TCP connections".   Work on a transport
mapping document for BEEP over UDP was deferred.  Joe Touch also stated
his intention to make a proposal for being able to turn off encryption on
a per-channel basis.