Subject: Re: [Tsvwg] ECN with Tunnels - to copy or change the ECN in the outerheader

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 01 Aug 2007 17:56:24 +0100

Responding to David and Bob together,

On 1/8/07 01:50, "Bob Briscoe" <[email-masked]> wrote:

> 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.
>>> 
>>> As I understand, the adjustment to IPsec related only to copying the 2
>>> 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
>> copies a CE codepoint from outer to inner.
> 
> [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).
> 
OK

>>> [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.
>>> 
>>> 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.
> 
> [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).
> 
I haven't seen a discussion of this in the context of general internet use
for tunnels. I know that the ECN work includes these ideas within a
"domain".

>>> [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:
>>> 
>>> * 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.
>> 
>> [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).
>
So, this is draft -00, I'd be interested to see how this develops.

>>> [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.
> 
Right.

An alternative could be that the tunnel could copy ECT(0), ECT(1), & CE to
the outer header (and update 00 to some codepoint such as ECT(0), which
seems to better preserve some types of semantics, I wonder which causes
fewest issues (would the assumption be that DSCP was also copied?)

> 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).
> 
Aha.

>>> [GF]: 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)."
>> 
>> [DB]: 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.
>> 
>>> [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.
>>> 
>>> - 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?
>> 
>> [DB]: 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.
> 
> [BB]: I agree with David here.
> 
Fine with me.

>>> [GF]:
>>> 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.
>> 
>> [DB]: Hmm ... I have the impression that non-support for 3540 (experimental)
>> is "in play" as a potential part of PCN.
>>
?? Hmmmm ??

>> 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 ;-).

> [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.
> 
I'll look at the next rev.

> [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).]
>
I don't understand the ordering with nonce issue, but that's a different
topic.

>>> [GF]:
>>> CE    -> ECT(0) ... What are the implications of this when transiting
>>>                    a network using ECN or alt. ECN semantics?
> 
> [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.
> 
OK, but since then we have seen protocols using both ECT(0) and ECT(1).
Nonce and others (with a DSCP), so I was hoping these could work with
tunnels (at least within the domains were they were to be used).

>> [DB]: 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.
> 
Yes, except if ECT(0) and ECT(1) had mean something for a flow, then  CE
means it was once one of these, (but the devices can not know which).

> [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.
> 
Agreed, not a good result.

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

Great to see someone working on these issues, thanks Bob!

Gorry