Re: [tsvwg] comment on draft-ietf-tsvwg-ecn-tunnel

[<philip.eardley at bt.com>]

David

<< 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".
>>

yes. 
My default assumption is that both PCN:ECN(1) and PCN:CE kick in before
any actual congestion occurs - where congestion means the queue
overflowing or it means the queue growing such that AQM would mark or
drop the pkt. 

At the end you say you want to work through "this issue" - please could
you clarify what issue you mean, as I don't think I get it right. For
instance, where you say "I'm not comfortable with PCN:ECT(1) being
treated like ECN:CE" - I thought treatment here meant "treatment by
tunnels" but your other comments seem to be more about the whole
behaviour of PCN vs ECN

Thanks
[phil



-----Original Message-----
From: tsvwg-bounces at ietf.org [mailto:tsvwg-bounces at ietf.org] On Behalf
Of Black_David at emc.com
Sent: 14 October 2009 18:37
To: Briscoe,RJ,Bob,XVR9 BRISCORJ R
Cc: tsvwg at ietf.org; Black_David at emc.com
Subject: Re: [tsvwg] comment on draft-ietf-tsvwg-ecn-tunnel

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 
> 
> 
>