search

panrg / path-properties

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

Remove domain/backbone classification, address #15 and #16 #22

Closed renghardt closed 5 years ago

renghardt commented 5 years ago

This removes the domain/backbone classification, leaving only dynamic and non-dynamic properties.

Right now, dynamic properties relate to the transmission of a specific flow and non-dynamic are everything else - not sure yet if the naming still makes sense this way. Other ideas for definitions or names?

Anyway, I think that this addresses the remaining comments in #15 and #16.

cyrill-k commented 5 years ago

Maybe getting rid of all the classifications is the easiest thing to do, because every time I try to come up with another classification, there is at least one property that applies to both classifications... For example if we simply say relevant for performance vs not relevant for performance, then we have the issue that (almost) all properties are potentially relevant for the performance.

But I think classifying based on how a property expresses the transmission performance might be a good idea. Since for a transmission, the properties (loss, delay, link usage) are what's mostly important and not the underlying properties such as link capacity, disjointness, or access technology that lead to the experienced performance. So we could maybe have transmission performance properties (loss, delay, link usage) vs other properties. Then we could put the other properties first and after that add a subsection for the transmission performance properties. What do you think about this?

renghardt commented 5 years ago

Yes, I think saying that the property expresses transmission performance, so it's a transmission performance property, sounds like a possible classification. Having the other category be "other" properties sounds kind of awkward though, especially having an "other" category that comes first. Or do you mean we don't make the "other" category explicit and simply say that these are examples of path properties, and then there's path properties that specifically express transmission performance? That could work, but then I wouldn't put them in a subsection, because having only a single subsection doesn't really make sense. So, should we get rid of the subsections, have text about the "other" properties first, then list them, then have some text about the transmission performance properties, and list them?

cyrill-k commented 5 years ago

Yes that is what I had in mind to at least provide some structure in this section instead of simply dumping a list of properties ;) I agree that a single subsection looks wierd so separating the performance properties by some text is a good idea.

renghardt commented 5 years ago

Okay, all properties are now in the same section, without any subsections, but separated by text. I chose to keep some text on how properties may be more or less dynamic, with the idea that it's not necessary to have a clear distinction, in the same way properties may apply to path elements close or less close to a host, but we don't have to define "close". Do you think this works?

Also, I removed one sentence from the Introduction because we don't actually have a separate section talking about path property classification anymore.

renghardt commented 5 years ago

Oh, by the way, I got rid of the sentence "Some dynamic properties are defined in different directions for the same path element, e.g., for transmitting and receiving packets." because links are unidirectional now and a single packet is only sent in one direction. Do you agree?

Also, I'm wondering if we want to get rid of the very last property, "Congestion" - I'm not sure if we really need this in our list and I'm not sure it belongs with the transmission performance properties.

cyrill-k commented 5 years ago

The document looks good now. I removed the congestion path property since ECN is already mentioned before and added ethernet MTU as a non-dynamic property.

I agree that it is unnecessary to explicitly mention the direction of a property.

I was thinking whether we want to move "Link Capacity" away from the transmission performance path properties since we are usually interested in the "Link Usage" for the performance. But since these two properties fit together nicely, I would leave it as it is now.

cyrill-k commented 5 years ago

Btw., did the PANRG chairs reply whether we should upload the draft as draft-irtf... or draft-enghardt...?

renghardt commented 5 years ago

Thanks for the further changes, I agree this is ready to go now. I talked to the chairs and we'll submit it as draft-enghardt again this time, then confirm the adoption in the PANRG session. I'll get the submission ready this afternoon.