---------- Forwarded message ---------- From: Vladislav Sterzhanov <[email protected]> Date: 2013/7/4 Subject: Re: [freenet-dev] [gsoc2013] Transport Layer - Update 1 To: Matthew Toseland <[email protected]>
On 07/03/2013 05:57 PM, Matthew Toseland wrote: > On Wednesday 03 Jul 2013 02:09:22 Vladislav Sterzhanov wrote: > > | Concerning CWV: Original RFC promotes two crucial ideas: > 1) If we received ack for a packet, but we didn't utilize the full window > when we actually sent it to the node (we were application-limited rather > than network-limited) - we should not increase the window size, but instead > shrink it since we can't be sure, could the link hold such window or not. > This shrink should be done immideately after sending the last packet that > doesn't fill up the window. > 2) If the application was idle for N RTO periods - the window should be > shrinked for each of those N - the previous window size can't be trusted as > relevant anymore. > The RFC says to shrink it by half for each RTT. (Subject to the usual > arbitrary minimum etc). > In idle periods - yes, once for each calulated average RTT that has passed since the sender was active. Two major problems here: >> Current implementation of CWV (PacketThrottle.** >> notifyOfPacketAcknowledged()) >> checks the size of a window *after* receiving an ack for packet, when it >> should check for the state of the window *when the packet was sent* - >> could >> be solved simply by adding a bitflag to SentPacket. >> > I don't follow, above you talk about when we receive an ack. > Doh, sorry, need to cease writing reports deep at night. Corrected the last part, but forgot about this one. It is all related to the process of sending a packet - even the fact that we receive an ack for a packet that was sent during application-limited period doesn't give us any new relevant information - the reliability of the size of the window is still not proved by anything. So now for the points that I'd like to discuss: >> >> | Packet vs Byte size: not sure about current status of this discussion, >> the last description of it that I've seen was in the comments to >> NPFCK.countSentPackets() - if there was something more recent - please, >> let >> me know. *IMHO*, changing it to bytes will give *much* more precise >> control >> over the link. In any case, there is *very* significant difference from >> the >> point of the already implemented algos and the ones outlined here whether >> there are currently N max-sized packets in flight, or just N left-overs or >> ack-only packets, much shorter than maxPacketSize. Thoughts? But of course >> it will create some difficulties, e.g. what to consider a "full" window? I >> propose considering the window full if it utilizes > (window - >> window%maxPacketSize bytes) - quite natural. >> > Yes, I started to try to implement byte-based congestion control some > years ago. It got awfully complicated, and the code was quite different > then. IMHO it's not worth looking at the old attempt. A closely related > issue: Small packets cause efficiency problems, because we have largish > headers. We may want to allow congestion control to make us send small > packets, but there has to be a lower bound ... > >From the first sight it doesn't seem to cause huge problems anymore - will try that, almost sure that it will have a considerable impact on the situation. | F-RTO algo: not very trivial logic to outline here, but it allows to >> detect the cases where the retransmission timeout was spurious - we could >> wait a while more and the ack would arrive. Could possibly help especially >> over high-latency and high-bandwith links. Have someone looked through it >> - >> could it be usefull for us? >> > This is a more sophisticated form of fast retransmission? Sounds > interesting. > Not exactly. It's weird, it is essentially a bulk of accurate modifications that notifies the layer that the timeout was too short - layer decided that a packet was lost and reset the congestion window, but the initial packet was not lost and arrived at last. So the layer probably should increase the RTO value and revert back changes to window size. Or something more complicated - the reaction to spurious timeout is not specified. High-bandwith links could possibly benifit from it. You are welcome to ask if something is not clear for you - I'm falling >> asleep, so sorry in advance. >> > I'll try to read the RFCs soon. Got lots of stuff to catch up on still... > No problems with that - I still contend with some of those and some others not mentioned - they are not all as transparent as they possibly could be. And I still need to implement sample testings for this all - so the discussion is not too urgent.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
