Subject: [tsvwg] Fwd: RE: draft-ietf-tsvwg-ecn-tunnel: no drop on 4301 decap

From: Bob Briscoe <[email-masked]>
Date: Thu, 30 Jul 2009 16:49:56 +0100

David,

Can we try to resolve your concern over dropping 
ECT(1) outer + Not-ECT inner, fairly soon?

I don't want to send a draft to IPsecME for 
review until we're stable on at least the basic technical proposals.

Bob

>Date: Mon, 27 Jul 2009 00:35:59 +0100
>To: <[email-masked]>
>From: Bob Briscoe <[email-masked]>
>Subject: RE: draft-ietf-tsvwg-ecn-tunnel: no drop on 4301 decap
>Cc: <[email-masked]>
>Bcc: ƒ\In 2009
>
>David,
>
>offlist
>
>At 14:28 26/07/2009, [email-masked] wrote:
>>Bob,
>>
>>I think you may have gone back into the PCN-like behavior swamp
>>by proposing to distinguish ECT(0) from ECT(1).
>>
>>Alternatively, are you arguing that this distinction is
>>necessary in tandem with change b):
>>   [ECT(0) inner + ECT(1) outer -> ECT(1) in resulting header]
>>in order to make 3 ECN codepoints really usable?
>
>Of course. All the MUSTs in any draft should be 
>read as a set of mutually supporting changes.
>
>
>
>
>Bob
>
>
>>Thanks,
>>--David
>>
>> > -----Original Message-----
>> > From: Bob Briscoe [mailto:[email-masked]]
>> > Sent: Friday, July 24, 2009 4:49 AM
>> > To: Black, David
>> > Cc: [email-masked]
>> > Subject: RE: draft-ietf-tsvwg-ecn-tunnel: no drop on 4301 decap
>> >
>> > David,
>> >
>> > Thanks for the insight into the likely reasoning.
>> >
>> >  From a transport perspective, I think now is the right time to say
>> > safety needs greater attention...
>> > - there's a desire to change 4301 decap anyway to support 2
>> > severity levels,
>> > - safety's become more important since 4301 - greater chance
>> > of errors...
>> >
>> > Guys I've talked to in the pseudowire area are considering using ECN
>> > for middlebox to middlebox congestion control (a bit like PCN).
>> > Pseudowires (or PCN) might or might not also require IPsec. But it's
>> > quite an art to turn on ECN across a tunnelled segment and do no harm
>> > in both the following cases:
>> > - if e2e ECN is on, avoiding polluting e2e ECN signals
>> > - if e2e ECN is off, avoiding turning it on
>> > (see recent PCN list).
>> >
>> > This all means the chances that an error will occur increases, either
>> > in broken implementations or broken deployments.
>> >
>> > The new rules in ecn-tunnel are designed so that tunnels should "just
>> > work" and "safely", even if they are deployed by someone who doesn't
>> > know they have to cater for an in-path internal ECN loop as well.
>> >
>> > Q. What do you think of extending drop to both CE and ECT(1) outer if
>> > there's a Not-ECT inner (see table)?
>> > Reasoning: As these are both currently error conditions and likely to
>> > remain so, rather than two different safety rules for different
>> > circumstances just make tunnels safe in all potential cases.
>> > Otherwise someone has to remember to configure a different safety
>> > rule on all their tunnels when PCN or pseudowires get deployed in
>> > their network.
>> >
>> > +----------------+----------------------------------------------+
>> > | Incoming Inner |             Incoming Outer Header            |
>> > |     Header     +---------+------------+------------+----------+
>> > |                | Not-ECT |   ECT(0)   |   ECT(1)   |    CE    |
>> > +----------------+---------+------------+------------+----------+
>> > |    Not-ECT     | Not-ECT | Not-ECT    | Not-ECT    | drop
>> >   |<-3168
>> > |    Not-ECT     | Not-ECT | Not-ECT    | Not-ECT    |Not-ECT
>> >   |<-4301
>> > |    Not-ECT     | Not-ECT | Not-ECT    | drop       | drop
>> >   |<-ecn-tun
>> > +----------------+---------+------------+------------+----------+
>> >                   |                Outgoing Header               |
>> >                   +----------------------------------------------+
>> >
>> >
>> > Bob
>> >
>> > At 22:44 23/07/2009, [email-masked] wrote:
>> > >Bob,
>> > >
>> > > > RFC4301 seems to say: If the inner is Not-ECT, anything
>> > else in the
>> > > > outer must be an error. But whereas RFC3168 dropped the packet if
>> > > > there was CE in the outer, RFC4301 says forward it as Not-ECT
>> > > > in all cases.
>> > > >
>> > > > RFC4301 gives no justification for this rather important
>> > change from
>> > > > RFC3168. I've spent the last hour or so trawling the
>> > IPsec and tsvwg
>> > > > archives and can't find any discussion on this point
>> > either. Was it
>> > > > discussed anywhere?
>> > >
>> > >Not that I recall.  I believe you're looking at a judgment call for
>> > >error case handling.  RFC 4301 was specified with close to the
>> > >minimum necessary to get ECN to work across an IPsec tunnel, as
>> > >security is an area where the default should be leaving out things
>> > >that aren't really necessary.  I believe that handling of this error
>> > >case was essentially treated as a "don't care."  Looking at your
>> > >alternative lines of thought:
>> > >
>> > > > * If the ingress wrongly turned a Not-ECT inner into an ECT outer,
>> > > > then subsequently a congested router marked it CE, then
>> > it's unsafe
>> > > > to remove CE and forward Not-ECT - drop would have been safer.
>> > >
>> > >The ingress is rather unlikely to have put ECT in the outer - that
>> > >clearly violates both RFC 3168 and RFC 4301, and is a bad idea.
>> > >Hence something's almost certainly broken ...
>> > >
>> > > > * If something broken set CE on the outer even tho there was no
>> > > > congestion, it's safe.
>> > >
>> > >If the packet shows up with Not-ECT in the inner and CE in the
>> > >outer, something's definitely broken, even if the breakage is
>> > >actually a bad Not-ECT -> ECT transition followed by a correct
>> > >downstream ECT->CE transition.  Not attempting to perform a
>> > >compensating fix is a reasonable course of action, IMHO ...
>> > >but I could also defend the 3168 drop behavior as within
>> > >reason, along the lines that you suggest.
>> > >
>> > >Thanks,
>> > >--David
>> > >
>> > >
>> > > > -----Original Message-----
>> > > > From: Bob Briscoe [mailto:[email-masked]]
>> > > > Sent: Monday, July 20, 2009 7:48 AM
>> > > > To: Black, David
>> > > > Cc: [email-masked]
>> > > > Subject: draft-ietf-tsvwg-ecn-tunnel: no drop on 4301 decap
>> > > >
>> > > > David,
>> > > >
>> > > > I wanted to move on from optional alarms to my proposed functional
>> > > > changes, ie. your case a).
>> > > >
>> > > > But I have to admit a big error which makes that moot. In
>> > > > ecn-tunnel-02 I incorrectly reported what RFC3168 &
>> > RFC4301 said (I
>> > > > just re-read them). See the table below.
>> > > >
>> > > > IP in IP Decapsulation; Recap of Pre-existing Behaviour
>> > > >+----------------+----------------------------------------------+
>> > > >| Incoming Inner |             Incoming Outer Header            |
>> > > >|     Header     +---------+------------+------------+----------+
>> > > >|                | Not-ECT |   ECT(0)   |   ECT(1)   |    CE    |
>> > > >+----------------+---------+------------+------------+----------+
>> > > >|    Not-ECT     | Not-ECT | drop       | drop       |
>> > drop     |<my error
>> > > >|    Not-ECT     | Not-ECT | Not-ECT    | Not-ECT    |
>> > drop     |<-3168
>> > > >|    Not-ECT     | Not-ECT | Not-ECT    | Not-ECT
>> > |Not-ECT   |<-4301
>> > > >|     ECT(0)     |  ECT(0) | ECT(0)     | ECT(0)     |   CE     |
>> > > >|     ECT(1)     |  ECT(1) | ECT(1)     | ECT(1)     |   CE     |
>> > > >|       CE       |      CE |     CE     |     CE     |   CE     |
>> > > >+----------------+---------+------------+------------+----------+
>> > > >                 |                Outgoing Header               |
>> > > >                 +----------------------------------------------+
>> > > >
>> > > > RFC4301 seems to say: If the inner is Not-ECT, anything
>> > else in the
>> > > > outer must be an error. But whereas RFC3168 dropped the packet if
>> > > > there was CE in the outer, RFC4301 says forward it as Not-ECT
>> > > > in all cases.
>> > > >
>> > > > RFC4301 gives no justification for this rather important
>> > change from
>> > > > RFC3168. I've spent the last hour or so trawling the
>> > IPsec and tsvwg
>> > > > archives and can't find any discussion on this point
>> > either. Was it
>> > > > discussed anywhere?
>> > > >
>> > > > This RFC4301 behaviour seems unsafe, but perhaps
>> > understandable. It
>> > > > all depends how the situation arose:
>> > > > * If the ingress wrongly turned a Not-ECT inner into an ECT outer,
>> > > > then subsequently a congested router marked it CE, then
>> > it's unsafe
>> > > > to remove CE and forward Not-ECT - drop would have been safer.
>> > > > * If something broken set CE on the outer even tho there was no
>> > > > congestion, it's safe.
>> > > >
>> > > >
>> > > >
>> > > > Bob
>> > > >
>> > > > At 12:07 13/07/2009, Bob Briscoe wrote:
>> > > > >David,
>> > > > >
>> > > > >We're getting somewhere (if we set aside (a) for now).
>> > > > >
>> > > > > > At 17:09 10/07/2009, [email-masked] wrote:
>> > > > >> > >Quick summary of the four changes proposed in the draft:
>> > > > >> > >
>> > > > >> > >a) Inner: Not-ECT, Outer: ECT(0)
>> > > > >> > >         RFC 3168/4301: drop(!!!), Change: Not-ECT(!!!)
>> > > > >> > >b) Inner: ECT(0), Outer: ECT(1)
>> > > > >> > >         RFC 3168/4301: ECT(0), Change: ECT(1)
>> > > > >> > >c) Inner: ECT(1), Outer: ECT(0)
>> > > > >> > >         RFC 3168/4301: ECT(1), Change: ECT(1)(!!!)
>> > > > >> > >d) Inner: CE, Outer: ECT(1)
>> > > > >> > >         RFC 3168/4301: CE, Change: CE(!!!)
>> > > > >> > >
>> > > > >> > >If we were designing from scratch, all of these
>> > changes would
>> > > > >> > >be fine things to do.  We're not, and especially after the
>> > > > >> > >discussion of how this impacts RFC 2003 gets added, this
>> > > > >> > >draft will be proposing changes to some of the most widely
>> > > > >> > >deployed mechanisms in the Internet.  To me, that strongly
>> > > > >> > >suggests a conservative design approach - focus on
>> > what really
>> > > > >> > >needs to be changed, and resist them temptation to fix other
>> > > > >> > >things that would be "nice to have".  In other words, IMHO
>> > > > >> > >the appropriate criteria for "fixing it" is a very strong
>> > > > >> > >cast that "it's broken".
>> > > > >> > >
>> > > > >> > >This is an area of principled disagreement on goals between
>> > > > >> > >Bob and myself that list discussion is unlikely to resolve.
>> > > > >> > >My view of the above four changes is that only b) makes it
>> > > > >> > >over the "really needs to be changed" bar (and even then,
>> > > > >> > >only with a *much* stronger statement of the PCN-based
>> > > > >> > >rationale than is in the current draft, and Bob concurs
>> > > > >> > >with strengthening the rationale).
>> > > > >> > >
>> > > > >> > >Turning to the other three changes, a) is clearly described
>> > > > >> > >as "nice to have", enough said.
>> > > > >> > >
>> > > > >> > >For c) and d), I don't believe the optional alarms are
>> > > > >> > >justified based on ECN (RFC 3168) alone.  A key observation
>> > > > >> > >is that this draft does not make the < b) ECT(0) [Inner]
>> > > > >> > >to ECT(1) [Outer], forward with ECT(1) > case subject to an
>> > > > >> > >optional alarm.  What this means is that this draft not only
>> > > > >> > >enables three codepoints (ECT(0), ECT(1) and CE), but it
>> > > > >> > >*assumes* that they are ordered in terms of priority,
>> > > > >> > >severity, or something analogous.  That is unwarranted as
>> > > > >> > >a general design assumption, IMHO.
>> > > > >> > >
>> > > > >> > >For this, reason, I think discussion of which
>> > transitions are
>> > > > >> > >optionally alarm-able in this fashion belongs in
>> > the context of
>> > > > >> > >a protocol that actually orders these codepoints, not in a
>> > > > >> > >general document that would serve to "just constrain future
>> > > > >> > >standards," borrowing Toby's words ;-).
>> > > > >> > >
>> > > > >> > >I could see discussion of optional alarms in an
>> > Appendix that
>> > > > >> > >discusses 3-valued PCN as an example, but not in
>> > the main body
>> > > > >> > >of the draft.  In the main body, it would be fine
>> > to say that
>> > > > >> > >specific uses of the ECN codepoints may assign meanings that
>> > > > >> > >cause some of these transitions to be appropriate for alarms
>> > > > >> > >(and point to the Appendix for a PCN example), but it would
>> > > > >> > >not be ok to constrain the assignment of those meanings by
>> > > > >> > >making the ECT(0) [Inner] to ECT(1) [Outer] change not
>> > > > >> > >optionally alarm-able.
>> > > > >> > >
>> > > > >> > >Thanks,
>> > > > >> > >--David
>> > > > >> > >
>> > > > >> > >
>> > > > >> > > > -----Original Message-----
>> > > > >> > > > From: [email-masked]
>> > [mailto:[email-masked]]
>> > > > >> > > > On Behalf Of Bob Briscoe
>> > > > >> > > > Sent: Thursday, July 09, 2009 3:08 PM
>> > > > >> > > > To: Black, David
>> > > > >> > > > Cc: [email-masked]; tsvwg IETF list
>> > > > >> > > > Subject: Re: [tsvwg] review of
>> > > > >> > draft-ietf-tsvwg-ecn-tunnel-02 pt 1/2
>> > > > >> > > >
>> > > > >> > > > David,
>> > > > >> > > >
>> > > > >> > > > Bringing to the list as agreed. I'll reply in 2
>> > > > parts. Part 1/2...
>> > > > >> > > >
>> > > > >> > > > Your comments get to the nub of the proposed egress
>> > > > >> > protocol changes.
>> > > > >> > > > Great... inline...
>> > > > >> > > >
>> > > > >> > > > At 00:43 09/07/2009, [email-masked] wrote:
>> > > > >> > > > >Bob,
>> > > > >> > > > >
>> > > > >> > > > >Sorry for the delay on this: things got entirely too
>> > > > >> > busy around the
>> > > > >> > > > >end of the quarter here.  Having re-read the draft from
>> > > > >> > scratch, I
>> > > > >> > > > >have a number of things to comment on ... I will be
>> > > > in Stockholm,
>> > > > >> > > > >and some of these items are going to need
>> > further discussion
>> > > > >> > > > >(private and/or public) in Stockholm.
>> > > > >> > > > >
>> > > > >> > > > >Starting with this table in Figure 4:
>> > > > >> > > > >
>> > > > >> > > >
>> > > > >> >
>> > > >
>> > >+------------------+----------------------------------------------+
>> > > > >> > > > >|  Incoming Inner  |             Incoming Outer Header
>> > > > >> >          |
>> > > > >> > > > >|      Header
>> > > > >> > +---------+------------+------------+----------+
>> > > > >> > > > >|                  | Not-ECT |   ECT(0)   |   ECT(1)   |
>> > > > >> >    CE    |
>> > > > >> > > >
>> > > > >> >
>> > > >
>> > >+------------------+---------+------------+------------+----------+
>> > > > >> > > > >|     Not-ECT      | Not-ECT |Not-ECT(!!!)|   drop(!!!)|
>> > > > >> > drop(!!!)|
>> > > > >> > > > >|      ECT(0)      |  ECT(0) | ECT(0)     | ECT(1)     |
>> > > > >> >   CE     |
>> > > > >> > > > >|      ECT(1)      |  ECT(1) | ECT(1)(!!!)| ECT(1)     |
>> > > > >> >   CE     |
>> > > > >> > > > >|        CE        |      CE |     CE     |     CE(!!!)|
>> > > > >> >   CE     |
>> > > > >> > > >
>> > > > >> >
>> > > >
>> > >+------------------+---------+------------+------------+----------+
>> > > > >> > > > >                    |                Outgoing Header
>> > > > >> >           |
>> > > > >> > > > >
>> > > > >> > +----------------------------------------------+
>> > > > >> > > > >
>> > > > >> > > > >My initial focus is on what needs to change from RFC
>> > > > >> > 3168/RFC 4301
>> > > > >> > > > >behavior and why.  Given that these two RFCs line up, I
>> > > > >> > think changes
>> > > > >> > > > >need strong motivation.  So, here are the four
>> > changes, and
>> > > > >> > > > my thoughts:
>> > > > >> > > > >
>> > > > >> > > > >a) Inner: Not-ECT, Outer: ECT(0)
>> > > > >> > > > >         3168/4301: drop (!!!)
>> > > > >> > > > >         Change: Not-ECT (!!!)
>> > > > >> > > > >         Rationale: "allow future standards actions
>> > > > to use this
>> > > > >> > > > >                 combination"
>> > > > >> > > > >         My view: This ain't broke, why are you
>> > fixing it?
>> > > > >> > > >
>> > > > >> > > > It is broke in the sense tunnel egresses unnecessarily
>> > > > >> > drop harmless
>> > > > >> > > > packets merely because they carry a "currently
>> > unused" (CU)
>> > > > >> > > > combination of codepoints. This is similar to the problem
>> > > > >> > ECN faced
>> > > > >> > > > with firewalls dropping packets unless they were Not-ECT.
>> > > > >> > > >
>> > > > >> > > > (a) wasn't originally part of the changes I was
>> > > > >> > proposing. But Anil
>> > > > >> > > > Agawaal convinced me it is worth doing. Reasoning: If we
>> > > > >> > are making a
>> > > > >> > > > change to decap anyway, let's get it as right as
>> > > > possible. If we
>> > > > >> > > > decide not to make any other changes to decap, I wouldn't
>> > > > >> > fight for
>> > > > >> > > > this one alone.
>> > > > >> > > >
>> > > > >> > > >
>> > > > >> > > > >b) Inner: ECT(0), Outer: ECT(1)
>> > > > >> > > > >         3168/4301: ECT(0)
>> > > > >> > > > >         Change: ECT(1)
>> > > > >> > > > >         Rationale: Treat ECT(1) as more severe
>> > congestion
>> > > > >> > > > than ECT(0).
>> > > > >> > > > >         My view: Longer discussion below.
>> > > > >> > > > >
>> > > > >> > > > >c) Inner: ECT(1), Outer: ECT(0)
>> > > > >> > > > >         3168/4301: ECT(1)
>> > > > >> > > > >         Change: ECT(1) (!!!)
>> > > > >> > > > >         Rationale: "no currently legal transition" can
>> > > > >> > > > produce this combo.
>> > > > >> > > > >         My view: Not a good idea, among other reasons
>> > > > >> > > > because it's at
>> > > > >> > > > >                 odds with your "future
>> > standards action"
>> > > > >> > > > explanation for
>> > > > >> > > > >                 the first change.  I'd remove
>> > this change
>> > > > >> > > > and instead deal
>> > > > >> > > > >                 with the possibility of
>> > raising an alarm in
>> > > > >> > > > a PCN-specific
>> > > > >> > > > >                 draft rather than declaring
>> > this to be an
>> > > > >> > > > alarm-able combo
>> > > > >> > > > >                 in general.
>> > > > >> > > > >
>> > > > >> > > > >d) Inner: CE, Outer: ECT(1)
>> > > > >> > > > >         3168/4301: CE
>> > > > >> > > > >         Change: CE (!!!)
>> > > > >> > > > >         Rationale & My view: <same as previous change>
>> > > > >> > > >
>> > > > >> > > > c) & d) aren't PCN specific.
>> > > > >> > > >
>> > > > >> > > > Reasoning for adding alarms (also said this eariler
>> > > > on list in
>> > > > >> > > > conversation with Gorry):
>> > > > >> > > > If security folks have concerns over possible attacks
>> > > > >> > from "currently
>> > > > >> > > > unused" combinations, I want to give them a way
>> > to manage the
>> > > > >> > > > perceived threat without just dropping packets. RFC3168
>> > > > >> > recommended
>> > > > >> > > > alarms for CU combinations. In these cases, I believe
>> > > > >> > RFC3168 simply
>> > > > >> > > > overlooked that these are also CU combinations.
>> > > > >> > > >
>> > > > >> > > >
>> > > > >> > > > >So, I would remove a) as not defensible (no good reason
>> > > > >> > for change),
>> > > > >> > > > >and I would push the discussion of adding alarms for c)
>> > > > >> > and d) into
>> > > > >> > > > >a PCN-specific document.
>> > > > >> > > >
>> > > > >> > > > c) & d) are not to do with PCN.
>> > > > >> > > >
>> > > > >> > > > My motivation is: While making change (b) to enable
>> > > > PCN, lets do
>> > > > >> > > > (a,c,d) to make the IP layer as clean as possible, to
>> > > > >> > ensure easier
>> > > > >> > > > future evolvability.
>> > > > >> > > >
>> > > > >> > > > I don't see the issue. It says SHOULD log and MAY
>> > > > alarm. So the
>> > > > >> > > > operator doesn't have to do anything.
>> > > > >> > > >
>> > > > >> > > > >The c) alarm in particular is only
>> > > > >> > > > >meaningful if PCN or something like it is in use.
>> > > > >> > > >
>> > > > >> > > > No. The combination in c) always was CU, and it's still
>> > > > >> > CU with PCN.
>> > > > >> > > > None of the proposed changes are PCN-specific.
>> > > > >> > > >
>> > > > >> > > > Even (b) is intended to also be useful for any 3-level
>> > > > >> > ECN while not
>> > > > >> > > > precluding 2-level ECN and the nonce.
>> > > > >> > > >
>> > > > >> > > > NB:  3 level = 2 'congested' levels + 1 level not
>> > > > >> > congested, e.g. VCP
>> > > > >> > > > or PCN which were both mentioned in RFC4774. This doesn't
>> > > > >> > count the
>> > > > >> > > > not-ECN-capable state, which makes 4 states.
>> > > > >> > > >
>> > > > >> > > > >I don't view d)
>> > > > >> > > > >as deserving of an alarm in general, as even though
>> > > > something has
>> > > > >> > > > >happened, no damage has been done - this is in
>> > line with the
>> > > > >> > > > >"be liberal in what you accept" principle of
>> > > > protocol design.
>> > > > >> > > >
>> > > > >> > > > That's why I'm proposing an optional alarm. Optional
>> > > > alarms *are*
>> > > > >> > > > liberal, but they allow operators a way to address
>> > > > >> > security concerns
>> > > > >> > > > about 'known unknowns' [Rumsfelt], while still
>> > allowing new
>> > > > >> > > > behaviours to be introduced.
>> > > > >> > > >
>> > > > >> > > >
>> > > > >> > > > >That leaves b), which I think is the key desired
>> > > > change, because
>> > > > >> > > > >it makes a third ECN code point usable through tunnels.
>> > > > >> > > >
>> > > > >> > > > Yes - exactly.
>> > > > >> > > >
>> > > > >> > > > >Much as
>> > > > >> > > > >this might be useful for PCN, it may be too late to
>> > > > do this.  The
>> > > > >> > > > >problem starts from the need to say that this draft
>> > > > >> > updates RFC 4301.
>> > > > >> > > > >The result will be a mix of 4301 and updated-4301
>> > > > implementations
>> > > > >> > > > >that render the third state difficult to use in
>> > > > practice.  The
>> > > > >> > > > >problem's even worse for non-IPsec tunnels.
>> > > > >> > > >
>> > > > >> > > > The idea is that an operator wanting to implement
>> > > > PCN will have a
>> > > > >> > > > spec they can point to in their invitation to
>> > > > tender. At the same
>> > > > >> > > > time this spec both UPDATEs and is backward compatible
>> > > > >> > with RFC3168 &
>> > > > >> > > > RFC4301 because it only changes CU stuff at egress and
>> > > > >> > the change at
>> > > > >> > > > the ingress leads to the same output at the egress.
>> > > > >> > Therefore vendors
>> > > > >> > > > can update 3168 & 4301 tunnels lazily - only when their
>> > > > >> > customers ask
>> > > > >> > > > for the new features (whether for PCN or for something
>> > > > >> > else like VCP).
>> > > > >> > > >
>> > > > >> > > > >I also read Appendix D
>> > > > >> > > > >as saying that PCN is going the two-state
>> > route, not three.
>> > > > >> > > >
>> > > > >> > > > That's not how it should be read - I'll clarify it. The
>> > > > >> > PCN w-g wants
>> > > > >> > > > 3 states, but can't have them while ecn-tunnel is
>> > > > not proposed
>> > > > >> > > > standard. Therefore, it has decided to define a 2-state
>> > > > >> > baseline and
>> > > > >> > > > a number of experimental schemes to work round this
>> > > > tunnel issue
>> > > > >> > > > (plus a comparison doc about them all). It has agreed
>> > > > >> > that eventually
>> > > > >> > > > just one experimental scheme will be chosen for
>> > > > standards track:
>> > > > >> > > > - 3-in-1 (the simplest, which depends on (b) of
>> > ecn-tunnel)
>> > > > >> > > > - 3-state (which uses an extra DSCP)
>> > > > >> > > > - psdm (which requires out of band state)
>> > > > >> > > > - sm (single marking gets 3 functions from 2
>> > > > encoding states but
>> > > > >> > > > admits admission control & termination aren't
>> > very precise in
>> > > > >> > > > all cases)
>> > > > >> > > >
>> > > > >> > > > ___
>> > > > >> > > > See part 2/2 for responses to your comments on
>> > specific parts
>> > > > >> > > > of the test.
>> > > > >> > > >
>> > > > >> > > > Thanks again for the review
>> > > > >> > > >
>> > > > >> > > >
>> > > > >> > > > Bob
>> > > > >> > > >
>> > > > >> > > >
>> > > > >> > > >
>> > > > >> > > >
>> > > > ________________________________________________________________
>> > > > >> > > > Bob Briscoe,               Networks Research Centre,
>> > > > BT Research
>> > > > >> > > >
>> > > > >> > > >
>> > > > >> > > >
>> > > > >> >
>> > > > >> >
>> > ________________________________________________________________
>> > > > >> > Bob Briscoe,               Networks Research Centre,
>> > BT Research
>> > > > >> >
>> > > > >> >
>> > > > >> >
>> > > > >
>> > > > >________________________________________________________________
>> > > > >Bob Briscoe,               Networks Research Centre, BT Research
>> > > >
>> > > > ________________________________________________________________
>> > > > Bob Briscoe,               Networks Research Centre, BT Research
>> > > >
>> > > >
>> > > >
>> >
>> > ________________________________________________________________
>> > Bob Briscoe,               Networks Research Centre, BT Research
>> >
>> >
>> >
>
>________________________________________________________________
>Bob Briscoe,               Networks Research Centre, BT Research

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research