[Scone] Re: Discussion on TRAIN and SCONE

[Matt Joras <[e-mail]>]

Hi Ted,

Couple things inline.

On Sun, Dec 8, 2024 at 4:18 AM Ted Hardie <[e-mail]> wrote:

> Hi Marcus,
>
> Pulling out one point:
>
>
>> The TRAIN format has the obvious benefit of minimizing overhead and
>> simplifying packet modification logic.
>>
>> The SCONE format, on the other hand, offers network element operators
>> more flexibility in setting appropriate rate limits, at the expense of
>> additional packet overhead.
>>
>>
>>
>> With my implementor hat on, I really appreciate the simplicity of the
>> TRAIN format. However, I fear that it will be very difficult to convince
>> operators to design their policies around a table of pre-configured values.
>> Keeping the table of values relevant over time might also be a challenge.
>>
>>
> I don't think we should focus on what the network element operators could
> say; there's quite a lot of variability possible and there are,
> unfortunately, vendors who would love to charge for the knobs, bells, and
> whistles to send complicated signals.
>

We absolutely should focus on what would be usable for network operators,
as they have a crucial role in the deployability of the working group's
output. If the signals provided by SCONE are not useful for a network
operator, either for operational or business reasons, it will not be
adopted. To that end, achieving parity with what they can currently have
available is important. Alternative solutions currently pitched by various
operators include out-of-band signalling that allow them to share arbitrary
limits. Also, whether or not they want to send "complicated signals" SCONE
is only chartered to develop a way to send one particular type of signal,
so I do not see how that is a matter of concern.


>
> Instead I think we have to focus on the receiver of the signals and the
> question of "What can the endpoint do with the information?" and, even more
> specifically on "What can the application do with the information?"  Are
> there really likely to be more than 64 distinct responses from the
> application to the information that there is a shaper in the path?  For
> video, I think the answer is probably "no", because the number of steps up
> or down in video quality is rarely infinite.
>

This is assuming that the only actuation in response is a change in video
quality, but this is not the case. For example, modern video playback of
especially short-form also often involves elaborate pre-fetching schemes to
ensure a good user experience. That is, an operator may set certain
data-rate limits but those do not 1:1 correspond with "move the quality
ladder up or down". It may also result in application decision making such
as "do or do not make this prefetch". This importance is something that has
only emerged in the past couple of years. This is exactly the kind of
unforeseen issue that can happen if we focus on a purely minimal viable
design for the information, as we cannot exactly anticipate what video
applications a couple years from now will need to be able to do with this
information. If we allow for at least a reasonable fixed size for the
advisory information, we will not get ourselves into this trouble.
Obviously this has to be balanced against including "the kitchen sink", but
again, SCONE has strict charter guardrails that prevent this kind of scope
creep.


>
>
> At the cost of some round trips, I think you could get an application
> below a network restriction with the spin bit and one extra bit.  If the
> extra bit is set, your network consumption is too high to be supported by
> the network, so you should lower the video resolution requested or sent.
> If the spin bit flips and the extra bit is still set,  it has to be lowered
> again one more step. Once the bit is unset, your network consumption fits
> within the shaper's constriction and you should continue with that video
> resolution (if it is unset at the beginning of the application-level
> connection, you started within the bounds of the network constriction).
>
> Obviously, that's  not the perfect answer, because we do not want to spend
> the round trips this implies it might take to get within the bounds.  But
> the actual behavior of the application in response to this signal is very
> simple, so sending complicated information to elicit that response probably
> isn't worth it.
> regards,
>
> Ted Hardie
> Path signal enthusiast
>
> _______________________________________________
> Scone mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>