[Scone] Re: Discussion on TRAIN and SCONE

[Ted Hardie <[e-mail]>]

Hi Matt,

A clarification in-lin.

On Mon, Dec 9, 2024 at 8:47 PM Matt Joras <[e-mail]> wrote:

> 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.
>

The point I was trying to make wasn't that we should ignore the network
operators in designing this, but that we should avoid defining the format
to encompass all the information a network operator might have available.
That can be a very large amount of data and interpreting it correctly can
require significant context and computation.  We want to design this so
that it elicits the behavior that the client, operator, and server all
want:  the  highest quality media stream that fits within the constraint
gets delivered.

In other words, we don't want to focus on what data is available, we want
to focus on what behavior we want to elicit.

regards,

Ted



> 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]
>>
>