Tony,
I answer, since you addressed this to me.
Tony Hain wrote:
>
> Alex Conta wrote:
>
> [...]
> While the original purpose of the proposal for the flow label may have
> been QoS, there is nothing restricting it to that usage.
>
I do not think that the Carpenter/Conta draft tries to exclude anything.
It tries to include Diffserv along Intserv. It is some of the Intserv
supporters that try to keep Diffserv out (excluded).
>
> an end-to-end immutable field
Requesting "immutability" makes sense only when a group of routers on
the path, in a routing domain for instance, are not capable of
preserving the meaning from ingress to egress of that domain, when and
if that
meaning is significant further downstream. If the routers are capable of
preserving the meaning, or there is no significance downstream, then
"mutability" is a non-issue.
So, "immutable" has to be at the most conditional, and therefore not
part of the
main definition.
> which may provide a hint to the routers
> that the sequence of packets with this marking are related
>
> How the routers treat that hint is a local administration issue, and
> outside the scope of any specific QoS model.
If treating the hint is outside the scope of the QoS model, how do we
know how to treat the flow label bits for QoS? That, to me, excludes
QoS, and so it cannot be accepted.
> The routers in the same
> administrative domain of the originating host may treat those as
> intserv bits,
If the bits may be treated as intserv bits, the flow label must be in
the scope of the Intserv model. This contradicts your previous
statement.
Access routers could police/shape the traffic using Diffserv.
> while an intermediate ISP may ignore them, and at the
> same time the destination administrative domain may have enough
> information to treat them as modifiers to a diffserv infrastructure.
Are you saying that the flow label bits can be used by Diffserv? That's
fine, however, there is still a contradiction, in my view, with your
previous "scope" statement.
> The point is they are simply a hint from the originator that packets
> between the src/dst pair are related as far as it is concerned.
This is an oversimplification, and vagueness, with no practical benefit.
At this stage, I do not think, we can afford that.
> The
> only one that may care is the destination host,
So, you provide in the flow label an additional hint to the destination
beside the pair of
ports that are in the host-to-host header? and that hint is using 20
bits of the main network layer header?
Oh NO, I do not think we can afford that for that purpose.
The IPv6 main header is very expensive real estate. Processing at wire
speed in the forwarding and QoS infrastructure is too, too critical,
that's where the flow label must be used.
And then why to duplicate information that the destination host has full
access to anyway (ports, destination options, etc...)?
> [...]
Sorry, without clarification, I could not make sense out of the rest of
what you wrote, so I discarded.
> Tony
Alex
S/MIME Cryptographic Signature
