Subject: [Tsvwg] feedback on draft-briscoe-tsvwg-ecn-tunnel-00

From: Sally Floyd <[email-masked]>
Date: Thu, 19 Jul 2007 14:30:56 -0700

Bob -

Here is some feedback on Layered Encapsulation of Congestion 
Notification,
draft-briscoe-tsvwg-ecn-tunnel-00.

As I have said earlier, it is fine by me to update RFC 3168 to say
that a tunnel ingress should copy the ECN field from the inner
header to the outer header.  So this feedback is about smaller bits
and pieces.  (SHOULD vs. MUST, for example...)

- Sally

Feedback on draft-briscoe-tsvwg-ecn-tunnel-00:

Section 3.1:
"ECN at the IP layer is designed to carry information about congestion
from a congested resource to some downstream node that will feed the
information back somehow to the point upstream of the congestion that
can regulate the load on the congested resource."

Actually, that is not true.  RFC 3168 has two parts, specifying
ECN in both IP and in TCP, but ECN in the IP layer wasn't designed
only for unicast transport protocols.  E.g., at the time multicast
was a big deal in some of the research community, with receivers
joining and leaving layered multicast groups.  From the first
paragraph of the Introduction of RFC 3168:

"We ... describe modifications needed to TCP to make it ECN-capable.
Modifications to other transport protocols (e.g., unreliable unicast
or multicast, reliable multicast, other reliable unicast transport
protocols) could be considered as those protocols are developed and
advance through the standards process."

And later, in Section 6 on "Support from the Transport Protocol":

"Second, the transport protocol must be capable of reacting
appropriately to the receipt of CE packets.  This reaction could be
in the form of the data receiver informing the data sender of the
received CE packet (e.g., TCP), of the data receiver unsubscribing to
a layered multicast group (e.g., RLM [MJV96]), or of some other
action that ultimately reduces the arrival rate of that flow on that
congested link."

So ECN was designed with transport protocols in mind, but it was not
designed only for unicast, TCP-like transport protocols.  In particular,
there could be protocols where the transport receiver is the actor,
not the transport sender.

Section 3.2:
"It might be useful for the tunnel egress to be able to tell whether
congestion occurred across a tunnel or upstream of it."

The rest of the paragraph is specific to multi-level congestion
marking such as PCN (and even in this case, I assume that the tunnel
egress can only tell whether congestion occurred across the tunnel
or upstream of it if the ECN field was not already at the highest
of the multi levels at tunnel ingress).

It seems *conceivable* to me that someone might want to design a
tunnel where the egress would want to know whether congestion
occurred across the tunnel or upstream of it, but where the ingress
was not a Load Regulator.  (I don't know why, offhand, though
multicast comes to mind.)  *If* one wanted to allow this in some
future tunnel, then one should change the MUST about copying the
ECN field from the inner to the outer header at ingress to a SHOULD.
And if one didn't want to allow this, then this should be made as
explicit as possible, I would say.  Making it completely clear that
when the ECN field is copied from the inner to the outer header at
ingress, then the tunnel egress won't necessarily be able to tell
whether congestion occurred across a tunnel or upstream of it.
(I guess that a simple way out would be just to stretch the
definition of "Load Regulator", to say that any time the tunnel
egress wants to be able to tell whether congestion occurred
across the tunnel or upstream of it, the ingress is called a
Load Regulator.)

Section 5:
In Table 1, are you ruling out the possibility of a future
tunnel design, with a Load Regulator at the ingress, where
packets are ECN-Capable within the tunnel, but not ECN-Capable
outside the tunnel?  (This could result in an inner header
that was not-ECT, but an outer header that was ECT or CE.)
Is this table specific to PCN?  It would seem OK to me to
think about an ECN-Capable tunnel with a Load Regulator in
the middle of a non-ECN-Capable end-to-end connection.

When the ingress is a Load Regulator, why "MUST" it reset
the outer heater to ECT(0)?  Isn't this PCN-specific?  Might
an ingress that is a Load Regulator in some cases want to
use both ECN(0) and ECN(1) *within the tunnel*, with some
tunnel-specific mechanism for using ECN(0) ad ECN(1) to
check for misbehaving nodes along the path?  (I am not
recommending it, just arguing against precluding
it unnecessarily...)

Section 9:
"With the rules as they stand in RFC3168 and RFC4301, within a
tunnel a CE marking could be added and subsequently removed by a
non-compliant node without detection, because the evidence of such
misbehaviour is removed by the decapsulator." Yep, as with this
document, RFC 3168 didn't copy ECT(0) or ECT(1) from the outer to
the inner header upon decapsulation.  But the tunnel egress, if it
wanted, could look to see if the ECT fields in the inner and outer
headers didn't match, and infer cheating within the tunnel, if it
wanted (in the RFC 3168 case, that is, where the ECT field from the
inner header is copied to the outer header).  But if you say that
an encapsulator that is a Load Regulator MUST set the outer header
to ECT(0), you lose that possibility of protection at the egress
of non-compliant nodes within the tunnel, it would seem to me.
Worth mentioning somewhere.

Nits:
 From the abstract:
This document "gives general principles to guide the design of
alternate congestion marking behaviours for specific PHBs and for
lower layer congestion notification schemes."

Where did this document do that?  That seems misleading to me.

Section 6:
When you first use "full-functionality" and "limited-functionality"
modes, you might want to refer the reader to RFC 3168.

Section 7:
"neither identified the need to raise an alarm if the inner header
was CE but the outer header was ECT."

RFC 3168 didn't identify the need to raise an alarm in this case
because there *is* no need to raise an alarm when the inner header
is not copied to the outer header, as is the case in RFC 3168.

---

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

Sally,

I was taking a couple of weeks off when you sent this, so only now am I 
catching up with the backlog...

At 22:30 19/07/2007, Sally Floyd wrote:
>Bob -
>
>Here is some feedback on Layered Encapsulation of Congestion Notification,

Good point. How about...

"ECN at the IP layer is designed to carry information about congestion
from a congested resource towards downstream nodes. Typically a downstream 
transport might feed the information back somehow to the point upstream of 
the congestion that can regulate the load on the congested resource, but 
other actions are possible (see [RFC3168] Sec.6)."

>across the tunnel or upstream of it, the ingress is called a

Actually, I think you'll find the rest of the para isn't specific to PCN 
and it answers your question (particularly from "But the same information 
could be gleaned...").

Essentially, even if the ingress copies the incoming header to the outer, 
any _additional_ marking along the tunnel can be detected at the tunnel 
egress as a difference between inner & outer.

Having realised this, there was no reason not to say MUST as:
- a single behaviour is always preferable to multiple options
- and copying at ingress actually doesn't lose info that might one day be 
useful about what happened across the tunnel.

Strictly, additional marking isn't quite the same as additional congestion 
(additional congestion which might have just happened to mark the same 
packet as was already marked). But, I don't think we should start 
introducing complicating options to allow for this corner case within some 
possible future scheme to extract what happened within the tunnel, that 
we're not sure anyone will ever want anyway. That corner case might be 
important to some scheme in the future during high congestion, but I 
suggest it will be their task to change MUST to SHOULD if they really need to.

>that was not-ECT, but an outer header that was ECT or CE.)

This table is a restatement of full functionality RFC3168 and RFC4301 
tunnel egress behaviour, which I haven't changed (except for adding a 
couple of warnings for illegal transitions that were missed in those two RFCs).

You're right, I hadn't considered that this would preclude an inner 
ECN-capable control loop.

See the next mail to Gorry about this: I *think* that we can make these 
control loop-within-loop issues orthogonal to tunnelling by showing that 
such functions can always be put before encapsulation or after 
decapsulation. Then we can simply define what to do in the appropriate 
I-D/RFC about in-path load regulation without crossing the issue of tunnelling.

>Is this table specific to PCN?

Not at all. As I said, Table 1 is just a restatement of vanilla RFC3168 / 
RFC4301. In fact, if PCN uses 2 congestion marking levels (admission & 
termination), we'll have to define a different egress behaviour for PCN, 
with the central square of the matrix changing from:

ECT(0)  ECT(0)
ECT(1) ECT(1)

to

ECT(0)  ECT(1)
ECT(0) ECT(1)

If we did this for all DSCPs, it would also correctly preserve the ECN 
nonce (see discussion in security considerations section about how RFC3168 
& RFC4301 currently lose nonce protection over a tunnel).

>It would seem OK to me to

Actually, I wasn't writing this with PCN in mind - I was just repeating 
what RFC3168 already said about resetting CE to ECT(0). I'm not sure what 
PCN should do yet, because the PCN encoding is very much up in the air at 
the moment (see draft-chan-pcn-encoding-comparison-00.txt, to which the 
authors have agreed substantial changes following considerable bashing on 
the list).

Anyway, as said above, I *think* I can take this in-path load regulator 
stuff out of this ecn-tunnel draft. Then it can be defined for each 
specific case, while tunnel implementations could all do the same thing 
irrespective of in-path load regulators. And any XXX-specific behaviour 
could be in a XXX doc, not this tunnelling doc, where XXX = 
{PCN|PWE3|CAPWAP|etc}.

>inner header is copied to the outer header).

True (strictly only the full functionality case of RFC3168).

>But if you say that

You're right - I could have said it sets either ECT(0) or ECT(1), with 
ECT(0) as default. But, as I said, I hope I won't need to say anything in 
this I-D about in-path load regulators.

>Where did this document do that?  That seems misleading to me.

I meant "... gives general principles to guide the design of tunnelling 
behaviours for alternate congestion marking schemes used by specific PHBs, 
and and the design of encapsulations by lower layer headers supporting 
congestion notification."

That's what sections 3 & 4 were meant to do. Is this better?

>modes, you might want to refer the reader to RFC 3168.

OK

>is not copied to the outer header, as is the case in RFC 3168.

Good point for ECT(0).

But in RFC3168, wasn't ECT(1) an illegal outer header if the inner header 
was CE, so a "MAY warn" would have been appropriate in that case at least?

Anyway, I'll change the offending text, to simply say that, once CE is 
copied to the outer at ingress, these extra warnings MAY be appropriate (or 
words to that effect).

Bob

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196