Subject: [Tsvwg] ECN with Tunnels - to copy or change the ECN in the outer header

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 27 Jul 2007 08:41:37 -0500

I have a query about the draft on ECN use with Tunnels, relating to the ECN
codepoint copying that I raised in the TSV meeting yesterday.

As I understand, the adjustment to IPsec related only to copying the 2 SCN
bits (plus DS codepoints) from the outer to the inner on ingress and back
again at egress. I agree we SHOULD also do a similar recommendation for
Tunnels in general, and I'd like to see this STD-Track for use in the
General Internet.

However, I am concerned that this draft does not only address these problems
(which could be a PS), but it also adds new concepts as well.

In the ECN architecture, my understanding is that HOSTs choose to set the
ECN field to ECT(0) and ECT(1), depending upon the policy at the sender. ECN
Nonce ( RFC3540) implies a specific semantic to this. The IETF has a BCP
that also says how other alternative semantics may be applied with specific
DS codepoints (RFC4774).

There seem to be two new ideas here. While this may be being considered in
other places, I do not recall it as a part of the original design for ECN:

* The idea that packets from an end host that do not use an ECN-capable
transport can be mapped to an ECT codepoint over a congestion-controlled
tunnel. The current scope of this work in the IETF seems to be scoped only
for use within a PCN domain.

* The idea that packets marked with an ECN codepoint may be remarked to a
different ECN codepoint by some tunnel endpoints, including mapping CE to an
ECT value, and mapping ECT(1) to ECT(0).

  "If the tunnel
   ingress is also a Load Regulator, it MUST instead reset the outer
   header to ECT(0)."

Section 7:
  "The rule that a tunnel ingress MUST copy any ECN field into the outer
   header is a change to RFC3168 (unless it is a Load Regulator as well,
   in which case there is no change)."

The draft describes permitting a mid-box/router to choose to reset the code
point to ECT(0) when it was originally set to some other value.

- So my view on this varies depending on the original value:
N-ECT  -> ECT(0) ... I think this was the goal,
                    but is this safe in the general internet?
ECT(0) -> ECT(0) ... No change
ECT(1) -> ECT(0) ... This contradicts  RFC3540 and RFC4774, and seems
                    like we are limiting options for using schemes
                    currently permitted and options for the future.
CE     -> ECT(0) ... What are the implications of this when transiting
                    a network using ECN or alt. ECN semantics?

Best wishes,

Gorry

---

From: [email-masked]
Date: Sun, 29 Jul 2007 22:42:18 -0400

Gorry,

> As I understand, the adjustment to IPsec related only to copying the 2
ECN
> Tunnels in general, and I'd like to see this STD-Track for use in the

IPsec (RFC 4301) does something slightly different on egress - it only
copies a CE codepoint from outer to inner.  

> for use within a PCN domain.

I tend to agree.  Absent something like PCN that invokes alternate
semantics
for the ECN field, the congestion control for the tunnel would have to
be
TCP-like (reaction to congestion-marked packet is equivalent to reaction
to dropped packet) in order to comply with RFC 3168.
 
>    in which case there is no change)."

Bob and I have had some serious private discussions about this.
IMHO, the charitable conclusion is that the Load Regulator
concept in the draft has not been completely thought through
(after all, it is a "draft"), and I believe Bob is considering
just dropping it from the next version of this draft.

>                     but is this safe in the general internet?

Provided that the tunnel ingress *knows* that the tunnel egress
will do the "right thing" (e.g., drop if outer is marked with CE,
else forward with N-ECT from inner header) this should be ok, but
*knows* can't just be *assumes*.  This is headed in the interesting
direction of running a congestion control feedback loop from tunnel
ingress to egress in a fashion transparent to the end-to-end
congestion control.  There are some details to watch out for, as
a drop could activate both ingress-to-egress and end-to-end
congestion control.

>                     currently permitted and options for the future.

Hmm ... I have the impression that non-support for 3540 (experimental)
is "in play" as a potential part of PCN.  FWIW, 4301 (IPsec) tunneled
the 3540 nonce rather than propagating it through the outer header.
Beyond this, I can't agree with the "contradicts ... RFC 4774"
statement without a much longer discussion ;-).

>                     a network using ECN or alt. ECN semantics?

As long as CE is tunneled through the inner header and not overwritten
at tunnel egress (i.e., end receiver gets CE, not ECT(0) in received
packet), this should be ok, as a router that would otherwise set CE
doesn't do anything different with a packet that is already marked
with CE vs. just marked with ECT.  Dropping a CE-packet doesn't change
the reaction of a correct end-system and is not helpful to a correct
end-system.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 01 Aug 2007 01:50:39 +0100

Gorry,

At 03:42 30/07/2007, [email-masked] wrote:
>Gorry,
>
>>[GF]: I have a query about the draft on ECN use with Tunnels, relating to 
>>the ECN codepoint copying that I raised in the TSV meeting yesterday.
>>
>>ECN bits (plus DS codepoints) from the outer to the inner on ingress and 
>>back again at egress. I agree we SHOULD also do a similar recommendation 
>>for Tunnels in general, and I'd like to see this STD-Track for use in the 
>>General Internet.
>
>[DB]: IPsec (RFC 4301) does something slightly different on egress - it only

[BB]: I deliberately kept the behaviour at the egress unchanged from 
RFC3168 ECN and RFC4301 IPsec (except I added some "MAY warn" statements 
for illegal transitions).

>>[GF]: However, I am concerned that this draft does not only address these 
>>problems (which could be a PS), but it also adds new concepts as well.
>>
>>ECN field to ECT(0) and ECT(1), depending upon the policy at the sender.

[BB]: FYI,  somewhere around the time the ECN spec was in the last stages 
of becoming RFC3168 in early 2001, I discussed with Sally the possibility 
of in-path nodes ('proxies') setting ECT (I think it was off-list, but I 
believe I summarised the conversation to the list). Sally's sensible view 
was that any such behaviour would have to be defined at the time such a 
proxy was defined. That's essentially what the PCN w-g is doing now (back 
then, we were working on what has become PCN, which is why I had an interest).

>>[GF]: ECN Nonce ( RFC3540) implies a specific semantic to this. The IETF 
>>has a BCP that also says how other alternative semantics may be applied 
>>with specific DS codepoints (RFC4774).
>>
>>There seem to be two new ideas here. While this may be being considered 
>>in other places, I do not recall it as a part of the original design for ECN:
>>
>>tunnel. The current scope of this work in the IETF seems to be scoped 
>>only for use within a PCN domain.
>
>[DB]: I tend to agree.  Absent something like PCN that invokes alternate 
>semantics for the ECN field, the congestion control for the tunnel would 
>have to be TCP-like (reaction to congestion-marked packet is equivalent to 
>reaction to dropped packet) in order to comply with RFC 3168.

[BB]: I relegated the stuff about an in-path load regulator to an appendix 
because I didn't want to introduce new stuff, but I did want to somehow 
give advice relevant to the PCN w-g (and possibly PWE3 and CAPWAP who are 
both knocking around ideas about in-path load regulators).

In-path load regulation is often a bad idea, but I didn't want to make that 
judgement in this draft, which is just about how tunnels handle the wire 
protocol. So I wanted to keep it at the level of "In any cases where the 
IETF deems in-path load regulation is sensible, this is what you should do 
with the wire protocol, if the load regulator co-incides with a tunnel 
ingress."

Just before the Chicago IETF, as David says, I realised I'd got the stuff 
about in-path load regulators wrong anyway. I now believe that an in-path 
load regulator would reset CE to ECT *before* any tunnel encapsulation.

I *think* these second thoughts mean that in-path load regulation is 
orthogonal to tunnelling, so I can just remove it from this draft 
altogether. And it can be dealt with in the relevant w-g (e.g. PCN, PWE3 or 
CAPWAP).

But I'd like to allow myself third thoughts when I update to -01. At that 
time, if I leave anything in about in-path load regulators I'll pop it onto 
the list first to get your reaction (and others).

>>[GF]: * The idea that packets marked with an ECN codepoint may be 
>>remarked to a different ECN codepoint by some tunnel endpoints, including 
>>mapping CE to an ECT value, and mapping ECT(1) to ECT(0).
>>
>>   "If the tunnel ingress is also a Load Regulator, it MUST instead reset
>>    the outer header to ECT(0)."

[BB]: Strictly, this idea isn't new. It was the full functionality mode in 
RFC3168. The CE is preserved through the inner header and pops out the 
other end of the tunnel, whatever variant of egress behaviour it encounters.

However, you are right that the idea of an in-path load regulator doing 
this is new (but likely to be removed anyway - so lets not worry about it 
for now).

>>[GF]: Section 7:
>>    header is a change to RFC3168 (unless it is a Load Regulator as well, in
>>    which case there is no change)."
>
>[DB]: Bob and I have had some serious private discussions about this.
>>[GF]: The draft describes permitting a mid-box/router to choose to reset the
>>code point to ECT(0) when it was originally set to some other value.
>>
>[DB]: Provided that the tunnel ingress *knows* that the tunnel egress

[BB]: I agree with David here.

>>[GF]:
>[DB]: Hmm ... I have the impression that non-support for 3540 (experimental)

[BB]: As I point out in the security considerations section of this draft, 
RFC3168 tunnel behaviour currently complicates the ECN nonce anyway, losing 
the sender's nonce protection over the length of the tunnel (noting Sally's 
point in the previous mail that the tunnel egress could detect changes to 
the nonce in these cases). Ideally, I would have redefined the egress 
behaviour to fix this, but I left it as it is, to avoid changing IPsec again.

We could fix the nonce as well, using this draft. But in discussions with 
David B, Bruce Davie and separately with the Transport ADs, the proposed 
plan is to wait until PCN is more mature, then we can take everything that 
might need taking into account, all together.

Current plan is to issue an update to this draft, still as individual 
draft-briscoe-tsvwg-ecn-tunnel-01 to make some necessary corrections to 
this draft that don't depend on where PCN might go, but then leave the I-D 
on hold for at least one IETF cycle to allow us to identify any consensus 
the PCN w-g is converging on regarding header encoding.

[BTW, PCN doesn't need to support the nonce edge-edge because PCN boundary 
nodes don't do predictable edge-edge packet ordering so a binary nonce 
wouldn't work anyway (but PCN may have to preserve an e2e nonce by 
tunnelling the e2e header - this is how I would approach the possibility of 
end-to-end having to coexist with edge-to-edge control loops).]

>>[GF]:

[BB]: This is the way RFC3168 worked: full functionality mode reset CE -> 
ECT(0) at tunnel ingress and ignored which ECT value was in the outer 
header at the egress, instead reinstating the ECT values from the inner header.

>[DB]: As long as CE is tunneled through the inner header and not overwritten

[BB]: A final process note:

As I said in the presentation last week, this draft currently aims to serve 
two purposes that I believe can both sit in one doc intended for PS:
1) A PS to bring 3168 into line with 4301
2) Informational guidance on the tunnelling constraints to consider 
if  defining new ECN field semantics for certain DS PHBs (like PCN) or for 
integrating IP congestion notification with lower layer protocols.

This leads to a potential for gridlock (or a race condition) with the PCN 
working group...

It would be wrong to bring RFC3168 into line with RFC4301 *before* PCN has 
decided its encoding, just in case there is something we can say in this 
ecn-tunnel doc that would ensure all tunnels 'just work' without special 
PCN modifications. IOW, the IETF needs to avoid the possibility of making 
two changes in quick succession to ECN tunnelling. Otherwise, the 
intermediate stage would create yet another tunnel endpoint variant that 
corresponding tunnel endpoints would have to check for.

But I wanted to have the guidance written down to improve the chances of 
the PCN w-g defining an encoding (chartered to be delivered to the IESG by 
Mar'08) so that tunnels would indeed 'just work' without special PCN 
modifications.

Even if I had split this draft into informational and PS parts, the PCN w-g 
need the informational part before Oct'07 for it to be useful. So, is it a 
reasonable approach to get the guidance in as good a shape as possible 
(thru discussions like this on the list) while still remaining as an 
individual draft? Then the PCN w-g can note the guidance in the knowledge 
it might be useful, but it is not fully baked or even formally adopted by 
the IETF. Thus relaxing the potential for gridlock.

Hope this helps.

Cheers

Bob

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196