Hi, On 2009-10-13, at 23:32, Matthew J Zekauskas wrote:
My thoughts are similar to Henk's. IPPM has always been interested in the area (see the bulk transport capacity work), so I'd claim the area is in-scope, but doing work would require AD discussion.
I think it wouldn't be unreasonable for IPPM to take this on, if we more clearly nail down what "this" is. I can also follow the argument that it could go into PMOL - to me, it doesn't matter very much, although since we're talking TCP I believe there is a stronger affinity with the transport area, i.e., IPPM.
I think Matt Mathis' last message to the list is also worth thought; it's hard to create a good metric.
I agree that while the idea sounds simple, in reality it isn't. It already starts to get complicated when we try to say what we mean by "TCP" - pretty much all stacks implement a different set of TCP extensions, and even stacks that implement the same extension usually implement a different set of the SHOULDs and MAYs. Other stacks (e.g., Linux) even implement a congestion control scheme that is completely non-standard (Cubic).
If the intent is to look at bulk throughput figures on otherwise idle paths with little to no loss, maybe those differences won't matter, but they will start to influence the result in more realistic scenarios.
So while I can see why TCP throughout metrics would be interesting to have, I believe it'll take a bit of work to define them in a useful way.
Lars
Attachment:
smime.p7s
Description: S/MIME cryptographic signature