Subject: [Tsvwg] SCTP path term

From: "Andrey Konstantinov" <[email-masked]>
Date: Wed, 1 Oct 2008 14:36:39 +0400

Hi experts,

I have several questions regarding the limitation which has been observed in
RFC4960

According to RFC4960 PATH term has the following definition:
   o  Path: The route taken by the SCTP packets sent by one SCTP
      endpoint to a specific destination transport address of its peer
      SCTP endpoint.  Sending to different destination transport
      addresses does not necessarily guarantee getting separate paths.

In every chapter we can read that SCTP manipulates by paths in this
definition. For example, SCTP estimates the RTO per path (time to reach and
get response from the specific destination address), SCTP checks the status
of the path (status of remote IP address) and so on.

However, we know that SCTP uses "IP link" in order to transport SCTP
packets, and "link" it is not only destination address, but the pair of
local and remote IP addresses. If remote endpoint has 2 IP addresses and
local endpoint has 2 IP addresses, there are 4 IP paths and only 2 SCTP
paths (according to definition above). As a result, we have 2 IP paths in
order to reach one destination IP address and they are "included" both into
one SCTP path.

It could be not a problem if two IP paths have identical characteristics
(for example, RTT or status). But in realitity it is not true in most cases.
And if SCTP estimates RTO per destination address only using two different
IP paths changing it each time (for example, it is the case of regular
heartbeats), SCTP can get completelly wrong results.

In my opinion, SCTP should create path's structures for each possible
local-remote pair but not only for destination addresses as it is proposed
in chapter 13.3.

I do not insist that the current definition of PATH term is not correct, but
I would like to propose the extended view on this term and maybe provide the
possible migration scenarious from the PATH term in current definition to
proposed by me.
Moreover, we have implemented the SCTP with separated paths (in my previous
example we have constructed 4 path strucutres instead of 2) and got the
resolution for the problem when SCTP tryes to apply the characteristics from
one IP path to an other combining it in one structure.

The first my question is:
     Am I the first person who mentioned this problem?

The next question is:
     What should I do (maybe send this mail to special address) in order to
post this as a comment on RFC?

And the last question is:
     How is it possible to post a new draft or a some sort of proposal how
to migrate from the current definition to new keeping the backward
compatility in the interaction with the users and sequences in the network.

Thanks in advance,
Andrey

---

From: Randy Stewart <[email-masked]>
Date: Wed, 1 Oct 2008 07:22:57 -0400

On Oct 1, 2008, at 6:36 AM, Andrey Konstantinov wrote:

> Hi experts,
>
> I have several questions regarding the limitation which has been  
> observed in RFC4960
>
> definition. For example, SCTP estimates the RTO per path (time to  
> reach and get response from the specific destination address), SCTP  
> checks the status of the path (status of remote IP address) and so on.
>
> packets, and "link" it is not only destination address, but the pair  
> of local and remote IP addresses. If remote endpoint has 2 IP  
> addresses and local endpoint has 2 IP addresses, there are 4 IP  
> paths and only 2 SCTP paths (according to definition above). As a  
> result, we have 2 IP paths in order to reach one destination IP  
> address and they are "included" both into one SCTP path.
>
> It could be not a problem if two IP paths have identical  
> characteristics (for example, RTT or status). But in realitity it is  
> not true in most cases.
> And if SCTP estimates RTO per destination address only using two  
> different IP paths changing it each time (for example, it is the  
> case of regular heartbeats), SCTP can get completelly wrong results.
>
> In my opinion, SCTP should create path's structures for each  
> possible local-remote pair but not only for destination addresses as  
> it is proposed in chapter 13.3.
>
> I do not insist that the current definition of PATH term is not  
> correct, but I would like to propose the extended view on this term  
> and maybe provide the possible migration scenarious from the PATH  
> term in current definition to proposed by me.
> Moreover, we have implemented the SCTP with separated paths (in my  
> previous example we have constructed 4 path strucutres instead of 2)  
> and got the resolution for the problem when SCTP tryes to apply the  
> characteristics from one IP path to an other combining it in one  
> structure.
>

No, this was discussed at length during the development of RFC2960.  
The general
consensus was that sourced based routing is not something widely  
deployed or
something one can depend on.

In fact in the common edge you will find that if the IP provider is  
doing
things correctly they will filter out your packets if you send with a
different source address then you have been assigned.

i.e. if I have

IP-A
and
IP-B

With say ATT == IP-A  and Verizon == IP-B,

If I send a packet sourced from IP-B towards the IP-A's
default router.. the packet will be dropped. This is often
termed "ingress filtering". Its point is to protect against
malicious attacks using false IP addresses.

This is also why its recommended to use the IP address that you
emit the packet on...

>
> The next question is:
>      What should I do (maybe send this mail to special address) in  
> order to post this as a comment on RFC?

Its been discussed at length and was specifically excluded from either  
RFC 2960 or 4960.

>      How is it possible to post a new draft or a some sort of  
> proposal how to migrate from the current definition to new keeping  
> the backward compatility in the interaction with the users and  
> sequences in the network.

You would have to convince the IESG and this working group that this  
is something
worth doing. Considering it was talked about at length and that we  
specifically had
a .. nope source based routing is not deployed widely nor supported by  
the internet.. back
from the IESG originally.. unless something has changed in this area I  
doubt you will
find any support for this.. I may be wrong.. so you can ask..

For my 2cents.. unless someone can convince me the internet as changed  
for
source based routing.. I agree with the original decision by the IESG  
and the wg.

Lars? I think you "herd" SCTP any comments?

R

> Andrey

-----
Randall Stewart
[email-masked]

---

From: Michio HONDA <[email-masked]>
Date: Wed, 01 Oct 2008 16:44:41 +0300

Hi, Andrey,

Andrey Konstantinov wrote:
> different IP paths changing it each time (for example, it is the case 
> of regular heartbeats), SCTP can get completelly wrong results.
I recognize the main objective of path measurement without the primary 
destination is measurement of the retransmitting path. 
Hence, I think that it is assumed that the retransmission occurs on the 
same path as that already measured by HEARTBEATs. 
If so, SCTP won't get wrong parameters(e.g., RTO) on retransmission, 
because SCTP usually retransmits packets to different "destination 
address".
> local-remote pair but not only for destination addresses as it is 
> proposed in chapter 13.3.
I think retransmission from a different source address to the same 
destination address is also allowed.  (of course as long as the packet 
traverses correct ISP)
This case necessarily occurs in mobility scenarios. 
Of course, applying incorrect path information in your mention should be 
avoided. 
However, depending on the operating system and the configuration, 
source-address management in the transport layer can be difficult. (as 
Randall mentioned, source-based routing is not deployed widely...)
Therefore, I think that care about change of source address should be 
considered by not specification but the implementation. 
It won't influence interoperability among different SCTP implementations.

Best regards

-- 
Michio Honda
E-mail: [email-masked], [email-masked]
Website: http://www.micchie.net/

---

From: "Andrey Konstantinov" <[email-masked]>
Date: Wed, 1 Oct 2008 17:49:38 +0400

Hi,

I do not speak about local routing... Maybe I understand something
incorrectly... Could you refer me two some document if it is so?

Let's consider the example which explains the situation:

Local endpoint is initialized by IP1 and IP2, remote endpoint has IP3 and
IP4.
     There are 2 SCTP paths: to IP3 and to IP4 (according to definition in
RFC4960)
     And there are 4 IP paths: IP1 <--> IP3, IP1 <--> IP4, IP2 <--> IP3, IP2
<--> IP4.
Local endpoint may generate outgoing packets using 4 combinations above (and
it is legally!). If two of them are not working, for example IP1 <--> IP4
and  IP2 <--> IP3 (Let's call them cross-paths), there are no problems due
to straight-paths IP1 <--> IP3 and IP2 <--> IP4 arу completely matched
unequally by destination address only and there are only 2 proposed by RFC
structures.

However,
     An SCTP implementation may provide the possibility to use not only
straight-paths but cross-paths too. And it is the real case when traffic
flow is moved from IP1-IP3 "IP link" to IP2-IP3, when IP1 interface is down
(not available) or under restart. In this case SCTP needs to detect the
status for each pair but not only for destination address (see example 2
below).

1. For example, how SCTP should detect the status of PATH object: sending
heartbeats using  IP1 <--> IP4, we can detect that destination is
inactivate; and using IP1 <--> IP3, we can detect completely different
status, i.e. it is activate.
The resolution is only to report the status about IP path (as a pair of
addresses), but not about destination address only. Do you agree?

2. And the next example. Look at the attached picture. It is netwrok
configuration. There is an association between EP1 and EP2. The destination
primary is IP3. Primary path is IP1-IP3. An association transmits "highload"
traffic (possible cwnd is used and utilized fully on each sending) using
IP1-IP3.
An user requests to make primary path IP2-IP3. It has not been used before
by the association (maybe regular heartbeats have been sent only) and SCTP
starts to transmit data through IP2<-->IP3 without slowstart phase, because
SCTP PATH (destination IP3) is in congestion avoidance phase (cwnd is high).
As a result it can impact the network2 (router2) unexpectedly.

Any comments?

2008/10/1 Randy Stewart <[email-masked]>

>> I have several questions regarding the limitation which has been observed
>> in RFC4960
>>
>> I do not insist that the current definition of PATH term is not correct,
>> but I would like to propose the extended view on this term and maybe provide
>> the possible migration scenarious from the PATH term in current definition
>> to proposed by me.
>> previous example we have constructed 4 path strucutres instead of 2) and got
>> the resolution for the problem when SCTP tryes to apply the characteristics
>> from one IP path to an other combining it in one structure.
>>
> No, this was discussed at length during the development of RFC2960. The
> general
> consensus was that sourced based routing is not something widely deployed
> or
> In fact in the common edge you will find that if the IP provider is doing
> Its been discussed at length and was specifically excluded from either RFC
> 2960 or 4960.
>
>
>
> You would have to convince the IESG and this working group that this is
> something
> a .. nope source based routing is not deployed widely nor supported by the
> internet.. back
> For my 2cents.. unless someone can convince me the internet as changed for
> source based routing.. I agree with the original decision by the IESG and
> the wg.
>

---

From: "Andrey Konstantinov" <[email-masked]>
Date: Wed, 1 Oct 2008 17:57:23 +0400

Hi,

Thanks for you answer.
But see my comments inline:

2008/10/1 Michio HONDA <[email-masked]>

> destination is measurement of the retransmitting path. Hence, I think that
> it is assumed that the retransmission occurs on the same path as that
> already measured by HEARTBEATs. If so, SCTP won't get wrong parameters(e.g.,
> RTO) on retransmission, because SCTP usually retransmits packets to
> different "destination address".

Yes, it is usually. But if there are no more destination IP addresses and we
can alternate only local addresses (of course, using IP addresses which
belongs to local endpoint)?

> This case necessarily occurs in mobility scenarios. Of course, applying
> incorrect path information in your mention should be avoided. However,
> depending on the operating system and the configuration, source-address
> management in the transport layer can be difficult. (as Randall mentioned,
> source-based routing is not deployed widely...)
> considered by not specification but the implementation. It won't influence
> interoperability among different SCTP implementations.

Again, maybe I do not understand something..., but it is the feature of SCTP
when it uses an alternative path to retransmit the data when the primary is
not active anymore. And alternative IP path can be only with alternative
local address if remote endpoint is not multihomed.

---

From: Michio HONDA <[email-masked]>
Date: Wed, 01 Oct 2008 17:52:45 +0300

Andrey Konstantinov wrote:
> Local endpoint is initialized by IP1 and IP2, remote endpoint has IP3 
> and IP4.
>      There are 2 SCTP paths: to IP3 and to IP4 (according to 
> definition in RFC4960)
>      And there are 4 IP paths: IP1 <--> IP3, IP1 <--> IP4, IP2 <--> 
> IP3, IP2 <--> IP4.
> Local endpoint may generate outgoing packets using 4 combinations 
> above (and it is legally!). If two of them are not working, for 
> example IP1 <--> IP4 and  IP2 <--> IP3 (Let's call them cross-paths), 
> there are no problems due to straight-paths IP1 <--> IP3 and IP2 <--> 
> IP4 arу completely matched unequally by destination address only and 
> there are only 2 proposed by RFC structures.
>  
> However,
>      An SCTP implementation may provide the possibility to use not 
> only straight-paths but cross-paths too. And it is the real case when 
> traffic flow is moved from IP1-IP3 "IP link" to IP2-IP3, when IP1 
> interface is down (not available) or under restart. In this case SCTP 
> needs to detect the status for each pair but not only for destination 
> address (see example 2 below).
>  
>  
> 1. For example, how SCTP should detect the status of PATH object: 
> sending heartbeats using  IP1 <--> IP4, we can detect that destination 
> is inactivate; and using IP1 <--> IP3, we can detect completely 
> different status, i.e. it is activate.
> The resolution is only to report the status about IP path (as a pair 
> of addresses), but not about destination address only. Do you agree?
Switching routing from IP1 to IP2 is a job in the network layer, usually. 
Although the routing table is not clear in your picture, if the link 
from IP1 becomes down, the network layer will switch the default route 
to Router2. 
Otherwise, communication on the other protocol is also impossible. 
When IP1 interface becomes unavailable, endpoint1 may detect it by 
operating system features.  In this case, ASCONF(DELETE_IP_ADDRESS) for 
the unavailable address may be sent explicitly. 
Even if it is not sent, endpoint2 will also detect it by transmission 
failure to IP1 and switch the primary destination to IP2.
> configuration. There is an association between EP1 and EP2. The 
> destination primary is IP3. Primary path is IP1-IP3. An association 
> transmits "highload" traffic (possible cwnd is used and utilized fully 
> on each sending) using IP1-IP3.
> An user requests to make primary path IP2-IP3. It has not been used 
> before by the association (maybe regular heartbeats have been sent 
> only) and SCTP starts to transmit data through IP2<-->IP3 without 
> slowstart phase, because SCTP PATH (destination IP3) is in congestion 
> avoidance phase (cwnd is high). As a result it can impact the network2 
> (router2) unexpectedly.
>  
> Any comments?
Do you mean that an user changes the default gateway?
If so, I agree that such operations influence congestion as long as SCTP 
maintains congestion parameters per destination. 
But I think that SCTP specification doesn't assume such cases because it 
happens very rarely without the handoff case.  
I recognize that detection of changing the source address should be done 
with "best effort" by the implementation except for the handoff case. 
>  
> 2008/10/1 Randy Stewart <[email-masked] 
> <mailto:[email-masked]>>
>
>
>         I have several questions regarding the limitation which has
>         been observed in RFC4960
>
>         In every chapter we can read that SCTP manipulates by paths in
>         this definition. For example, SCTP estimates the RTO per path
>         (time to reach and get response from the specific destination
>         address), SCTP checks the status of the path (status of remote
>         IP address) and so on.
>
>         However, we know that SCTP uses "IP link" in order to
>         transport SCTP packets, and "link" it is not only destination
>         address, but the pair of local and remote IP addresses. If
>         remote endpoint has 2 IP addresses and local endpoint has 2 IP
>         addresses, there are 4 IP paths and only 2 SCTP paths
>         (according to definition above). As a result, we have 2 IP
>         paths in order to reach one destination IP address and they
>         are "included" both into one SCTP path.
>
>         characteristics (for example, RTT or status). But in realitity
>         it is not true in most cases.
>         And if SCTP estimates RTO per destination address only using
>         two different IP paths changing it each time (for example, it
>         is the case of regular heartbeats), SCTP can get completelly
>         wrong results.
>
>         possible local-remote pair but not only for destination
>         addresses as it is proposed in chapter 13.3.
>
>         I do not insist that the current definition of PATH term is
>         not correct, but I would like to propose the extended view on
>         this term and maybe provide the possible migration scenarious
>         from the PATH term in current definition to proposed by me.
>         Moreover, we have implemented the SCTP with separated paths
>         (in my previous example we have constructed 4 path strucutres
>         instead of 2) and got the resolution for the problem when SCTP
>         tryes to apply the characteristics from one IP path to an
>         other combining it in one structure.
>
>     No, this was discussed at length during the development of
>     RFC2960. The general
>             What should I do (maybe send this mail to special address)
>         in order to post this as a comment on RFC?
>
>
>     Its been discussed at length and was specifically excluded from
>     either RFC 2960 or 4960.
>
>
>
>
>         proposal how to migrate from the current definition to new
>         keeping the backward compatility in the interaction with the
>         users and sequences in the network.
>
>
>
>     You would have to convince the IESG and this working group that
>     this is something
>     a .. nope source based routing is not deployed widely nor
>     supported by the internet.. back
>     from the IESG originally.. unless something has changed in this
>     area I doubt you will
>     source based routing.. I agree with the original decision by the
>     IESG and the wg.
>
>     [email-masked] <mailto:[email-masked]>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>

---

From: "Andrey Konstantinov" <[email-masked]>
Date: Wed, 1 Oct 2008 19:27:34 +0400

Hi

Please, see my comments below.

Thanks for your response.
1 октября 2008 г. 18:52 пользователь Michio HONDA
<[email-masked]>написал:

>>     And there are 4 IP paths: IP1 <--> IP3, IP1 <--> IP4, IP2 <--> IP3,
>> IP2 <--> IP4.
>> Local endpoint may generate outgoing packets using 4 combinations above
>> (and it is legally!). If two of them are not working, for example IP1 <-->
>> IP4 and  IP2 <--> IP3 (Let's call them cross-paths), there are no problems
>> due to straight-paths IP1 <--> IP3 and IP2 <--> IP4 arу completely matched
>> sending heartbeats using  IP1 <--> IP4, we can detect that destination is
> Although the routing table is not clear in your picture, if the link from
> IP1 becomes down, the network layer will switch the default route to
> Router2. Otherwise, communication on the other protocol is also impossible.
> When IP1 interface becomes unavailable, endpoint1 may detect it by operating
> system features.  In this case, ASCONF(DELETE_IP_ADDRESS) for the
> unavailable address may be sent explicitly. Even if it is not sent,
> endpoint2 will also detect it by transmission failure to IP1 and switch the
> primary destination to IP2.

Understand this, sure it is so. But from point of endpoint1 view: when
interface1 is down it should chose the alternative path and continue to send
to IP3 since it is remote primary for the endpoint1 and still reachable.

> Do you mean that an user changes the default gateway?

No, I mean that the application which uses SCTP service requests to change
primary path (especially local primary address, according to RFC primary
path definition may include local address too).

> maintains congestion parameters per destination. But I think that SCTP
> specification doesn't assume such cases because it happens very rarely
> without the handoff case.  I recognize that detection of changing the source
> address should be done with "best effort" by the implementation except for
> the handoff case.

We avoided this situation maintaining variables per local-destination
address. I think it covers all possible cases for SCTP level without taking
into account features from the environment (like source address routing).

>
>  2008/10/1 Randy Stewart <[email-masked] <mailto:
>> [email-masked]>>
>>
>>
>>

---

From: David Borman <[email-masked]>
Date: Wed, 1 Oct 2008 11:35:05 -0500

This is the same issue that I brought up.  It is not source based  
routing, and it is not about using a different source IP address than  
the one assigned to the interface.  It is applicable in an environment  
where your local host can have multiple routes to a single  
destination, for example a default route out each interface.  So in  
the case where there are two local interfaces and two remote  
addresses, to fully detect all the possible paths, out each interface  
you need to send a HB to both the remote addresses.

Take a simple case:

Network X
---------+----------------+-----------------+-------
          |x.1             |x.2              |x.3
      +---+----+        +---+----+       +---+----+
      | Host A |        | Router |       | Host B |
      +---+----+        +---+----+       +---+----+
          |y.11            |y.12             |y.13
---------+----------------+-----------------+-------
Network Y

If you are running SCTP between Host A and Host B, you are going to be  
sending HB
	x.1 -> x.3
	y.11 -> y.13
If both x.1 and y.13 go down, you'll loose the connection, even though  
there is still a path through the router:
	y.11->(y.12->x.2)->x.3

One could argue that this is source based routing within the host.  
i.e., the source address determines which interface should be used to  
send the packet.  But it really is about having multiple routes to the  
remote address through different interfaces, and the source address is  
determined by which interface is being used to send the packet.

			-David Borman

On Oct 1, 2008, at 6:22 AM, Randy Stewart wrote:

>> However, we know that SCTP uses "IP link" in order to transport  
>> SCTP packets, and "link" it is not only destination address, but  
>> the pair of local and remote IP addresses. If remote endpoint has 2  
>> IP addresses and local endpoint has 2 IP addresses, there are 4 IP  
>> characteristics (for example, RTT or status). But in realitity it  
>> is not true in most cases.
>> possible local-remote pair but not only for destination addresses  
>> as it is proposed in chapter 13.3.
>>
>> previous example we have constructed 4 path strucutres instead of  
>> 2) and got the resolution for the problem when SCTP tryes to apply  
>> the characteristics from one IP path to an other combining it in  
>> one structure.
>>
> a .. nope source based routing is not deployed widely nor supported  
> by the internet.. back
> from the IESG originally.. unless something has changed in this area  
> I doubt you will

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 1 Oct 2008 12:59:20 -0600

David,

I was (at least) one of the people that brought up such issues
when RFC 2960 was being developed.  I believe that all of the
path issues were addressed before RFC 2960 was cut.  Some
changes were before RFC 2960 was finalized that addressed them.

For your specific case where x.1 and y.13 are down:

> Network X
> ---------X----------------+-----------------+-------
>          Xx.1             |x.2              |x.3
>          |y.11            |y.12             Xy.13
> ---------+----------------+-----------------X-------
> Network Y

If Host A has a route to x.3 via y.11 it can still send
HEARTBEAT messages to x.3 via y.11.  In this case, Randall's
advice that the source address on the HEARTBEAT message be the
address of the interface upon which it is being emitted is a
good one.  Host A can route HEARTBEAT (and other messages) to
x.3 via y.11 with a destination address of x.3 and a source
address of y.11.  Host B in this case should, per the RFC, send
HEARTBEAT ACK using the source address in the HEARTBEAT (y.11)
and assuming that Host B has a route to y.11 via x.3, the
HEARTBEAT ACK (or other ack message such as SACK) can get
through and the association will not be lost.

The implementation at Host A and Host B must be cognisant of the
fact that there are two routes to x.3 (one direct with a metric
of 1 and one indirect with a metric of 2).  When the route to
x.3 of metric 1 fails, it should try the route to x.3 of metric
2.  Because this case is an interface failure, Host A can know
that one route has failed (because the local interface has
failed).  If it is a link failure (e.g. the cable attached to
x.1) then it can only rely on negative advice with regard to x.1
to determine when to try the metric 2 route.

Nevertheless, however, this regards IP routing at Host A and is
not directly within the scope of SCTP.  We did recommend,
however, that where the implementation has no source address
control that it vary the source addresses in it HEARTBEAT
messages over the available source addresses.  And I think that
you can see why.

--brian

David Borman wrote:                           (Wed, 01 Oct 2008 11:35:05)

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

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 1 Oct 2008 21:27:18 +0200

Hi Andrey,

comments in-line.

Best regards
Michael

>      Am I the first person who mentioned this problem?
No. This question comes up from time to time. The SCTP RFC does not  
require an
SCTP implementation to be able to control the outgoing interface or  
the source
address. Therefore to provide fault tolerance you need not only to  
engineer your
network but also the addressing.

It is possible to generalize SCTP to consider source and destination  
address
pairs (assuming that you send out packets only on interfaces with own  
the
corresponding address), but this is not described in RFC 4960.
> order to post this as a comment on RFC?
Not sure. I think the RFC describes clearly the situation. You want to  
describe how
to use SCTP using a generalized path concept. If you really want to do  
that, you might write an ID...
> sequences in the network.
Write it, submit it... I'm not sure if it will become an RFC. That  
depends on several things...

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 1 Oct 2008 21:36:28 +0200

Hi Randy,

comments in-line.

Best regards
Michael

> This is also why its recommended to use the IP address that you
But using source/destination pairs is not restricted to source
based routing. You might be able to send packets to one of your peers
address via multiple interfaces...
> source based routing.. I agree with the original decision by the  
As said above: This is not necessary related to source based routing.  
It is
just about letting the transport layer detect all the possible  
combinations:
Which peer addresses can be reached from which local interfaces.

One could do it. But one has to go through the procedures and figure out
what is "per destination address" like "path verification" and what is
"per source/destination address pair" like the path supervision. You  
need
to adopt the error counting for the association and also the congestion
control. And loadsharing becomes even more interesting...

As far as I can see, all this can be sender only, so the protocol on the
wire does not need to change, and you might consider it an  
"implementation
issue".

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 1 Oct 2008 21:43:04 +0200

Hi David,

comments in-line.

Best regards
Michael

On Oct 1, 2008, at 6:35 PM, David Borman wrote:

> routing, and it is not about using a different source IP address  
> than the one assigned to the interface.  It is applicable in an  
> environment where your local host
Correct.
> can have multiple routes to a single destination, for example a  
> default route out each interface.  So in the case where there are  
> two local interfaces and two remote addresses, to fully detect all  
> the possible paths, out each interface you need to send a HB to both  
> the remote addresses.
>
> Take a simple case:
>
> Network X
> If you are running SCTP between Host A and Host B, you are going to  
> be sending HB
> 	x.1 -> x.3
> 	y.11 -> y.13
> If both x.1 and y.13 go down, you'll loose the connection, even  
> though there is still a path through the router:
> 	y.11->(y.12->x.2)->x.3
>
> i.e., the source address determines which interface should be used  
> to send the packet.  But it really is about having multiple routes  
> to the remote address through different interfaces, and the source  
> address is determined by which interface is being used to send the  
> packet.
As said in my previous mail: It is about the reachability of peer  
address from each local interface...

As said earlier: It is doable, but not done in RFC 4960.
>>> address), SCTP checks the status of the path (status of remote IP  
>>> address) and so on.
>>>
>>> the pair of local and remote IP addresses. If remote endpoint has  
>>> 2 IP addresses and local endpoint has 2 IP addresses, there are 4  
>>> IP paths and only 2 SCTP paths (according to definition above). As  
>>> a result, we have 2 IP paths in order to reach one destination IP  
>>> correct, but I would like to propose the extended view on this  
>>> term and maybe provide the possible migration scenarious from the  
>>> PATH term in current definition to proposed by me.

---

From: "Andrey Konstantinov" <[email-masked]>
Date: Thu, 2 Oct 2008 09:48:42 +0400

Hi,

Thanks for your answer.
It seems that we have a specific case. Indead, each IP interface has own IP
address in our system [...(assuming that you send out packets only on
interfaces with own the corresponding address) ...] Moreover, each IP
interface can be located on different computer board. So, SCTP level needs
to detect all possible combinations of paths in order to use multihoming
more effectively and in more reliable way, espacially if one board can be
turned off or removed from the system in runtime.
Yes, our path conception is not described in RFC4960. That is why I have
asked how it is possible to share our experiance and get a response from
other vendors.
Could you point me out the procedure the it is described how I can submit
the draft?

2008/10/1 Michael Tüxen <[email-masked]>

> No. This question comes up from time to time. The SCTP RFC does not require
> an
> SCTP implementation to be able to control the outgoing interface or the
> source
> address. Therefore to provide fault tolerance you need not only to engineer
> your
> pairs (assuming that you send out packets only on interfaces with own the
> Write it, submit it... I'm not sure if it will become an RFC. That depends
> on several things...
>
>>
>> Thanks in advance,
>> Andrey
>>
>
>

---

From: "Andrey Konstantinov" <[email-masked]>
Date: Thu, 2 Oct 2008 09:59:09 +0400

Hi Michael,

>>> different IP paths changing it each time (for example, it is the case of
>>> regular heartbeats), SCTP can get completelly wrong results.
>>>
> As said above: This is not necessary related to source based routing. It is
> "per source/destination address pair" like the path supervision. You need

Yes, correct. Especially it is necessary to have shared t3 counter between
several path which are connected with one destination address. It is the
first behavior.
And also, it is possible to redefine the path term more widly. For example,
we can have t3 counter for each pair local-remote and status of a
destination address is considered as active if there is at least one active
path to reach this destination and it is inactive if all paths are failed.
It is our alternative behaviour. Operator, could chose the behaviour: use
multipaths and adapt the sequences according to current RFC or use
multipaths with the complete redefinition of the term path.
And the last alternative is not described somewhere, that is why I am
investigating if it is useful to describe and publish or not.

> wire does not need to change, and you might consider it an "implementation
> issue".
>
>
>>

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 2 Oct 2008 08:54:27 +0200

Hi Andrey,

see my comment in-line.

Best regards
Michael

On Oct 2, 2008, at 7:48 AM, Andrey Konstantinov wrote:

> Hi,
>
> Thanks for your answer.
> It seems that we have a specific case. Indead, each IP interface has  
> own IP address in our system [...(assuming that you send out packets  
> only on interfaces with own the corresponding address) ...]  
> Moreover, each IP interface can be located on different computer  
> board. So, SCTP level needs to detect all possible combinations of  
> paths in order to use multihoming more effectively and in more  
> reliable way, espacially if one board can be turned off or removed  
> from the system in runtime.
> Yes, our path conception is not described in RFC4960. That is why I  
> have asked how it is possible to share our experiance and get a  
> response from other vendors.
> Could you point me out the procedure the it is described how I can  
> submit the draft?
http://www.ietf.org/ietf/1id-guidelines.html
> Not sure. I think the RFC describes clearly the situation. You want  
> to describe how
> to use SCTP using a generalized path concept. If you really want to  
> do that, you might write an ID...
>
>