On Tuesday 28 June 2005 12:10 pm, Weeks, Zeke wrote:
> We have two congestion window problems:
> 1. Web100 reports the congestion window size in increments of (what I think
> is?) TCP MSS (~1448 bytes for our Fedora 2 system). Is it possible to
> obtain the "true" calculated value of cwnd in individual bytes rather than
> 'blocks/segments" of 1448 bytes using Web100. If this cannot be done,
> could anybody recommend an alternative? To align our real world data with
> our simulated data, we are hoping to obtain precise cwnd measurements in
> bytes (not segments * MSS).
Linux itself tracks congestion window in packets rather than bytes, so Web100
must always report cwnd in multiples of MSS.
> 2. Rather than recording the current congestion window size at a fixed time
> interval, we are interested in obtaining the value of the congestion window
> only when a TCP event has occurred [where an event would be some TCP
> activity that would cause the congestion window to be altered (increased,
> decreased, or remain constant)]. We are interested in recording changes
> (caused by TCP events) to the current congestion window only. We cannot
> use Web100 cwnd measurements which (I think) can only be obtained based
> upon time interval polling vs. event polling. For instance, assuming that
> we used WatchSender to 'poll' the connection every 0.001 seconds, we would
> NOT be interested in knowing that the cwnd has remained constant for the
> past '0.007' seconds and have ~8 records with duplicate congestion window
> values; we WOULD like to record the change from 'cwnd a' to 'cwnd b' (ex.
> 1448 to 2896). Can Web100 be used to record event-driven data vs.
> time-driven data? If no, are there any alternatives?
This is something we've talked about, but unfortunately at this point it's not
possible.
If you really need to see every cwnd chagne, you have some optoins, but it
will likely involve some hacking. Web100 does have an event notification
system using a netlink socket, which currently notifies of new connections.
It would probably be possible to similarly add in cwnd notification to this
as well.
Also, I know Arnaldo Carvalho de Melo <arnaldo.melo@xxxxxxxxx> has a patch
called OSTRA which can trace arbitrary kernel events. I've never used it,
and at this point I think it's pretty raw and undocumented, but might be able
work for you.
> 3. Does Web100 include the ability to timestamp (NOT a TCP timestamp
> RFC1323) each record that is collected using WatchSender? (not a problem if
> this isn't a built-in feature).
If you have a snap of all variables, you should be able to use the variables
StartTimeSec, StartTimeUsec, and Duration. This can give you
microsecond-resolution timestamps for your snapshots.
> 4. It is obvious that Web100 includes numerous enhancements to the generic
> TCP Reno. I have not been able to find any documentation that reports
> which RFC's a standard Web100 build is in compliance with, as well as any
> additional features. Is a white paper, or some other source available
> which can help me understand the more complicated TCP Congestion control
> mechanisms operating in a Web100 system or a list of Web100 enhancements to
> TCP Reno?
The Web100 patch currently implements Limited Slow Start, High Speed TCP
(these are both from Sally Floyd, see http://www.icir.org/floyd/hstcp.html),
as well as Scalable TCP (http://www-lce.eng.cam.ac.uk/~ctk21/scalable/). It
also gives the ability to directly control the alpha (AI) and beta (MD)
parameters for AIMD control.
Tom Dunigan has a web site documenting his work in this area:
http://www.csm.ornl.gov/~dunigan/net100/.
FYI, it's likely that (most of) this will be supported in Linux 2.6.13 as part
of the new modular congestion control framework, and will be removed from the
Web100 patch.
-John
_______________________________________________
Discussion mailing list
Discussion@xxxxxxxxxx
http://internal.web100.org/mailman/listinfo/discussion
|