Re: [Tsvwg] early retransmit limits

> However, I think it would be beneficial to research the benefit of
> options that strengthen ER (~if needed~).  So, if network
> conditions change and reordering becomes more prevalent, we would
> know what the benefit/impact of using ER would be (in its
> different forms).

I agree that if reordering became a lot more prevlent then it would
behoove us to re-think ER (both in terms of network resource
wasteage and the cwnd sacrifice that ER causes).  Put another way,
spurious ERs cause a penalty for the connection itself and so there
is an incentive to not spuriously ER.

> On a side note.  There are studies to try and make TCP more robust
> to packet reordering.  One such method is to increase dupthresh,
> and I'll use that in the next example.  Suppose that during a
> connection, we've grown dupthresh to a value greater than three.
> If the connection then later experiences an ER situation, is ER
> still valid? (b/c an increased dupthresh would mean that you've
> experienced some amount of reordering, which is non-negligible)

Maybe.  In the dupthresh adjustment schemes sketched in
draft-blanton-tcp-reordering-00.txt the dupthresh is cwnd-1 at its
maximum.  So, as the window drains dupthresh is reduced.  But,
clearly, we could keep a maxdupthresh that indicates if we have ever
changed dupthresh based on reordering.  But, if we're headed down
that road then I think all we really need to do is look for
duplicate ACKs and no loss and set a flag if we see such an event.
Then we can use that as input to some sort of ER decision.  (A
dupack can be caused by packet replication in the network, but
everything I have seen shows that to be quite rare.)  My own opinion
right now is that this is a bit of overkill for ER because its so
tightly scoped.  But, something to keep in mind for down the road if
ER ends up busting a lot.

Thanks!

allman

--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg