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

From: Sally Floyd <[email-masked]>
Date: Wed, 1 Aug 2007 15:16:34 -0700

Bob -

This is a long email, but it just says "OK" in response to email from 
Bob
about two small wording issues, and continues an extended but
non-critical discussion about one case of "MUST" vs. "SHOULD".  FYI...

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

That sounds fine to me.

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

As I read it, the rest of that paragraph is specific to
multi-level congestion marking.

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

Yep.  But *additional* marking (for an ECN codepoint defined to
have multi-level congestion, and for a packet that is not already
marked at the highest level of congestion before the tunnel ingress)
is one thing, and a packet that *would have been* marked in
the tunnel if it hadn't already been marked is another.
I think it is good to be quite clear about the difference.

> Having realised this, there was no reason not to say MUST as:
> - a single behaviour is always preferable to multiple options

I happen to disagree.  The guideline that I use is not to specify
"MUST" unless I think it is necessary.  I don't know off-hand if there
is a specific IETF guideline on this.

> - and copying at ingress actually doesn't lose info that might one day 
> be useful about what happened across the tunnel.

And I said above, I think this is wrong.  I think that copying at
ingress is fine.  But I think it is good to be clear that is *does*
lose information about routers that would have marked packets along
the tunnel (e.g., for the default ECN semantics specified in RFC 3168,
or for packets that were already marked at the highest level in a
multi-level congestion mechanism).

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

I would prefer "SHOULD", but I could live with "MUST".  But if the
draft leaves it as MUST, then I think the draft should clarify that
this means that the tunnel egress can't necessarily tell if a router
in the tunnel would have marked the packet, because it is quite
possible that the packet was already marked at the highest marking
level before it entered the tunnel.   I would also suggest that
the draft clarify that if someone in the future wanted to use
a tunnel protocol where the egress router can detect whether packets
are marked inside the tunnel, then they would have to change this
"MUST" to a "SHOULD" or "MAY".

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

Yep.  Many thanks.

- Sally
http://www.icir.org/floyd/

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 06 Aug 2007 14:46:08 +0100

Sally,

I've snipped the points of agreement; one remaining issue below but I think 
we are close to resolution...

At 23:16 01/08/2007, Sally Floyd wrote:
>>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...").
>

I just need to understand which words make you think this is about 
multi-level marking, because it wasn't meant to make the reader think like 
this. Here's the rest of the para. Can you indicate which part I should 
change to avoid implying multi-level.

"                                                           If outer
    header congestion marking was reset at the tunnel ingress ('I'), by
    the end of a tunnel ('E') the outer headers would indicate congestion
    experienced across the tunnel ('I' to 'E'), while the inner header
    would indicate congestion upstream of 'I'.  But the same information
    could be gleaned even if the tunnel ingress copied the inner to the
    outer headers.  By the end of the tunnel ('E'), any packet with an
    _extra_ mark in the outer header relative to the inner header would
    indicate congestion across the tunnel ('I' to 'E'), while the inner
    header would still indicate congestion upstream of ('I').
"

>>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.
>
>>- and copying at ingress actually doesn't lose info that might one day be 
>>useful about what happened across the tunnel.
>
>>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.
>
>level before it entered the tunnel.

I v happy to say this.

>I would also suggest that

And I'm happy to say this. I'll put working in an -01 and post to the list.

Bob

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