search

panrg / path-properties

A Vocabulary of Path Properties
Other
1 stars 3 forks source link

Motivate why we pick these properties #2

Closed renghardt closed 5 years ago

renghardt commented 5 years ago

The draft should motivate why we choose these particular properties and not others.

Is it because we want to do "better than random" prediction? Or are we just trying to get an idea of the state of a path?

cyrill-k commented 5 years ago

Even though this is not part of our question (vocabulary of path properties), as question 3 & 5 will more closely look at what the actual use cases, I think we should nonetheless mention possible protocols that would benefit from path properties in order to justify our selection of path properties. Then we can argue about useful metrics for the majority of these protocols (e.g., delay, loss, bw, ...) Is this a good approach to motivate our selection?

Which systems profit from path awareness (benefits are mostly performance-wise in these cases)?

What are desirable metrics for these systems?

As a side note, this was mentioned in the ALTO requirement document, RFC 5693, as their goal (the overall goal being a peer selection better than random): Increase application performance, reduce congestion, and decrease the overall amount of traffic across different networks

renghardt commented 5 years ago

I'm hesitant about starting out by naming actual protocols and claiming that our properties will improve their performance in some way. I'm also not sure we need the "What are desirable metrics" part here already, shouldn't that be part of the drafts answering the other questions?

At least I think we want to start with abstract reasons why one might want these properties, and then name some examples. I mean, choosing between different paths is one motivation, but not the only one.

So one reason is that one might want to choose between different paths, for example in routing protocols, where path properties could help influence routing metrics, right? Or on different layers, they could help choose between Transport Layer endpoints or Application-Layer peers. Maybe here we can also state or reference the "better than random" goal. Maybe this motivation shouldn't be the first one we name though, otherwise we end up "predicting the future" again... ;)

I think another reason we might want path properties is network monitoring, e.g., to make sure that we meet some QoS requirements. Before we can improve performance, we need to understand it, so I think this reason should come first.

Another reason might be compliance with some policies, e.g., having a specific device present on the path, or only routing traffic through specific networks.

Maybe let's start with these, and if we come up with more, we can add them?

cyrill-k commented 5 years ago

I removed discussion about desirable metrics and focused on scenarios where path properties are useful.

I created the pull request #6 which so far only consists of the abstract scenarios without any examples. If you think the scenarios are fine this way, we can add examples.

renghardt commented 5 years ago

Closed via #6.