Subject: [SAM] draft-kellil-sam-mtocp

From: Matthias Waehlisch <[email-masked]>
Date: Fri, 26 Mar 2010 14:36:21 -0700 (Pazifik Sommerzeit)

Dear authors,

  I read your draft on the multiparty transport overlay control 
protocol. Nice work. Can you clarify the following questions:

  * How does the MTO-Ctrl knows other MTO entities? Must all MTOCP 
entities have to register at the MTO-Ctrl?

  * In section 2.2, you mention that the MTO-Ctrl assigns the port 
numbers. How does the Ctrl knows that ports are not already in use?

  * The forwarding process is a bit unclear to me: By which means does 
an overlay node to unicast or to multicast?

  * It may be helpful to mention explicitly which states are maintained 
by which MTOCP entity.

  * And an editorial question: Page 4: "Comments are solicited and 
should be addressed ..." Is the mailing list correct?

Thanks
  matthias

-- 
Matthias Waehlisch
.  FU Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:[email-masked] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

---

From: "KELLIL Mounir" <[email-masked]>
Date: Mon, 29 Mar 2010 12:07:49 +0200

Dear Matthias

Thanks a lot for reading the draft, and your very relevant comments.

Please find below my answers.

> entities have to register at the MTO-Ctrl?
[MK] Currently (or in the current implementation if you want), MTO-Ctrl
gets the list of overlay nodes and connection descriptions from an
external module defined in a deliverable of the FP7 CCAST project work,
which MTOCP is part of.  Actually, the current MTOCP draft focuses on
the "enforcement/configuration" of the overlay tree in the network. The
"generation" of the topology/form of the overlay tree is out of the
scope of the draft. In our project implementation, the generation of the
overlay topology is handled by a specific network context-aware
component interacting with (but could be integrated in) the MTO-Ctrl;
but this is external to the MTOCP protocol.

> numbers. How does the Ctrl knows that ports are not already in use?
[MK] In our work we considered the single operator scenario in which the
operator has sufficient knowledge (and actually full control) of overlay
nodes in its network, their existing ports, etc. In such a scenario, the
MTO-Ctrl (owned by the operator) sets up a range of assignable port
numbers. Ports numbers are assigned for all multicast connections as
well unicast connections, except unicast connections terminating at
terminals. In the latter case, the MTO-CTRL might learn the terminal's
listening port from an out of band mechanisms (e.g. Session Mgmt
signalling like SIP).

> an overlay node to unicast or to multicast?
[MK] An ON receives forwarding information from the MTO-CTRL (via the
MTCOP protocol) in the form of one input transport connection and one or
multiple output transport connections (for a given MTO Tree ID). These
input/output connections are bound together in the ON "MTO forwarding
table". When the overlay node receives data on the input transport
connection, it then just forwards the data onto the output connections
indicated in its "MTO forwarding table".
Of course, the destination address of transport connections could be
multicast or unicast, IPv4 or IPv6. 

> by which MTOCP entity.
[MK] OK, this will be clarified a bit more in the next draft version.
BTW, the MTO-Ctrl maintains the list of all active MTO trees (MTO tree
IDs. And, for each MTO tree ID; it maintains the list of overlay nodes
along with their multicast/unicast connections). On the other hand, the
overlay node maintains the list of all input and output connections per
MTO tree which the said overlay node is connected to. 

> should be addressed ..." Is the mailing list correct?
[MK] Sorry, this and other typos will be corrected in a future version
of the draft.

Please do not hesitate to send us further comments you may have.

Best regards

Mounir

---

From: Matthias Waehlisch <[email-masked]>
Date: Wed, 31 Mar 2010 22:56:59 -0700 (Pazifik Sommerzeit)

Dear Mounir,

  many thanks for your answers!

On Mon, 29 Mar 2010, KELLIL Mounir wrote:

> [MK] Currently (or in the current implementation if you want), 
> MTO-Ctrl gets the list of overlay nodes and connection descriptions 
> from an external module defined in a deliverable of the FP7 CCAST 
> project work, which MTOCP is part of.  Actually, the current MTOCP 
> draft focuses on the "enforcement/configuration" of the overlay tree 
> in the network. The "generation" of the topology/form of the overlay 
> tree is out of the scope of the draft. In our project implementation, 
> the generation of the overlay topology is handled by a specific 
> network context-aware component interacting with (but could be 
> integrated in) the MTO-Ctrl; but this is external to the MTOCP 
> protocol.
> 
[MW] OK ... The MTO-Ctrl is an entity to establish centrally multicast 
states. The topolog creation should probably be integrated within the 
MTO-Ctrl as topologies will be constructed depending on the receivers. 
On ther other hand, one can collect, maybe aggregate, and delegate 
receiver subscriptions to the specific topology component.

  Nevertheless, the receivers have to register at the MTO-Ctrl - or at 
the topology component.

> MTCOP protocol) in the form of one input transport connection and one 
> or multiple output transport connections (for a given MTO Tree ID). 
> These input/output connections are bound together in the ON "MTO 
> forwarding table". When the overlay node receives data on the input 
> transport connection, it then just forwards the data onto the output 
> connections indicated in its "MTO forwarding table". Of course, the 
> destination address of transport connections could be multicast or 
> unicast, IPv4 or IPv6.
> 
[MW] OK, an ON decides on multicast or unicast based on the destination 
address in its local MTOCP state table.

  How do you map the destination address to an actual IP forwarding 
interface at an ON? Is this based on the local unicast routing table? 
And what does this mean for a multicast destination address: multicast 
addresses are not included in unicast routing tables. Thus, you cannot 
easily replicate packets and require an addition multicast 
routing/signaling, right?

  Btw: Do you assume a global topology view - at least with respect to 
the overlay nodes? Otherwise it seems hard to determine appropriately 
the destination address for ON state tables.

Thanks & Best regards
  matthias