On Tuesday 27 July 2010 15:54:58 Martin Nyhus wrote: > On Sat, 17 Jul 2010 18:07:56 +0100 Matthew Toseland wrote: > > > - ********** IIRC TCP resends immediately if it sees a later sequence > > number? This reduces latency but will occasionally result in > > unnecessary resends? I think what TCP does is this: If a packet > > hasn't been acked after 4 RTT's (you can get this from > > PeerNode.fourRTTs()), we resend it; and if we get an ack for a > > packet, we assume those before it haven't arrived and resend them. I > > may be remembering wrong, there's something about 1.5 RTTs somewhere? > > Look it up, maybe on the wiki page? What the old FNP code does is > > hideous, of course.
> I couldn't find the details on TCP at first glance, but improving the > resend logic is on my todo-list. Okay so we do the equivalent of TCP slow retransmit (RTO) after 2 RTT's. The main difference being the simplistic calculation of RTT. Fast retransmit in TCP occurs after 3 duplicate ACKs. Basic TCP doesn't include select ack's, so this is equivalent to receiving acks for 3 packets after the lost packet. So we may want to implement something like that - find the packet waiting for ack with the highest sequence number, if there are 3 packets which have been acked after it, resend it. In doing so I believe we create a new sequence number, so it will then be gone from the resend tracking data structure? Is the current slow retransmit only adequate for now? I.e. can we deal with this after merging? This mainly matters with heavy packet loss. The old FNP does pull-based retransmit so requires multiple round trips, so we can probably merge with just slow retransmit. RTT: "In addition, senders employ a retransmission timeout (RTO) that is based on the estimated round-trip time (or RTT) between the sender and receiver, as well as the variance in this round trip time. The behavior of this timer is specified in RFC 2988. There are subtleties in the estimation of RTT. For example, senders must be careful when calculating RTT samples for retransmitted packets; typically they use Karn's Algorithm or TCP timestamps (see RFC 1323). These individual RTT samples are then averaged over time to create a Smoothed Round Trip Time (SRTT) using Jacobson's algorithm. This SRTT value is what is finally used as the round-trip time estimate." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20101109/023cd63c/attachment.pgp>
