Re: [LARTC] [OT]: rtt measurement using tcp timestamps from a MITM

[Patrick McHardy <kaber@trash.net>]

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 ?

There a two problems with this,
first it assumes the remote clock is incremented at the same rate as 
mine which will not be true most of the time.
Second RFC1323 requires the host to only update its estimated rtt if it 
receives an echo to an timestamp it sent out before (=exact echo),
although linux for example doesn't seem to validate the echoed value.
Perhaps i should syncronize somehow to the remote clock, by calculating 
the clock-skew and the factor between the two clock-rates.
But there the problem would be that the clock-rate-factor is already 
influenced by the roundtrip time, so i guess it's not really suited to 
measure it afterwards ..

>
>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 :)

>
>Doei, Arthur.
>
Thanks for your help,
Patrick


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/