Bob (and Phil),
This is the core of what we need to work through:
> I hope Phil's response helped you here. We want PCN:ECT(1) to mean
> "no more inelastic traffic than this" while PCN:CE will mean "reduce
> inelastic traffic due to loss of capacity". ECN:CE encompasses both
> meanings because it is for elastic traffic that will reduce then
> immediately try to increase again.
ECN:CE means "reduce traffic". If one looks at RED as an example
of the sort of AQM that works well with ECN, ECN:CE signals that
queue occupancy is above the desired operating point and traffic
needs to be reduced in order to move towards the operating point;
it's not sufficient to only not add additional traffic. The
attempted increase in elastic traffic will subsequently happen on
a significantly longer time scale (e.g., it will not immediately
try to restore the old throughput), as the process is AIMD, not MIMD.
So, I'm comfortable with PCN:CE being treated like ECN:CE. I'm not
comfortable with PCN:ECT(1) being treated like ECN:CE, as I expect
PCN to be setting it earlier (wrt increasing traffic level) than
ECN:CE (i.e., the P in PCN stands for "pre"). If the queue occupancy
is above the desired operating point (criteria for setting ECN:CE),
PCN:ECT(1) isn't going to help, because it only stops the situation
from getting worse (unless we assume that the inelastic traffic
is composed of short-lived "mice" resulting in continuous occurrence
of flow termination), so PCN:CE will need to be used in order to
obtain improvement.
This is also consistent with Phil's response in which he describes
PCN:ECT(1) as kicking in before congestion occurs - wrt this fuzzy
notion of congestion occurring, ECN:CE kicks in as congestion occurs,
not before, and this distinction is aligned with the P in PCN standing
for "Pre".
Let's get through this issue, then we can figure out how to apply
the result to tunnel egress handling.
Thanks,
--David
> -----Original Message-----
> From: Bob Briscoe [mailto:rbriscoe at jungle.bt.co.uk]
> Sent: Friday, October 09, 2009 7:02 AM
> To: Black, David
> Cc: tsvwg at ietf.org
> Subject: RE: [tsvwg] comment on draft-ietf-tsvwg-ecn-tunnel
>
> David,
>
> At 19:14 04/10/2009, Black_David at emc.com wrote:
> >Bob,
> >
> > > >Let me suggest that if PCN will use ECT(1) to indicate a level of
> > > >congestion comparable to CE for ECN (non-PCN) traffic, then this
> > > >difference is justified, otherwise, I would forward with Not-ECT
> > > >in both cases to avoid dropping traffic that isn't
> causing non-PCN
> > > >congestion.
> > >
> > > OK. PCN indeed wants to use ECT(1) as comparable to CE, but can't
> > > with tunnels as they are.
> >
> >For ECN, CE means "I would have dropped this packet, endpoints should
> >react as if it had been dropped." By comparable, I don't just mean
> >that it indicates congestion, but that the indication is at least as
> >severe as "I would have dropped this packet (e.g., if it had been
> >marked Not-ECT)."
> >
> >I need to find the time to review the PCN material to check this;
> >I think that's the next step.
>
> I hope Phil's response helped you here. We want PCN:ECT(1) to mean
> "no more inelastic traffic than this" while PCN:CE will mean "reduce
> inelastic traffic due to loss of capacity". ECN:CE encompasses both
> meanings because it is for elastic traffic that will reduce then
> immediately try to increase again.
>
>
> > > For the avoidance of doubt, when you say "this difference is
> > > justified", do you mean for all tunnels, or only for
> tunnels within a
> > > PCN domain?
> > >
> > > This seemed to be the difference in our positions before - I'm
> > > playing safe in case a PCN config'd router appears outside a PCN
> > > domain
> >
> >Mumble ... another view of "playing safe" by dropping questionable
> >traffic is creation of an unexpected traffic black hole ... it's
> >not always "safe" to drop.
>
> That is certainly true. But it's bad spec writing to leave this
> choice hanging for a combination that currently isn't valid. It is
> incumbent on us to clearly say what kit should do if unexpected
> combinations appear. Otherwise future protocol design has to assume
> drop might happen anyway.
>
> For Not-ECT inner the draft makes it clear:
> forward ECT(0) outer; drop ECT(1) outer
>
> The question is, do you agree?
>
> It seems like you are conditionally agreeing below. The condition
> being whether we bless PCN usage of ECT(1). PCN marking & baseline
> encoding have just passed IESG review this week. The question is do
> you want to bless PCN usage of ECT(1)? Not just PCN, but any future
> protocol that wants two-level congestion severity.
>
>
> > > - with the added benefit of zero config.
> >
> >IMHO, if we're going to bless PCN usage of ECT(1) as another form of
> >CE, then zero config is desirable, and what you want to do
> is probably
> >what needs to be done. If we are going to bless that PCN usage,
> >we will need to say so clearly and bluntly in the ecn-tunnel draft.
>
> OK. Once this thread completes, I'll do a minor text rev. I'm
> good at blunt :)
>
> Would something like the change below be sufficient? Remember this is
> in addition to all the motivation using PCN that's already in
> ecn-tunnel-03. Pls search thru for the string "PCN".
>
> s/ The above logic allows for ECT(0) and ECT(1) to both represent the
> same severity of congestion marking (e.g. "not congestion
> marked").
> But it also allows future schemes to be defined where ECT(1) is a
> more severe marking than ECT(0). This approach is discussed in
> Appendix D and in the discussion of the ECN nonce [RFC3540] in
> Section 9, which in turn refers to Appendix F.
>
> / The above logic allows for ECT(0) and ECT(1) to both represent the
> same severity of congestion marking (e.g. "not congestion
> marked").
> But it also allows future schemes to be defined where ECT(1) is a
> more severe marking than ECT(0), in particular enabling
> the simplest
> possible encoding for PCN [I-D.ietf-pcn-3-in-1-encoding]. This
> approach is discussed in Appendix D and in the discussion of the
> ECN nonce [RFC3540] in Section 9, which in turn refers to
> Appendix F.
> /
>
> >FWIW, this decision about whether ECT(1) can be another form of CE
> >will probably also mostly resolve the dangling topic of what
> >transitions may generate alarms.
>
> Once you've replied to this one, I'll dig out the old thread on that
> and re-post it.
>
>
> Bob
>
>
> >Thanks,
> >--David
> >
> >
> > > -----Original Message-----
> > > From: tsvwg-bounces at ietf.org [mailto:tsvwg-bounces at ietf.org]
> > > On Behalf Of Bob Briscoe
> > > Sent: Thursday, October 01, 2009 5:32 AM
> > > To: Black, David
> > > Cc: tsvwg at ietf.org
> > > Subject: Re: [tsvwg] comment on draft-ietf-tsvwg-ecn-tunnel
> > >
> > > David,
> > >
> > > At 07:28 30/09/2009, Black_David at emc.com wrote:
> > > >Bob,
> > > >
> > > >I started out to write a much longer message, but I'm ok
> with much
> > > >of what you've written. The only case where I think we
> aren't yet
> > > >aligned on function (we can come back to alarms) is I think that:
> > > >
> > > > > > > >- Not-ECT [inner]: ECT(0) [outer] and ECT(1)
> [outer] should
> > > > > > > > have the same behavior. That behavior
> > > could be Forward
> > > > > > > > with Not-ECT or Drop.
> > > >
> > > >Whereas you want to Forward with Not-ECT in the ECT(0)
> [outer] case
> > > >vs. Drop in the ECT(1) [outer] case. Both of these are
> error cases.
> > > >
> > > >Let me suggest that if PCN will use ECT(1) to indicate a level of
> > > >congestion comparable to CE for ECN (non-PCN) traffic, then this
> > > >difference is justified, otherwise, I would forward with Not-ECT
> > > >in both cases to avoid dropping traffic that isn't
> causing non-PCN
> > > >congestion.
> > >
> > > OK. PCN indeed wants to use ECT(1) as comparable to CE, but can't
> > > with tunnels as they are.
> > >
> > > For the avoidance of doubt, when you say "this difference is
> > > justified", do you mean for all tunnels, or only for
> tunnels within a
> > > PCN domain?
> > >
> > > This seemed to be the difference in our positions before - I'm
> > > playing safe in case a PCN config'd router appears outside a PCN
> > > domain - with the added benefit of zero config.
> > >
> > > Put another way, are you happy with the text in S.4.2
> <ecn-tunnel-03>
> > > for decap cases with a Not-ECT inner?
> > >
> > > >I'm presuming that CE has comparable ECN and PCN
> > > >meanings, justifying Drop for traffic that arrives with
> CE [outer]
> > >
> > > You presume correctly.
> > >
> > >
> > > Bob
> >
> >[... remainder snipped ...]
>
> ________________________________________________________________
> Bob Briscoe, BT Innovate & Design
>
>
>