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

[Arthur van Leeuwen <arthurvl@sci.kun.nl>]

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/