Sigtran Working Group
Meeting Notes

Reported by Tom Taylor.

The Sigtran Working Group met on Tuesday afternoon, March 16.
There were 200 attendees.

1. Opening

Lyndon Ong, Chair, opened the meeting by reminding attendees of the terms
of the group's charter and schedule.  The proposed agenda was approved.

-------------

2. Architecture and Functional Requirements
(draft-ietf-sigtran-framework-arch-00.txt)

Lyndon Ong led discussion on this document.  The contents of this document
were agreed to be stable.  The group intends to bring it to WG last call in
accordance with the original schedule of April 1999.  The current draft
contains four sections:
 - terminology
 - architectural model
 - protocol architecture
 - functional requirements.

Work was still needed on sections for management and security.  An editing
session to review the document and flesh out those sections was set for the
next day (March 17).

The presentation concluded by reviewing the functional requirements as are
presented in the current draft.  No comments were offered by the meeting.

--------------

3. Sigtran Performance Requirements

The group currently has two drafts on performance requirements:
 - draft-seth-sigtran-sigtran-req-00.txt (considered in December)
 - draft-ietf-sigtran-TCAP-perf-req-00.txt 

Paul Lin presented the latter to the meeting, working from a chart based on
Figure 2 of the draft with time values filled in.  His chart showed a
breakdown of a 350 ms TCAP response time.  Within this, 150 ms is available
for message transfer.  As against this, a single round trip is in the order
of 100 ms.  If the initial try succeeds, the transfer is within budget;
otherwise it is not.

Discussion turned to how much delay Diffserv processing would add.  Scott
Bradner intervened at this point to suggest that it was far too early to
worry about Diffserv delays: we don't know yet what Diffserv will do for us.

Paul was asked whether the 350 ms total budget was for an average response
time or some percentile (e.g. 95% of responses are now received within 350
ms of query transmission).  The point is that if this is an average and the
average probability of retransmission is low enough, then the average (i.e
expected value) of message transfer time will be within budget.

The discussion of the TCAP presentation concluded with a suggestion that
transfer time budgets may have more significance for network engineering
than for protocol design.

Discussion now turned to call setup performance. It was suggested that
Sigtran should aim to support performance as good as users of the PSTN are
used to.  In particular, they are now accustomed to a post-dialing delay of
less than a second.  The proposed objective for Sigtran is therefore:
  Probability(IP portion of call setup > 1 s) = 0.05

Based on typical call flows involving a single tandem IP connection between
two decomposed gateways (see charts), a series of 10 messages must be
passed to complete call setup.  This includes MGC-MG messaging.  Assuming
that 50% of the 1 second budget is allocated to processing, this leaves a
transport budget of 500 ms/10 messages = 50 ms per message (one-way
transfer).  

Initial discussion included the reminder that transmission delays are
distance-sensitive and a suggestion that processing should get more than
50% of the budget, based on current experience with TCAP.  There was a
suggestion that the call flows on which this presentation was based were
faulty, in that the SDP loop should be completed before sending the IAM on
to the terminating PSTN.  It was noted that message transfer times must be
less than typical ISUP messaging timeouts in PSTN switches or signalling
will fail.  These timeouts are typically in the order of 20 s for receipt
of an Address Complete Message (ACM), meaning that the satisfaction of
subscriber expectations is a far more stringent requirement.

The question raised at this point was what to do with the numbers that had
come out of the discussion.  What are the hard requirements on message
transfer times?  Some more numbers were offered at this point: Bellcore
(Telcordia) measurements of post dialling delay give typical figures of
around 5 s for a local call, 8 s for an international call.

One possible use of all of these numbers might be to decide whether there
is sufficient time to do the three-way handshake required to set up a TCP
connection.  Scott Bradner commented that this is unlikely to be the
show-stopper for TCP.  The real problem is the number of sessions which
must be supported simultaneously.

The discussion concluded with a note that Paul's draft provides other
figures of merit besides end-to-end delay.   Subsequent discussion in the
editing session led to some of the key requirements on message loss and
sequence error being added to the functional requirements document, and an
agreement to clearly identify the "hard" and "soft" delay requirements.

----------------

4. Protocol Framework 

4.1 draft-rytina-sigtran-generic-framework-00.txt

Ian Rytina presented the charts in this section.  He began by providing a
rationale for a generic protocol framework:
  -- there are lots of SCN protocols
  -- their requirements are different.
His proposed approach is to provide common basic services on the one hand,
then group protocols in "service levels" according to the additional
services they require.  The Working Group's first task is thus to define
the service levels and allocate protocols to them.  Detailed work should
start with the protocols most in demand.

In discussion it was noted that the term "service level" may be confusing.
In a totally unrelated point, it was noted that QSIG might be transported
on its own or might be contained within an ISUP message.  The meeting
agreed that in the latter case the Sigtran transport need not be aware of
the encapsulated protocol.

Lyndon asked if the Working Group has problems with using a modular
framework.  There was general support for the modular concept, but numerous
unresolved issues on the details.  The resulting discussion raised several
questions.
Question: does modularity imply successive protocol layers, with the
overhead they might add?
Response: the Working Group is open to suggestions for increased efficiency.
Question: will Sigtran recognize national variants?
Response: yes.
Question: how many layers will be developed?
Response: the Working Group will decide as we go.

Closing remark: how will the group co-class protocols?  What criteria will
be used?  The group needs to develop guidelines. 

4.2 Session Manager, Backhaul Application
  (draft-ietf-sigtran-session-mgr-00.txt,
draft-ietf-sigtran-signaling-backhaul-00.txt)

David Auerbach presented the charts.  He and his colleagues viewed the
problem as divided into three layers, for which the two drafts named above
plus draft-ietf-sigtran-reliable-udp-00.txt provide proposed solutions.
The basic model on which the proposals are based assumes that
time-sensitive and invariant aspects of the Sigtran protocol are
implemented on the SG.  Signalling protocol-variant portions of the Sigtran
protocol are implemented on the MGC.  His presentation in general provided
a summary of the rationale and design approach on which the three proposals
are based.

There was one question on management.  The protocol should allow the MGC to
manage signalling links on the MG or SG as the case may be.

Ken Morneault presented the slides dealing specifically with the Session
Manager proposal.  Lyndon commented that this might be an example of a
module within the Sigtran framework. Discussion ensued regarding whether
the work proposed in the Session Manager document was really an area for
standardization.  The meeting did not come to a conclusion on this issue.

4.3 MIME Type/Format Issues
  (draft-ietf-sigtran-mime-isup-00.txt)

Christian Huitema led the discussion.  He explained that to register a MIME
type, one had to provide pointers to format specifications for that type.
To specify ISUP, one needs additional parameters, which he had defined in
his proposal.

Scott Bradner explained that the registration of a new MIME type is being
used as a procedural shortcut, obviating the need to publish a new RFC.

Gur Kimchi noted that one could also use registered object identifiers
(OIDs) as an alternative to MIME types.

Christian was asked if the MIME type were intended as a per-message
identifier.  In Christian's view, the answer was "no".  Rather, it would be
used as part of a management operation setting up a "signalling channel".

Chip Sharp suggested that vendor and version parameters might also be
needed.   Q.931 provided an example of such a requirement.  Jonathan
Rosenburg  questioned the need for a vendor parameter, since it is normally
part of the IANA registration process.  In the present case, however, it
may be a functional requirement.

Christian will recycle the draft to add the new parameters.

-----------------

5. Reliable Transport

Lyndon introduced this part of the meeting by expressing the intent that a
design team made up of the proponents of the various reliable protocol
proposals would sort through them and narrow the set of choices to be made
by the Working Group.  Volunteers for the design team were taken and it was
agreed to begin meeting via conference call in the following week.

5.1 H.323 Annex E

Gur Kimchi presented this protocol.  H.323 Annex E can be obtained at
ftp://standard.pictel.com/avc-site/9905_San/H.323-annex-e-white.zip. 

H.323 Annex E describes a transport mechanism which is independent of
H.323, but was designed to carry H.323 call signalling on top of UDP.  The
header is binary but is not ASN.1-encoded.  Gur enumerated the features of
the protocol and described the header.  Annex E is currently going through
balloting and is due to be decided (made a standard) at the next ITU-T
Study Group 16 meeting in May.  Our understanding is that it is no longer
open to modifications.

5.2 MDTP (draft-ietf-sigtran-mdtp-01.txt)

Qiaobing Xie presented the slides for the MDTP presentation.  The key
feature of this protocol is its ability to provide rapid recovery from
network failures.  It is based on the use of alternative hot stand-by links
to which traffic may be moved in the event of failure.  The protocol
achieves its advantages by insulating the upper layers from link management. 

5.3 RUDP (draft-ietf-sigtran-reliable-udp-00.txt)

Ken Morneault presented the slides for the RUDP presentation.  RUDP meets
most of the Sigtran requirements.  It lacks a congestion avoidance
mechanism. The presentation included a list of suggested improvements.

Christian Huitema stated that the purpose of congestion avoidance is not to
protect the network: the network can protect itself.  Instead, congestion
avoidance allows the application to adapt to the network's current
capacity. If it does so, it gets to choose which packets get through.  If
it fails to do so, the network chooses which packets get through.  For a
different view of congestion avoidance, see below.

5.4 PURDET (draft-toney-purdet-00.txt)

Ken Toney presented a list of the advantages of PURDET, emphasizing its
light weight and ease of implementation.  He also showed the message flows
associated with its use.  PURDET satisfies many of the functional
requirements for Sigtran, including multiplexing of signaling streams.

Scott Bradner commented that congestion avoidance is a requirement for any
protocol to come out of Sigtran.  He also urged presenters and their
colleagues to attend the SLUMS BOF.

5.5 SSCOP (draft-sidebottom-sigtran-ips7-rtsp-00.txt)

Greg Sidebottom presented an analysis of the possible use of SSCOP to carry
signalling over IP.  He reviewed the features of that protocol and
described the work that would be required to adapt it to IP operation.
SSCOP would provide some commonality of transport of signaling in ATM and IP.

This section of the meeting concluded with the comment that TCP is the
benchmark against which any other proposals should be measured.