Hi all,
I'm planning to start a new branch in which I want to modify Katrina's
rtt-branch. The reason is to measure RTT in a different way.
The idea what I have about RTT is measuring a gap between the time a
segment is seen and the time a segment directly after the corresponding
ack is seen in the monitoring point.
I'm wondering if somebody is working on this at the moment or anybody
already tried this.
Juhoon
The idea what I have about RTT is measuring a gap between the time a
segment is seen and the time a segment directly after the corresponding
ack is seen in the monitoring point.
Can you sketch in more detail (with an example) what you have in mind?
(I've been down this path in the past, and it gets pretty complex!)
Also, what's your ultimate goal: path/performance characterization?
Katrina's is more focused on trouble-shooting, so finding exceptional
values rather than (for example) accurately tracking the RTO computation.
Vern
> The idea what I have about RTT is measuring a gap between the time a
> segment is seen and the time a segment directly after the corresponding
> ack is seen in the monitoring point.Can you sketch in more detail (with an example) what you have in mind?
(I've been down this path in the past, and it gets pretty complex!)
Sorry, my description was not clear enough. Following is an RTT what we
want to measure.
[Sender] [Monitor]-------------(a)------>[Receiver]
[Sender]<-------[Monitor]<--------ack-of-(a)----[Receiver]
[Sender]------->[Monitor]
While Katrina's RTT estimation seems like following:
[Sender] [Monitor]-------------(a)------>[Receiver]
[Sender] [Monitor]<--------ack-of-(a)----[Receiver]
Also, what's your ultimate goal: path/performance characterization?
Katrina's is more focused on trouble-shooting, so finding exceptional
values rather than (for example) accurately tracking the RTO computation.
Yes, our goal is to measure the performance of TCP flows. That's why we
want to measure RTT as accurate as possible.
Juhoon
Sorry, my description was not clear enough. Following is an RTT what we
want to measure.[Sender] [Monitor]-------------(a)------>[Receiver]
[Sender]<-------[Monitor]<--------ack-of-(a)----[Receiver]
[Sender]------->[Monitor]
How will you identify the correct segment for this last component? That's
where it gets quite hard. You need to understand the precise congestion
control algorithm that the Sender implements, along with dealing with
headaches like the second component (ack-of-(a)) being lost between the
Monitor and the Sender, or the Sender imposing a sender-side buffering
limitation or inheriting an initial ssthresh. (A bunch of this is discussed
in my tcpanaly paper from an eon ago.) It really is quite hard, though
it's easier if you can confine yourself to simpler instances such as
only measuring RTT prior to a loss occurring.
Vern
[Sender] [Monitor]-------------(a)------>[Receiver]
[Sender]<-------[Monitor]<--------ack-of-(a)----[Receiver]
[Sender]--(b)-->[Monitor]
I thought that the acknowledgement number of the second component
(ack-of-a) is always the same with the sequence number of the next
segment (b). That is how I wanted to identify the segment (b).
You need to understand the precise congestion control algorithm that the Sender implements,
However, it seems like it is not always the case. I will study more
about this.
(A bunch of this is discussed
in my tcpanaly paper from an eon ago.) It really is quite hard,
Maybe I underestimate this problem. I will restart from the paper.
Thanks.
[Sender] [Monitor]-------------(a)------>[Receiver]
[Sender]<-------[Monitor]<--------ack-of-(a)----[Receiver]
[Sender]--(b)-->[Monitor]I thought that the acknowledgement number of the second component
(ack-of-a) is always the same with the sequence number of the next
segment (b). That is how I wanted to identify the segment (b).
No, instead seq-of-b will be seq-of-a's-ack *plus* the congestion window.
This is where it gets hard.
Vern
Juhoon, this is one of the reasons why I recommended the handshake_sum_estimate event in my branch. It essentially does what you want to do, but just on TCP handshakes. That's because with the handshake we can easily figure out what segment (b) is (it's the ACK to the SYN-ACK). As Vern pointed out, determining (b) is tough in general.
Katrina
Juhoon, this is one of the reasons why I recommended the
handshake_sum_estimate event in my branch.
It essentially does what you want to do, but just on TCP handshakes.
That's because with the handshake we can easily figure out what segment
(b) is (it's the ACK to the SYN-ACK).
Thanks Katrina, but I don't think that an RTT of a TCP handshake represents
the average RTT of a whole flow. One of things we want to know is how it
differs on flow sizes.
As Vern pointed out, determining (b) is tough in general.
Yes, I now realize that it is not that easy as I thought. I think I will
come back to this discussion with a better idea.