Bob and Phil,
I've pulled out just the topics that I think need discussion:
> Over the last few months, our conversation has been progressing like
> two guys at each end of a blunt saw. Can we try to reach a conclusion
> on each of the three 'cuts' below? I shall be posting a rev
> before Monday.
Let's see if this sharpens the saw. I apologize for the delays on
my part - the people who pay my salary expect me to do my day job
for some strange reason :-). I will not be in Hiroshima (can't
justify the travel, sorry).
> 1/
> >[DB] I'm not comfortable with PCN:ECT(1) being treated like ECN:CE,
> >as I expect PCN to be setting it earlier than ECN:CE. If the queue
> >occupancy is above the desired operating point, PCN:ECT(1) isn't
> >going to help, because it only stops the situation from getting worse
>
> [BB] You may not be aware that PCN has two threshold bit-rates: a
> lower one when PCN:ECT(1) is triggered meaning 'stop admission' and a
> higher one when PCN:CE is triggered, which means 'terminate flows'.
I have been aware of that. PCN:CE causes reduction of traffic load in
a fashion similar to ECN:CE. PCN:ECT(1) is a indication of less severe
congestion that is triggered earlier as congestion increase. IMHO, it
therefore does not directly correspond to ECN:CE.
> Anyway, (paraphrasing Phil Eardley) are you uncomfortable about
> 'treatment' in the sense of tunneling treatment (wire protocol), or
> is this about PCN marking algo treatment, which ought to move
> to the PCN list?
The former. How PCN marks packets is specified in PCN documents, and
should not be changed here. I clearly used poor words in leaving you
and Phil with the impression that I wanted to change PCN - that was
*never* my intention (sorry).
My concern is based on the following two points:
(A) I agree with reasoning of the form "<X> needs to be done for ECN:CE,
therefore it needs to be done for PCN:CE." That's has to be
valid, because if it were not, PCN would not have used the CE
codepoint.
(B) I do not agree with reasoning of the form "<X> needs to be done
for ECN:CE and PCN:CE, therefore it needs to be done for
PCN:ECT(1)."
As noted above, PCN:ECT(1) is not a directly comparable
congestion
indication to either ECN:CE or PCN:CE.
The immediate consequence of this is that we disagree on the treatment
of Inner:Not-ECT/Outer:ECT(1). I view the arguments for Drop in this
case as instances of the (B) reasoning that I do not agree with. Hence
I prefer the treatment of this case to be forwarding with Not-ECT (!!!)
[exclamation points indicate unusual case that gets logged/alarmed.]
OTOH, this is splitting hairs over an error case [i.e., (!!!)]. If I'm
the only person with this concern, at some point the chairs should
declare that I'm on the "rough" end of "rough consensus" and that'll
be that - this issue is not worth the time of the ADs or IESG.
> 2/
> >[DB]> >If we are going to bless that PCN usage,...
> >
> >[BB]> For Not-ECT inner the draft makes it clear:
> > > forward ECT(0) outer; drop ECT(1) outer
> > >
> > > The question is, do you agree [to bless that PCN usage]?
Not in that fashion - see above.
> 3/
> >[DB] > >...we will need to say so clearly and bluntly in the
ecn-tunnel draft.
> >
> >[BB]> 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.
> > > /
Independent of our other discussions, I think that text change should
be made, as it clearly states the primary motivation for some of the
changes, and I see that it's been done in the -04 draft.
We have one more issue, pulling text out of an earlier message:
> 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.
That issue surrounded what to do when the inner and outer headers
have different ECT values. PCN uses Inner:ECT(0)/Outer:ECT(1), but
has no use for the other case, Inner:ECT(1)/Outer:ECT(0).
The log/alarm behavior in Figure 4 of the -04 draft is somewhat
alarming ;-) ;-).
Clearing ECT(1) to Not-ECT doesn't get logged or raise an alarm,
but clearing ECT(1) to ECT(0) does, while clearing CE to Not-ECT
doesn't. Before you write a long response, I'm aware that the
explanations of what does vs. does get the log/alarm treatment
involve what happens when a new tunnel decapsulator is paired with
one of the two RFC 3168 encapsulator variants, but the result is
still strange and possibly of limited value for PCN.
Let me suggest a blunter alternative:
- Only log/alarm (!!!) by default the transitions away from Not-ECT
in the inner header (first line in Figure 4, 3 right hand
boxes).
These are just plain wrong, no matter what.
- Do not alarm any other combinations by default. That puts a rapid
end to this discussion.
- Provide an explanation (in an Appendix?) about what to alarm in a
controlled PCN environment. The short summary is that because
PCN has to be deployed in a closed/controlled network, it's
reasonable for the operator to know (in some cases) that there
are no RFC 3168 encapsulators, and therefore be confident I
explicitly enabling a considerably more aggressive log/alarm
approach that catches all reduction/removal of congestion
markings by comparison to what's in Figure 4.
If this is done, I think the current Appendix F can be bit-bucketed,
and that's probably an improvement.
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
black_david at emc.com Mobile: +1 (978) 394-7754
----------------------------------------------------