Matt is interested in provider performance and technology issues.
There is currently no good way for consumers to measure the performance of a provider in meeting the consumer's needs. So, this working group will attempt to create a toolkit for helping the consumer find the right provider to meet his or her needs.
Volunteers are solicited for a middle manager for the co-chair.
Selective acknowledgement by TCP is not widely deployed. TRENO has an ideal implementation of SACK. Currently, turning off this feature is not possible.
A PSC customer in California is not getting a good transfer rate from PSC. TRENO indicates that there are a large number of retransmissions and timers expiring at various parts of the path. The case presented indicates that the T1 link to the Internet at the user's university site is too small (< 60kbs).
There are some issues about treno's instrumentation. There are also safety issues.
Router requirements -- TTLs need to be be returned at full speed and such things can sell routers. Sean argues that routers are optimized for switching not reporting errors and to get this feature will cause swithing to suffer (or cause them to cost more).
The intent of TRENO is to use the same resources TCP uses. Because of the way certain routers are implemented, that is not the case. However, that will change as more routers are tuned to provide better TTL performance.
It is important that whatever tools are use for measurement actually help overall performance. This way, good measurements indicate good overall performance.
Peter Ford contends that users are not being helped by this. Matt argues that the users he is talking about are really administrators.
TRENO can be found at ftp://ftp.psc.edu/pub/net_tools/treno.shar.