• Ilpo Järvinen's avatar
    tcp FRTO: work-around inorder receivers · 79d44516
    Ilpo Järvinen authored
    If receiver consumes segments successfully only in-order, FRTO
    fallback to conventional recovery produces RTO loop because
    FRTO's forward transmissions will always get dropped and need to
    be resent, yet by default they're not marked as lost (which are
    the only segments we will retransmit in CA_Loss).
    
    Price to pay about this is occassionally unnecessarily
    retransmitting the forward transmission(s). SACK blocks help
    a bit to avoid this, so it's mainly a concern for NewReno case
    though SACK is not fully immune either.
    
    This change has a side-effect of fixing SACKFRTO problem where
    it didn't have snd_nxt of the RTO time available anymore when
    fallback become necessary (this problem would have only occured
    when RTO would occur for two or more segments and ECE arrives
    in step 3; no need to figure out how to fix that unless the
    TODO item of selective behavior is considered in future).
    Signed-off-by: default avatarIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
    Reported-by: default avatarDamon L. Chesser <damon@damtek.com>
    Tested-by: default avatarDamon L. Chesser <damon@damtek.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    79d44516
tcp_input.c 156 KB