On Tue, 13 Feb 2007, IESG Secretary wrote:
[logical components being:] encoding and transport along forward
path from marker to egress, metering of congestion information at
the egress, and transport of congestion information back to the
controlling ingress.
I'd like to see it explicitly stated that transporting congestion
information in the (metered) IP packets themselves is out of scope.
This should exclude designs such as adding IP options en-route,
defining new extension headers, or modifying the packets in any,
currently undefined way. (I say this explicitly because based on a
very quick look at the mailing list archives I saw discussion relating
to IP header encoding and it unnerved me.)
Reaction mechanisms at the boundary consist of flow admission and
flow termination.
In order to do flow admission, you'll first need to recognize a flow.
How do you recognize at the borders (or in the core) which kind of
flows should be considered to be treated as PCN? The mechanisms for
accomplishing this in an operationally feasible way don't seem to be
discussed in the charter.
This may be easy if all the traffic you're interested of is using a
few predetermined (and configured) protocols and port numbers, but I
suspect that is not the case, and layer 7 packet inspection is not an
option either..
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf