Arthur van Leeuwen wrote: > >On Fri, 28 Jun 2002, Patrick McHardy wrote: > >>Hi Arthur, >> >>Arthur van Leeuwen wrote: >> >>>>A TCP usually takes care of this (wraparound after min. 24.8 days), but >>>>this will not be true anymore. if we choose our timestamp clock to >>>>increase once every 1 ms the sign bit will wrap after 5.5 minutes. I'm >>>>not sure what to do about this (this is why i'm writing), does anyone >>>>here have good ideas? I would also be happy about a completly different >>>>approach, somehing totaly passive would be nice .. :) >>>> >>>The completely different approach would be to recognize all TCP streams >>>running through the machine and keep clocks for them: store the most recent >>>RTTM SYN time for a particular stream as well as the current time of the >>>machine when that RTTM time was seen. This will give you a good enough >>>approximation of the clock-skew between what you would put in the RTTM field >>>yourself and what is in there already, allowing you to use the RTTM fields >>>if they already exist. Note that this takes 64 bits, i.e. 8 bytes of storage >>> >>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 ? the reason i came up with this is i want to avoid storing lots of timestamps/myclock pairs, the number i would need to store depends on how many packets fit in the current window, 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. > >Doei, Arthur. > Bye Patrick _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
