[Scone] Re: Discussion on TRAIN and SCONE

[Ted Hardie <[e-mail]>]

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.

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.

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