potential bug on SFR-CACC

potential bug on SFR-CACC

[Chang]

Hi all,
I'm reading the source code of LK-SCTP and find something that I 
couldn't understand on the SFR-CACC feature of LK-SCTP, which might be a 
bug.

When a sender receiving a SACK, ***sctp_check_transmitted()*** would be 
invoked to update the state variables related to SFR-CACC, including 
***highest_new_tsn_in_sack*** and ***cacc_saw_newack***.

---------------------------------------------------------
The scripts to update ***highest_new_tsn_in_sack*** is as follow. 
Function ***sctp_acked*** checks if the tsn is acked(EITHER cumulatively 
OR selectively) in the sack reply.
---------------------------------------------------------
if(sctp_acked(sack, tsn)) {
     ......
     *highest_new_tsn_in_sack  = tsn;
     ......
}
---------------------------------------------------------
The scripts to upate ***cacc_saw_newack*** is as follow. It checks if 
the tsn is less/euqal than the cumulatively acked TSN ONLY in the sack 
reply, which is INCONSISTENCY with the abovementioned.
---------------------------------------------------------
if (TSN_lte(tsn, sack_ctsn)) {// sack_ctsn is cumulatively-acked
     ......
     if (!tchunk->tsn_gap_acked) {
         if (transport && sack->num_gap_ack_blocks && 
q->asoc->peer.primary_path->cacc.changeover_active)
         transport->cacc.cacc_saw_newack = 1;
     }
     ......
}

I would appreicate if anyone could confirm this is a work-as-design or a 
bug?

Cheers!

Re: potential bug on SFR-CACC

[Thomas Dreibholz]

[-- Attachment #1: Type: text/plain, Size: 2723 bytes --]

Hi Chang,

the first block should find the highest acknowledged TSN. If it is a GapAck, the 
receiver may revoke this acknowledgement later.

For the congestion control, it is important to find out whether there have been 
*new* acknowledgements. A TSN only counts as new once (when it is acknowledged 
for the very first time). After that, particularly also when the 
acknowledgement is revoked (reneging) and the TSN has to be transmitted and 
acknowledged again, any further acknowledgements of the same TSN do not count 
any more as "new".


Søndag 13. oktober 2013 12.11.22 skrev Chang:
> Hi all,
> I'm reading the source code of LK-SCTP and find something that I
> couldn't understand on the SFR-CACC feature of LK-SCTP, which might be a
> bug.
> 
> When a sender receiving a SACK, ***sctp_check_transmitted()*** would be
> invoked to update the state variables related to SFR-CACC, including
> ***highest_new_tsn_in_sack*** and ***cacc_saw_newack***.
> 
> ---------------------------------------------------------
> The scripts to update ***highest_new_tsn_in_sack*** is as follow.
> Function ***sctp_acked*** checks if the tsn is acked(*either*
> *cumulatively* *or* *selectively*) in the sack reply.
> ---------------------------------------------------------
> if(sctp_acked(sack, tsn)) {
>      ......
>      *highest_new_tsn_in_sack  = tsn;
>      ......
> }
> ---------------------------------------------------------
> The scripts to upate ***cacc_saw_newack*** is as follow. It checks if
> the tsn is less/euqal than the *cumulatively* acked TSN in the sack
> reply, which is *INCONSISTENCY* with the abovementioned.
> ---------------------------------------------------------
> if (TSN_lte(tsn, sack_ctsn)) {// sack_ctsn is cumulatively-acked
>      ......
>      if (!tchunk->tsn_gap_acked) {
>          if (transport && sack->num_gap_ack_blocks &&
> q->asoc->peer.primary_path->cacc.changeover_active)
>          transport->cacc.cacc_saw_newack = 1;
>      }
>      ......
> }
> 
> I would appreicate if anyone could confirm this is a work-as-design or a
> bug?
> 
> Cheers!

-- 
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

=======================================================================
 Thomas Dreibholz

 Simula Research Laboratory
 Simula Innovation AS, Network Systems Group
 Visiting address: Martin Linges vei 17, 1364 Fornebu, Norway
 Mailing address:  P.O.Box 134, 1325 Lysaker, Norway
-----------------------------------------------------------------------
 E-Mail:     dreibh@simula.no
 Homepage:   http://simula.no/people/dreibh
=======================================================================

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]