RE: [Lksctp-developers] retransmission on alternate path in a multihomed session [Spam][87.9%]

[Vlad Y. <vla...@hp...>]

On Tue, 2006-01-31 at 17:07 +0100, Johan Eklund wrote:
> Hi again
>  
> Thanks for the answer Mark and I'm sorry for my delayed reply. Of
> course I want the data transmitted as soon as possible. My problem is
> that I've seen a different interpretation by another implementation. 
> What still puzzles me, as I read the RFC, section 7.2.1, is the
> initial size of the cwnd of the alternate path.
> As I interpret the text the cwnd of that path  (that has been idle so
> far) should be no more than 2 * MTU.
> When using the Linux 2.6-kernel I've noticed that more than 3 times
> MTU ( 3 full packets + a non full packet), actually all data sent but
> not yet SACKed on the primary path, is sent directly on the alternate
> path as the timer times out on the primary path.
> I find this odd, since I expected the cwnd on the alternate path to be
> restricted, and to grow as the first SACK arrives.
>  
> Any suggestions on how the initial size of the congestion window of
> the alternate path is determined?

Johan

See draft-ietf-tsvwg-sctpimpguide-16, Section 2.30.2

specifically the following text:

   ---------
   New text: (Section 7.2.1)
   ---------
      o  When the endpoint does not transmit data on a given transport
         address, the cwnd of the transport address should be adjusted
         to max(cwnd/2, 4*MTU) per RTO.


So, if you have idle transports for an RTO (in lksctp we use
Heartbeats), the cwnd will be adjusted to 4*MTU.

-vlad

>  
> thanks
> /Johan
>  
>  
>         
>         -----Original Message-----
>         From: lks...@li...
>         [mailto:lks...@li...] On
>         Behalf Of Mark Butler
>         Sent: den 19 december 2005 23:28
>         To: Johan Eklund
>         Cc: lks...@li...
>         Subject: Re: [Lksctp-developers] retransmission on alternate
>         path in a multihomed session [Spam][87.9%]
>         
>         
>         Johan Eklund wrote: 
>         > Hi 
>         >  
>         > I'm looking into failover performance in a multihomed
>         > session. According to RFC 2960 section 6.3.3 i expect one
>         > single packet to be sent on the alternate path after the
>         > first RTO-timeout (caused by path failure on the primary
>         > path). I've done an experiment on the Linux 2.6 -kernel and
>         > found that all not yet SACK'ed messages are sent on the
>         > alternate path in several different packets ( in my case
>         > three packets) after the timeout. I find this a bit strange,
>         > since, to me, it is not correct according to the RFC, or is
>         > it possible to interpret the RFC this way?
>         > 
>         > 
>         
>         Section 6.3.3 also states that the other data (pending on the
>         original address) that does not fit into the first packet
>         should be marked for retransmission and sent as soon as the
>         cwnd allows.  So the observed behavior is correct.
>         
>         Out of curiosity, why would you want it differently?
>         
>          - Mark
>