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

[Patrick McHardy <kaber@trash.net>]

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/