Subject: Re: [tsvwg] review of draft-ietf-tsvwg-ecn-tunnel-02 pt 2/2

From: Bob Briscoe <[email-masked]>
Date: Thu, 09 Jul 2009 20:14:28 +0100

David,

Part 2/2...

Thanks for the further comments below. I agree with everything and 
will make appropriate changes, except where I've pushed back below.

At 00:43 09/07/2009, [email-masked] wrote:

[snip egress changes stuff - see previous mail]

>To counter this, the argument in Appendix D) needs to be strengthened;
>I think there's an appeal to the controlled domain/closed system
>nature of PCN - i.e., PCN is only used by an operator who is in
>complete control of everything in the PCN domain, hence can assure
>that all tunnels are 3-ECN-value-compatible.  You haven't said this,
>you need to, and probably in the main body of the draft, not hiding
>in Appendix D).

Yup.

>Section 4.3 should be an Appendix, with the possible exception of
>the paragraph containing the "Don't" guidance.

I don't think moving this to an appendix is the appropriate way to 
deal with future design guidelines. My intent here was to encapsulate 
a tiny informational RFC within a standards track RFC. Gorry went the 
other way to you and asked whether some of the shoulds and should 
nots would be better capitalised.

I need guidance here, as I don't know what is normal procedure when 
including guidelines for future protocol design in a stds track doc. 
I noticed Fred's admitted-realtime-dscp contains a section with 
uncapitalised recommendations, and I figured this is more useful than 
a tiny separate I-D, which would have to "re-load all the state" 
built up within ecn-tunnel.

Possibilities:
1. Drop the whole section
2. Keep it as it is
3. Write a short informational RFC just for this section.
4. Move the bullet points to an appendix, but keep a short guidance 
para in the body.

My position on these:
1. No: ecn-tunnel has achieved an ECN tunnelling behaviour that works 
across a wide range of requirements. This section gives sound advice 
on trying to keep it that way. There is no other better place for 
this advice than in ecn-tunnel, because RFC4774 (alt ecn sematics) 
doesn't cover tunnels.

2. Yes. I think it's fine as it is. I'll sign-post it so implementers 
can skip over it. I'll also cite RFC4474.

3. No. A new I-D would need loads more contextual text copied from 
this one than the actual short piece of guidelines text.

4. May-be. But that just makes the whole doc longer with redundant 
headings and cross-refs and it reduces the force of the guidelines.

>Section 5.2 fails to discuss the 3rd-value incompatibility problems
>caused by a non-upgraded (i.e., 4301-only) egress.  It's correct
>that the 4301-only and new egress behaviors are both compatible
>with a 4301 ingress.  In essence, 5.2 has failed to discuss egress
>behavior changes.

5.2 is about ingress back-compat. 5.1 is about egress, and I believe 
covers what you are asking for.

>The last few paragraphs of Section 5.3 that say it's not enough to
>just implement compatibility mode are going to cause problems

Not at all. This says what an implementor has to do to comply with 
this spec. It says an ingress that always turns off ECN processing 
across a tunnel can't be considered compliant with the ECN-tunnelling spec.

IOW, if a vendor doesn't want to support ECN tunnelling at all, they 
just won't comply with this spec. It doesn't mean they have to 
support ECN tunnelling, it just means they can't claim they comply 
with the ECN-tunnelling spec if they don't.

Surely this is all just stating the obvious.

>(in
>essence, a lot of existing tunnels immediately become non-compliant).

Surely legacy stuff is always non-compliant with new RFCs that update 
the RFC they were coded against. E.g. an RFC2003 tunnel is 
non-compliant with RFC3168. The ingress ECN processing of an 
RFC3168/2401 IPsec tunnel is non-compliant with RFC4301.

>I got a private email from Gorry on basically this point, in which
>Gorry essentially asks (I've added emphasis): How on earth is an
>existing tunnel supposed to negotiate this?

I missed out saying (and I'll add) that I'm not recommending 
negotiation, but I have to recognise that it may exist (because 3168 
introduced it). There are two potential types of tunnel:
* Static: those coded on the assumption that the pair of ends are 
config'd together by the same admin
* Adaptive: those where each end is coded to be able to work with 
whatever other end it encounters as it sets up tunnels driven by the 
demands of arriving packets. E.g. Dynamic TED, which isn't IETF 
standardised AFAIK, but it exists: 
<http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/ted.html>

Existing static tunnels won't have any problem with a new spec; if 
the admin upgrades one, it's up to the admin to upgrade the other at 
the same time.

If an existing adaptive tunnel already negotiates between RFC3168 
limited & full functionality, this spec is designed so a new ingress 
or a new egress "just works" with such a negotiating legacy tunnel endpoint.

>Another way to realize
>that you have a problem here is that you also need to say that
>this draft updates RFC 2003, and moreover does so in a non-backwards-
>compatible fashion.  I'm not going to say it has to come out, but
>attention clearly needs to be called to this in Stockholm.

I say "This specification updates RFC3168 and RFC4301."
And I say "In the RFC index, RFC3168 should be identified as an 
update to RFC2003. RFC4301 should be identified as an update to RFC3168."

Therefore, as this spec updates 3168, which updates 2003, this spec 
updates 2003.

But updating 2003 is not a problem. This new spec is designed to 
ensure a compliant tunnel endpoint will interwork safely with a 2003 
tunnel endpoint at the other end. Whichever end is which.

For the full scary table of all the possible permutations of 
compatibility, see spare slide #11 in the pack I presented at the last IETF:
<http://www.bobbriscoe.net/present.html#0903ecn-tunnel>
As you can see, the new spec interworks with all the possible other 
tunnel endpoints.

>Section 6 needs to deal with RFC 2003.

OK, that's easy to do (I was merely trying to avoid extra text about 
double backwards compatibility, but it's been considered in the 
wording of the rules so it's no problem to explain this).

>Somewhere in Section 5.3 and 6, you ought to discuss RFC 3168's
>update to RFC 2401.  To put it bluntly, this was a failed attempt
>to add ECN egress behavior negotiation to an existing tunnel
>setup protocol (IKEv1 for a tunnel-mode SA).  The result was
>unworkable in practice for overhead and negotiation structure
>reasons, and I suspect it was never implemented.

I'd like to know more about the history here.

By my analysis, an RFC3168 _egress_ never needed to know the mode the 
tunnel was in, because a full mode egress produces the correct output 
in either case:
- limited mode ingress:   outer    = Not-ECT
- limited mode egress:    outgoing = inner
- full mode egress:       outgoing = inner (if outer = Not-ECT)

Before entering full mode, an RFC3168 (or later) _ingress_ does need 
to know it's not talking to a pre-3168 egress which would discard CE 
introduced within the tunnel.

If this implies I need to define how an ingress checks the egress is 
ECN-capable, please tell all!

>Section 8 spends too much text on the ECN nonce.

I agree. The nonce issues within tunnels are a really unimportant 
aspect of the nonce.

But if I don't talk about corner-cases, I'll only get someone on the 
IESG showing off that they've noticed I haven't taken account of a 
corner-case ;)

It's the same with the IKEv2 vs manual keying corner case.

I'll try to say less, but it's hard, because the corner-cases require 
convoluted description of what the case is.

As this is a change to the IP layer, I do feel I have to say at least 
something about anything that it might impact.

>As part of
>discussion in Stockholm, I'd ask about whether this draft should
>be used as an opportunity to declare the ECN nonce (RFC 3540)
>to be Historic.

I don't believe the nonce should be historic until something else 
(e.g. re-ECN) looks like it will replace it. I think it would be 
previous to make it historic otherwise - it's not wrong at all, it's 
just the best that could be thought of at the time.

The nonce is a fine idea, it's just too limited in applicability IMHO 
to be in the IP layer. The nonce only works for e2e transports with 
in-order reliable delivery, and it is only applicable if the sender 
is expected to act in the interests of the common good.

My only concern is if anyone actually implemented the nonce it would 
make re-ECN hard/impossible to deploy. Because with re-ECN a network 
operator is intended to count ECT(1) packets without looking at flows 
(and in re-ECN, ECT(1) has a different meaning to the nonce).

>On rereading this draft from scratch, I'm not clear on why
>Appendix B is included.  I think Section A.2 of Appendix A
>is sufficient (or if not, can be expanded slightly).  Appendix
>B is very abstract, and needs better grounding in actual examples
>(e.g., not saving them until the end).  I'd remove Appendix B.

I've just re-read it and you're right. It can be removed. Others 
wanted shoter appendices, so this solves that problem in a stroke!

>The paragraph in Section A.2 on egress congestion differentiation
>between congestion across a tunnel vs. upstream.  In contrast
>to Appendix B, I think Appendix C is ok in its current form, I
>just don't see the need for it and would remove it.

I'm confused. Do you mean remove appendix B (which I agree with)? Or 
remove appendix C (which I'd rather not)?

Appx C addresses the only concern anyone could have about losing the 
reset behaviour of a 3168 ingress.

>There's some Appendix D discussion above.  In addition to that,
>D.1 needs to be reworked to better acknowledge the current
>2-state PCN direction.

Well, I agree it needs to be updated to acknowledge the current state 
of discussions in PCN (but this isn't just a 2-state direction as I 
explained above).

>Last paragraph in Appendix E needs a little more text to explain
>that what goes wrong is (wrt Fig 6) that "R" marks some traffic
>for removal by setting CE, and then "M" independently marks the
>same fraction of traffic for removal - if there's no overlap in
>the markings, twice as much traffic gets removed as should have
>been.

It's not like this, but this highlights to me that I need to re-write 
that para to explain it better to those that don't know PCN intimately.

>In addition, discussion of this scenario (too much traffic removed)
>probably needs to say something about how/why this can still happen
>despite the controlled domain/closed system nature of PCN (which I
>think needs to be added - see above).

OK.

Thanks v much for this excellent & thoro review. I'm revving -02 to -03 now.

Bob

>Enjoy ;-),
>--David
>
> > -----Original Message-----
> > From: Bob Briscoe [mailto:[email-masked]]
> > Sent: Thursday, June 25, 2009 8:07 PM
> > To: Black, David
> > Subject: Calling in your offer to review draft-ietf-tsvwg-ecn-tunnel
> >
> > David,
> >
> > I noted down that you volunteered to review this one, in a weak
> > moment at an earlier IETF...
> > <http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-ecn-tunnel/>
> >
> > I'd appreciate comments by Mon 6 Jul '09 if poss - when I return from
> > a week off so I can make revs for the IETF deadline the
> > following week.
> >
> > I've substantially re-written it - simplified and cut-down. As with
> > many drafts after a few revs, it needed a complete re-write - all the
> > modifications had got unwieldy and in hindsight most of the
> > justificatory text could be removed to appendices, leaving just the
> > standards action stuff.
> >
> > Cheers
> >
> >
> > Bob
> >
> >
> > ________________________________________________________________
> > Bob Briscoe,               Networks Research Centre, BT Research
> >
> >
> >

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research