Talk:TSSP Framework

From ReddNet
Revision as of 13:43, 20 December 2007 by Hunterh (talk | contribs) (New page: "Here are some comments on your specification page: 1. I think it would be good to list all of the possible actors and their roles at the beginning of the description. Some of the actors...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

"Here are some comments on your specification page:

1. I think it would be good to list all of the possible actors and their roles at the beginning of the description. Some of the actors you have listed (such as the "route generator" may not exist yet, which means that perhaps we should not include them in this document.

2. You should come up with another name/description for the IBP client, one which describes its function, not its implementation. "Data source" and "Data destination" might be two such roles (notice that there are two roles even though a single protocol is being used).

3. Your description of the "Steps" for the various operations is very high level, and some protocols that fit the description definitely would not work, certainly not achieving acceptable performance. For instance, the multistream TCP download implemented in LoRS is quite complex, with a number of optimization parameters. Now, we might not want to standardize on a protocol with all that complexity but on the other hand we might want to. If not, then how much complexity do we want to require? And do we want to specify the full protocol as an optional variant of a simpler one?

4. It's not clear to me why you refer to storage space as bandwidth. This is not standard terminology even when dealing with communication buffers, as far as I know. It certainly doesn't fit the scenario when storage allocations are used to implement persistent files (unless you mean to characterize a file as a "channel through time" which is a nice image, but one that few people outside of Claxton Hall will understand).

5. Your Teardown operation seems to be the only way to truncate the duration of storage allocations. What if a user simply deletes the exNode without doing the truncation? Remember, this may happen due to client error, so a protocol that rules it out cannot be implemented reliably.

6. Why do you need both Teardown and Duration? The former seems like a special case of the latter.

7. I think that some open issues include what sorts of up/download algorithms are considered acceptable. If there is a single-stream implementation that gets really terrible performance and sometimes doesn't succeed when more sophisticated algorithms succeed, is that an acceptable implementation (becauase when it does succeed it delivers the correct bits).

8. The relationship between resources on a single depot needs to be specified. Are they necessarily independent or can they be linked (eg having resource zero represent the union of the other resources). " - Micah 12/20/07