SCTP path term

Re: SCTP path term

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
>
> 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?

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.

>
> 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.

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

>
> Thanks in advance,
> Andrey

-----
Randall Stewart
randall <at> lakerest.net

Re: SCTP path term

Hi, Andrey,

Andrey Konstantinov wrote:
>  
> 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.
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".
>  
> 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 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: micchie <at> sfc.wide.ad.jp, micchie <at> ht.sfc.keio.ac.jp
Website: http://www.micchie.net/

Fwd: SCTP path term

SCTP path term

Re: Fwd: SCTP path term

Andrey Konstantinov wrote:
>
> 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?
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.
>  
> 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?
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 <randall <at> lakerest.net 
> <mailto:randall <at> lakerest.net>>
>
>
>     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
>
>         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?
>
>
>     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.
>
>
>
>
>         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.
>
>
>
>     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
>
>
>         Thanks in advance,
>         Andrey
>
>
>     -----
>     Randall Stewart
>     randall <at> lakerest.net <mailto:randall <at> lakerest.net>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>

--

-- 
Michio Honda
E-mail: micchie <at> sfc.wide.ad.jp, micchie <at> ht.sfc.keio.ac.jp
Website: http://www.micchie.net/

Re: Fwd: SCTP path term

Re: SCTP path term

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:

>
> 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
>>
>> 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?
>
> 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.
>
>
>>
>> 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.
>
>
> 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
>
>>
>> Thanks in advance,
>> Andrey
>
> -----
> Randall Stewart
> randall <at> lakerest.net
>
>
>
>

Re: SCTP path term

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
>      +---+----+        +---+----+       +---+----+
>      | Host A |        | Router |       | Host B |
>      +---+----+        +---+----+       +---+----+
>          |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)
> 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:
> 
> >
> >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
> >>
> >>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?
> >
> >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.
> >
> >
> >>
> >>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.
> >
> >
> >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
> >
> >>
> >>Thanks in advance,
> >>Andrey
> >
> >-----
> >Randall Stewart
> >randall <at> lakerest.net
> >
> >
> >
> >

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/

Re: SCTP path term

Hi Andrey,

comments in-line.

Best regards
Michael

On Oct 1, 2008, at 12:36 PM, Andrey Konstantinov wrote:

> 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?
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.
>
> 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?
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...
>
> 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.
Write it, submit it... I'm not sure if it will become an RFC. That  
depends on several things...
>
> Thanks in advance,
> Andrey