On Mon, 19 Feb 2007, Black_David(_at_)emc(_dot_)com 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.
Forward transport of the basic congestion information has to be in
scope as Fred has pointed out. Backwards transport needs to be scoped
by application scenario - for example, backwards transport via SIP
is clearly out of scope for the initial PCN work. OTOH, not specifying
how to actually move any of this information around would turn PCN
into the moral equivalent an IRTF Research Group, which (IMHO) would
be bad - at the end of the day, PCN needs to produce something that
actually works (need "running code" in addition to "rough consensus").
It seems that are assuming the transport needs to happen in the packet
itself. While this is a possible approach, I don't see that it needs
to be the only one. For example, a mechanism where the mutually
trusting network components would have another channel to convey this
information (e.g., using SNMP, IPFIX, or the like) might also apply.
However, to be clear, I have no objection to using the ECN field(s) if
that does not hinder the current use (or lack thereof) of ECN. What I
specifically don't want is to define new fields for PCN, especially
extension headers or IP options. I should have been clearer with my
objection.
--
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