Summary of MoIP reliable transport conference call

[James_Renkel at 3COM.COM]

A conference call was held on Friday, June 15, 2001, between
representatives of The CommWorks Corp. and Cisco Systems to begin
discussing the requirements for a reliable transport protocol to be used
with MoIP, the evaluations of existing protocols against those requirements,
and the eventual recommendation of an exisitng (possibly modified) or new
protocol for that purpose.

On the call from The CommWorks Corp. were:
-    Mike Nicholas; and
-    Jim Renkel.

>From Cisco Systems were:
-    Herb Wildfeuer; and
-    Mehryar Garakani.

The call began by discussing the events that led up to the call. It was
agreed that the goal of this and future follow-on calls is to develop a
joint CommWorks / Cisco Systems contribution to the next meeting of
TR-30.1 giving requirements for the MoIP reliable transport mechanism
that could be agreed to by the two companies, and possibly an evaluation
of existing protocols against these requirements that both companies could
also agree to. Requirements and evaluations that could not be agreed to by
the two companies would be left for presentation by each company separately.
It is understood that there is a desire, once the requirements and possible
evaluations have been presented to TIA TR-30.1 and agreed to by them, to have
the requirements and possible evaluations presented to the IETF 51 meeting
in London, UK, during the week of 8/5/2001. It is also understood that some
parties plan to present a draft protocol proposal to that meeting.

It was then agreed that proprietary information previously disclosed in
contributions to the ITU-T and TIA groups studying MoIP could be discussed
in these conference calls, but no new proprietary information should be
first disclosed in these calls.

It was then suggested and agreed that a small "reference model" would be
useful in the discussions. The following was agreed to as the refence model,
subject to future modification as may be necessary:
-    The reliable transport issue is bi-directional and symmetric, but is
     perhaps best addressed by: considering the uni-directional, asymetric
     case; then combining the uni-directional case with a mirror image of
     itself to yield the bi-directional case.
-    The uni-directional case can be represented by this diagram:
      (See attached file: Reliable transport.vsd).

Discussion then turned to CommWork's contribution PCM01-020, "Transport
mechanisms in MoIP operations", to the Nice, FR, rapporteur's meeting of
Q11/16, in particular a row by row discussion of Table 1, "Transport
mechanism characteristics", on page 8 of that contribution.

It was agreed that the transport protocol must support two-way, unicast
sessions. It need not support one-way only or multicast sessions. Jim Renkel
will draft requriements statements reflecting this for consideration for
inclusion in the joint contribution .

It was agreed that the protocol should be structure preserving, but that
this should be described as "packet oriented rather than stream oriented."
Mehryar Garakani will draft requirements statements reflecting this  for
consideration for inclusion in the joint contribution .

In considering the next characteristic, "Structure format discriminating",
it was agreed that the issue really being considered here is that of
switching / transitioning among VoIP, FoIP, and MoIP "modes" during the
course of a call. While no firm agreement was reached on the requirements
and mechansim for doing this, the discussion seemed to indicate that the
companies were close to agreement. Each company will draft requirements
for this to be exchanged via e-mail prior to and discussed at the next
conference call.

The next conference call is to be held Tuesday, 6/19/2001, at 10:30 A.M.,
CDT, 8:30 A.M., PDT.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Reliable transport.vsd
Type: application/octet-stream
Size: 27648 bytes
Desc: not available
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20010622/3bc0c380/attachment-0003.obj>