ietf-wg-ccwg / rfc5033bis

IETF drafts
Other
4 stars 6 forks source link

Delete redundant section #88

Closed martinduke closed 7 months ago

martinduke commented 7 months ago

Fixes #86

renghardt commented 7 months ago

This makes sense to me, thanks! One small point: Should we require that (or mention that it's good if) the new algorithm compete "fairly" with itself? That's the only nuance I don't see explicitly mentioned in the text post deletion.

nealcardwell commented 7 months ago

This makes sense to me, thanks! One small point: Should we require that (or mention that it's good if) the new algorithm compete "fairly" with itself? That's the only nuance I don't see explicitly mentioned in the text post deletion.

AFAICT this is covered in the previous paragraph? I mean this one:

### Fairness within the Alternate Congestion Control Algorithm.

When multiple competing flows all use the same
alternate congestion control algorithm, the proposal should
explore how the capacity is shared among the competing flows.
Capacity fairness can be important when a small number of similar
flows compete to fill a bottleneck. It can however also not be useful,
for example, when comparing flows that seek to send at different rates or
when some of the flows do not last sufficiently long to approach
asymptotic behavior.
renghardt commented 7 months ago

Oh, right, thanks. Nevermind my question then.

gorryfair commented 7 months ago

Wait a minute, I don't think I agree with this PR: to me: a starvation test isn't a fairness test. To me fairness is about whether a method wisely distributes capacity between the set of flows. Often this is a long-term measurement that can be made by app, if one understands the other flows, i.e.e, once algorithms have converged. e.g. For a web client: One could in principle do this by showing that if there are N flows, a flow converges to 1/N of capacity... Starvation on the other hand is about the effect a flow has on a different flow. I think it may only be relevent when you have a different algorithm or type of traffic. Starvation really is much harder to evaluate in a practical measurement, because it concerns whether the flow has the effect of disrupting another flow so that it does significantly worse (more harm) than flow that would expect. A web client typically does not know if it's CC behaviour disrupts a different multimedia transfer's timing, (unless you dig into the data for that other application (the other sharing flow), which might be with a different IP address/user.

Now I'm not sure this is so clear, in our current text, but we might perjaps need to think in terms of fairness of algorithms to traffic using the method, and harm to other traffic using other algorithms.

martinduke commented 7 months ago

Are you concerned about this for single algorithms or for mixed algorithms?

If the first, we have to delete the first clause. If the second, this should move into the next session.

gorryfair commented 7 months ago

I think I may have changed my mind since we wrote, so there is something to change - I think that harm - aka impact on delay, stravation, etc is pirmarily a concern when competing with other algorithms.

martinduke commented 7 months ago

deleted in favor of #89