Re: [tcpm] An issue in RFC3517? (Re: end-of-stream loss recovery (TCP SACK) )

[Mark Allman <[e-mail]>]

> Otoh, a more optimal approach could be to identify if the cumulative
> ack 5 was due to the retransmitted seg 1, or the original seg 1 -
> I.e. By using timestamp information. Depending on the result, a cumack
> due to delayed seg1 could be identified and adressed (similar to eifel
> detection/response).... 
> 
> Would that be a workable solution for that scenario?

Maybe.  I'll channel colleague here and note that you'd have to work
through a bunch of scenarios.  This reordering case is merely one
example of the sort of thing Ethan and I have did *countless* times in
the development of 3517.  The interactions are subtle and not always
readily apparent at first blush.

    (For instance, this conversation with Ethan started by me saying
    "looks OK, right?" and him saying something like "well, I dunno who
    has worked through it diligently?".  And then me throwing out some
    examples and then both of us trying to figure out where it breaks.
    Ethan constructed a case based on your example where we needlessly
    retransmitted and then we hit upon the realization that half the
    window could get needlessly sent.  But, it takes some effort to play
    through these things and dream up what might happen.  So, "is that
    workable?" is a really tough question to answer.)

Also, I'd like to remind folks that we never intended 3517 to be *the*
way to do SACK.  We designed it as a reasonable and conservative way to
use SACK information to do loss recovery.  I would be perfectly happy to
see folks carefully develop alternatives.

allman