RE: [PCN] Re: WG Review: Congestion and Pre-Congestion Notification(pcn)

[Pekka Savola <pekkas at netcore.fi>]

On Mon, 19 Feb 2007, Black_David at emc.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.org
https://www1.ietf.org/mailman/listinfo/ietf