please place your key research questions here

Views: 128

Reply to This

Replies to This Discussion

Loci/methods for congestion control

Congestion control in TCP definitely helps, but it may not be sufficient. In fact, endpoint congestion control may not be sufficient.

One principle of distributed systems exhorts us to place information, power/competence, and incentive together. However effective well executed endpoint control may be, we should expect cases when endpoints are incompetent or even malicious. E.g., a flooding attacker desires congestion, and will hardly co-operate to avoid it.

Owners of forwarders/routers seem to have the most reliable incentive to maintain smooth network operation, and they certainly have the power/competence to drop packets. We should investigate how well they can discover which packets to drop in order to reduce loss of throughput due to congestion.
Ken - one could use automation - as in cognitive networking. One vision for this is "Application-Private Networking" (APNets), where various cognitive mechanisms infer what applications need from the network and configure it
accordingly.


Ken Calvert said:
Postmodern research issues

1. Money flow - how to get money to flow to providers that will inves in infrastructure and new services?

2. How should we build applications to take advantage of new services offered by the network? Can't ask (human) users, applications may not know their requirements, especially a priori. How to allow expression of policies for, e.g., choosing among paths? There are applications that know how to do this -- cf. protocols for video streaming.

3. Performance - how do we add the things we need (motivation, accountability) to the forwarding operation without destroying performance? This is a question about engineering the fast path, but may also have to do with amelioration strategies - e.g., are there ways to avoid doing it in certain cases?
Questions for SILO:

- The claimed enrichment by introducing some amount of "meaning" thorough the ontology also claims to make it more possible to enable diverse (including currently unforeseen) security services, security strategies (services acting in unison), security policies (constraints on what services cannot/have-to act in unison). But this requires some representation of security semantics inside the ontology. What are the security-related information that must be required by the architecture to be in the ontology? Will this be on per-service basis, or something else?

- How does "collected wisdom" get inside the ontology? The ontology is supposed to store information about what services work well or do not work with others. Who is competent to put this information in the ontology? Does/should the mechanism to collect this information into the ontology form part of the architecture?

- How do you know what to optimize? Who is competent to know what metric should be optimized? If there are multiple metrics, who gets to say which one has priority, or higher weight?

Reply to Discussion

RSS

© 2017   Created by David Clark.   Powered by

Report an Issue  |  Terms of Service