Re: [Tsvwg] SCTP multi-homing association

devayya,

Well, if you push the connection beyond its capacity, delay will
increase.  When delay increases beyond T7, M2PA will consider the
signalling link unusable.

Delay under load, however, can be aggravated if you are sending a
SACK or a retransmission to the failed interface by mistake.

This is probably a question for SIGTRAN instead of TSVWG, so I have
redirected it there.

--brian

devayya wrote:                              (Sat, 08 Apr 2006 09:37:02)
> Hi Mark,
> 
> Please see inline comments.
> 
> 
> Mark Butler wrote:
> 
> > First of all, can you tell us which OS and SCTP implementation you are 
> > using?  If not a common one, 'internal/proprietary' is fine.
> 
> I am using Lynx RTOS(version 3.0.0) and the SCTP implementation is done 
> inhouse according to the  rfc2960, with some changes from SCTP 
> implementors guide version 14.
> 
> >    A few comments:
> >
> > 1. Normally in SCTP, associations do not go active / inactive, paths 
> > do. 2. Delayed ACK timer expiry is a normal event that is not an 
> > indication of a failure,
> 
> Here I was talking about the Upper Layer links(M2PA) going ACTIVE and 
> INACTIVE. and also the delay ACK timer is the Upper Layer delay ack 
> timer(T7 timer). I had metioned in my first mail that the SCTP 
> association remains in ESTABLISHED state, but the Upper Layer link(M2PA) 
> goes INACTIVE, probably due to no-delivery of the message from SCTP.
> I am sorry, that everybody misunderstood this as SCTP delay ack timer 
> expiry. My mistake, I should have been more clear.
> 
> > 3. If a DATA chunk is lost, either a later SACK or the T3 timer will 
> > eventually trigger a retransmission, which is supposed to be on an 
> > alternate path if available.
> 
> I agree.
> 
> >
> > 4.  If a DATA chunk is received but a SACK is lost, and there are no 
> > follow on SACKs, the DATA chunk will also be retransmitted in the same 
> > manner, but ignored since it was already received.
> 
> This could be one of the reason.
> 
> > 5. Max.Burst probably doesn't have anything to do with your problem.
> 
> I agree.
> 
> >
> > - Mark B.
> >
> >
> Thanks and regards,
> devayya
> 
> >>> On Apr 7, 2006, at 11:13 AM, devayya wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I have a question on SCTP multi-homing,
> >>>>
> >>>> My SCTP multi-homing test set up is as follows,
> >>>> There are two etherenet ports with different ip address are  
> >>>> configured for one endpoint(say endpont A). and similarly I have  
> >>>> another endpoint (say endpoint B) with two ethernet ports with  
> >>>> different ip addresses. The association between two endpoints is  
> >>>> ESTABLISHED.
> >>>>
> >>>> Using a test tool I transmit traffic between these two endpoints.
> >>>> With less amount of traffic flowing, if one of the ethernet port 
> >>>> IP  address is lost, then the association between these two 
> >>>> endpoints  remain ACTIVE and the traffic flows on the second 
> >>>> ethernet port.(As  per multi-homing  requirement)
> >>>> With increase in traffic flowing, if one of the ethernet port IP  
> >>>> address is lost, then the association between these two endpoints  
> >>>> goes to INACTIVE. and there is traffic loss. Although the SCTP  
> >>>> association is still present, the ULP association goes down, with  
> >>>> the reason "delay ACK timer expiry". Can anybody help find out why?
> >>>>
> >>>> As per SCTP implemtors guide, there is mention of  updation of 
> >>>> cwnd  when user tries to transmit DATA, cwnd should be modified 
> >>>> depending  on the flightsize and a newly introduced MAX.BURST.(not 
> >>>> present in  RFC)
> >>>>               if((flightsize + Max.Burst*MTU) < cwnd)
> >>>>                    cwnd = flightsize +  Max.Burst*MTU
> >>>>
> >>>> Is it really needed to implement this MAX.BURST?
> >>>> Will addition of this MAX.BURST solve the earlier problem 
> >>>> mentioned  by me?
> >>>>
> >>>> Thanks and regards,
> >>>> devayya
> >>>>
> >>>> P.s: For your reference I have attached a text file of the set up.
> >>>>
> >

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