Re: [Tsvwg] early retransmit

>    "Research shows that a general reduction in
>     the number of duplicate ACKs required to trigger fast retransmission
>     of a segment to two (rather than three) leads to a reduction in the
>     ratio of good to bad retransmits by a factor of three [Pax97].
>     However, this analysis did not include the additional conditioning
>     on the event that the ownd was smaller than 4 segments."
> 
> I don't see how the condition of ownd < 4 segments matters. If 3
> dupacks is more appropriate to due the amount of reordering, then
> less than 3 isn't appropriate regardless of ownd.

Unless the pattern of reordering a connection experiences is
effected by the amount of load that connection is placing on the
network.  The Bennett, Partridge, et. al. study on reordering (ToN,
12/1999) suggests that reordering and congestion are linked (but, I
do not think they analyzed that correlation at the connection
level).

Maybe all that needs stated a bit better.  But, I think the point is
still valid.  (And, you might be right... my point is really that we
don't know.)

> I prefer solutions which induce the possibility of 3 dupacks (or 4
> missing reports for SCTP). 

Well, that is best.  I like limited transmit.  And, you'll note that
this ID is for the case when you don't have new data to send.  But,
you knew that because...

> Hari Balakrishnan's solution of sending zero-byte segments and

So, I'd be interested in hearing from people who understand these
sorts of things... Given that I am going to form up a packet and
send it across a network path, what is the marginal cost of adding
data to that packet?  I.e., what is the delta in effort between a
zero byte packet and a full packet?  (I realize that this is likely
hard to quantify in any sort of general way.  But, is it "a lot more
effort" or "not much more effort" or what?)

My gut says that in the general case we might as well dump data into
the packet.

> Marco Mellia et al.'s solution of breaking segments into smaller
> pieces are two ideas which I think deserve more attention.
> Although these mechanisms may add _some_ load to the network, I
> think more research is needed with these type of solutions.

I agree that more research is needed.  No doubt.

But, it comes down to a question of what is the unit that matters.
Is it the number of bytes I throw into the network or the number of
packets I inject?  (And, yes, I am sure the answer is "both". ;)

I think early retransmit sounds like a fine idea.  Digging a little
deeper into one of my questions of this morning... What sorts of
limitations should we place on the use of ER?  I think a possible
approach is to say that you should use DSACK or Eifel or something
in conjunction with ER to detect the cases when ER retransmitted
spuriously.  And, if you figure that out then you have to stop using
ER.

> I also think that more research is needed to determine what dupack
> threshold is appropriate. It may be worthwhile to investigate the
> use of a mechanism which begins with a conservative threshold, and
> then gets adjusted over time. To start, DSACKs/Eifel/etc may be
> useful for increasing the threshold.

    Ethan Blanton, Mark Allman. On Making TCP More Robust to Packet
    Reordering. ACM Computer Communication Review, 32(1), January
    2002.
    http://roland.grc.nasa.gov/~mallman/papers/tcp-reorder-ccr.ps

    Ethan Blanton, Robert Dimond, Mark Allman. Practices for TCP
    Senders in the Face of Segment Reordering, February
    2003. Internet-Draft draft-blanton-tcp-reordering-00.txt (work
    in progress).

    Ming Zhang, Brad Karp, Sally Floyd, and Larry Peterson.  RR-TCP:
    A Reordering-Robust TCP with DSACK, ICSI Technical Report
    TR-02-006, Berkeley, CA, July 2002.
    http://www.icir.org/bkarp/reordering-TR.ps.gz

I am sure others, too.

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