Subject: [Sigtran] Multihoming: use of two paths

From: Troiano Marco <[email-masked]>
Date: Tue, 19 Jul 2011 08:21:59 +0000

Hi Brian,
my name is Marco Troiano and I am a TLC engineer, working on a Italian Telecommunication company. I work on testing Sigtran in these days and I saw that some SCTP implementations use two paths for data traffic.
I mean that, in normal conditions, one node send traffic using both primary and secondary path in the same SCTP association. Is this behaviour normal for you? Looking at RFC 4960, I see:

An SCTP endpoint is considered multi-homed if there are more than one
   transport address that can be used as a destination address to reach
   that endpoint.

   Moreover, the ULP of an endpoint shall select one of the multiple
   destination addresses of a multi-homed peer endpoint as the primary
   path (see Section 5.1.2<http://tools.ietf.org/html/rfc4960#section-5.1.2> and Section 10.1<http://tools.ietf.org/html/rfc4960#section-10.1> for details).

   By default, an endpoint SHOULD always transmit to the primary path,
   unless the SCTP user explicitly specifies the destination transport
   address (and possibly source transport address) to use.

I understood that it is not mandatory using primary path but it is not mentioned to use two paths.

Thanks in advance,
Marco Troiano

Wind sostiene 10decimi. 
Invia un SMS del valore di 1 euro ai numeri: 45555-45556-45557.
E se hai una SIM Wind, ricarica online da wind.it e aiuta 10decimi.
Grazie da tutti i bambini di 10decimi.

Le informazioni contenute in questo messaggio di posta elettronica e in ogni
eventuale documento allegato sono riservate, potrebbero essere coperte dal
segreto professionale e possono essere utilizzate esclusivamente dal
destinatario sopra indicato. Ogni divulgazione o copia di questo messaggio o
dei suoi eventuali allegati non autorizzata, cosi' come ogni uso o
divulgazione delle informazioni negli stessi contenute, sono da considerarsi
come vietate e potrebbero costituire violazione delle normative ivi
applicabili.  Se ricevete questo messaggio per errore Vi preghiamo di
volerci avvertire immediatamente tramite posta elettronica o telefonicamente
e di cancellare il presente messaggio e ogni documento ad esso allegato dal
Vostro sistema. Vi informiamo che svolgiamo ogni attivita' finalizzata a
proteggere la nostra rete da virus e non ci assumiamo alcuna responsabilita'
in ordine a possibili virus che possano essere trasferiti con la presente mail.
Grazie.

*****************

The information contained in this e-mail and in any file transmitted with it
is confidential and may be privileged for the sole use of the designated
addressee. Any unauthorized dissemination or copying of this e-mail or its
attachments, and any use or disclosure of any information contained in them,
is strictly prohibited and may be illegal. If you are not the designated
addressee, please notify the sender immediately by e-mail or by telephone
and delete this e-mail and any file transmitted with it from your system.
We make every effort to keep our network free from viruses and take no
responsibility for any computer virus which might be transferred by way of this
e-mail.
Thank you.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 19 Jul 2011 14:24:34 -0600

Troiano,

Dr. Tuexen wrote a fairly good overview of the approach here:

	http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-multipath

A number of telecommunications and reliability focussed implementations
have used these and related techniques for quite a few years.  A body of
research exists: search on "Concurrent Multipath Transfer (CMT)."  There
has even been some conferences focussed on this single topic.

Hope that helps.

--brian

BTW, it is bad form to send e-mail messages to IETF working groups with
proprietary information notices such as that at the bottom of your note.

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/