From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arthur van Leeuwen Date: Mon, 01 Jul 2002 08:05:40 +0000 Subject: Re: [LARTC] [OT]: rtt measurement using tcp timestamps from a MITM Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org On Fri, 28 Jun 2002, Patrick McHardy wrote: > Arthur van Leeuwen wrote: > > > > >On Fri, 28 Jun 2002, Patrick McHardy wrote: > > > >>Hi Arthur, [snip, RTT estimation from router] > >>I hope i got you right, you mean i should calculate the difference > >>between my clock and the first timestamp of a session, then > >>send my own and on reply substract the clock-skew again ? > >> > > > >No, that is active intervention again. I meant to *remember* the value of > >your clock and the last seen RTTM field for a session, and then when > >the corresponding ack returns use that remembered value as opposed to the > >the value in the RTTM field for your round-trip time calculation. > > > >>>per TCP stream, and tracking of all active TCP streams running through your > >>>machine. However, the latter is probably necessary *anyway* if you are > >>>going to do rate control, as you're bound to want to store the windowsizes > >>>and stuff related to each TCP stream separately. > >>> > > > >>Yes connection tracking is necessary (and already working fine :) > >> > > > >Well, what you do then is (in pseudocode): > > > > if packet contains RTTM field: > > if packet is SYN: > > remember local time (RTTM value, TCP stream) > > send packet on > > else: > > lookup local time for (TCP stream, RTTM value) > > calculate round-trip with local time > > else: > > do whatever you like > > > >Thereby you merely use the value in the RTTM field as a key to a set of > >stored local clockvalues. Yes, this will break if the value in the RTTM does > >not monotonically increase, but... that increase *is* guaranteed by the RFC. > hmm i suppose with "if packet is SYN" you mean "if packet contains new > data", right ? Well, I mean `if packet contains new RTTM timestamp'. However, I didn't think this through all that well: you want to store the last seen RTTM field in each direction of a TCP stream. > the reason i came up with this is i want to avoid storing lots of > timestamps/myclock pairs, You'll have to store 2 per TCP stream, one for each direction. > the number i would need to store depends on how many packets fit in the > current window, No. You only need to store the one for each window. Thus, upon store, have a counter count acks, and remember the new RTTM field only when the counter drops below the number of packets that fit in the window. Although round-trip-time may vary per packet, the approximation is probably still good enough. > so for bigger windows i would have to remember lots of values. > Remebering only the first one wouldn't work because i had to rely on the > remote clock to increase excactly as fast as mine. Why? The remote clock doesn't do *anything* to the RTTM field. As I read the RFC a host has to copy the RTTM field back verbatim into the ACK to the packet that contained it... as such, you *only* rely on your own clock to measure roundtrip time. Doei, Arthur. -- /\ / | arthurvl@sci.kun.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/