Thanks Spencer, this is massively helpful. The background to this is that I am implementing a TCP for use in the app I am building. Obviously I want to use best-current-practice when building it, but I do need to roll my own rather than rely on the OS' implementation as my app needs to adjust some of the TCP internals to change the speeds of connections to different hosts relative to each other, based on some other factors (more details here when I get the thing to work satisfactorily).
I have built the protocol based on TCP Vegas, but after reading those references I clearly need to update it to use SACK and to ack-clock except on rto, as you mention. My implementation of the protocol is seemingly coming to resemble a microcosm of TCP development. :o) One further question, which RFCs 2018/2581 don't seem to address; do modern TCPs still use a Vegas-like system for detecting congestion in advance of packet loss, i.e. by measuring difference between expected and actual throughput and adjusting the window accordingly? If not, what other mechanism[s] do they use? Thanks again, Will On 04/01/2008, Spencer Dawkins <[EMAIL PROTECTED]> wrote: > Can I ask why you're looking at TCP Vegas? Are you actually running TCP > Vegas from the early 1990s, and not a more recent TCP? > > I haven't seen a network trace for a TCP that didn't do SACK in quite a > while... If your network trace shows the TCPs offering the SACK option, > you're not doing TCP Vegas. > > Current standardized TCP (ftp://ftp.rfc-editor.org/in-notes/rfc2581.txt) > assumes that duplicate ACKs are evidence of reordering ("SOMEthing is > getting to the other end and being acknowledged"), so you send another NEW > packet down the connection. > > When you get enough duplicate ACKs in a row (in the standard, the threshold > is "3"), you assume that, in fact, the next unACKed segment DID get lost, so > you retransmit the presumed-lost segment and execute congestion avoidance. > > The general goal in modern TCPs is to use ACK clocking for everything except > RTO ("the ABSENCE of ACK clocking"). The idea is that you can always send a > packet down a connection when you get an ACK, because packets are still > reaching the far end and being ACKed. > > This isn't based on a sender-side clock for duplicate ACKs - the sender only > uses the RTO timer, because when the RTO timer fires, this means you haven't > gotten an ACK for the segment AND you haven't gotten three duplicate ACKs, > so more than one packet may be lost. > > I haven't worked on TCP in a couple of years, but when I was, Linux and > Windows certainly implemented fast retransmit this way (not counting SACK, > which they also implemented). > > I hope this is helpful... > > Thanks, > > Spencer > > > >I wonder if someone here with TCP skillz could help me with an > > implementation question. Apologies if this is off-topic for this > > list, but its answer will help me in p2p hacking. :o) > > > > TCP Vegas, as per http://citeseer.ist.psu.edu/brakmo94tcp.html section > > 3.2, retransmits a packet when it receives a duplicate ACK, if the > > time elapsed since the packet was originally sent exceeds 'the timeout > > value', but doesn't say what this timeout value is. > > > > The implication seems to be that it is RTO, but this makes no sense; > > if RTO had elapsed, the Reno/Tahoe retransmission timer (which Vegas > > retains) would have already fired anyway. So, what value should be > > used for the timeout? SRTT? > > > > Thanks in advance, > > > > Will > > > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers > _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
