Subject: Re: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-ecn-03.txt

From: Bob Briscoe <[email-masked]>
Date: Sat, 07 Apr 2001 18:07:15 +0100

Sally, KK, David,

Just confirmation that you've got rough agreement on draft-03 from me.
Hence I'm sending this to the list, not to the IESG in response to their
last call.

It's rough, because 
1/ On marking behaviour, I don't actually agree with the way the router
behaviour is described, embedding 'mark=drop' in your implementation
suggestions. IMHO, the prediction that future research might change things
is too vague to warn implementors how to protect themselves from future
changes per diffserv class. But it's your document, so such questions of
emphasis are yours to decide.
2/ On non-compliance, the argument that non-compliant use of ECN is no more
of a problem than for discard is wishful thinking, in my opinion. I
explained at IETF-50 initial ideas on a 'drop=drop' scheme that would fix
this and is particularly suited for real-time (and hence mostly UDP)
buffer-starving diffserv classes. But, let's give 'mark=drop' a shot for
TCP and see if non-compliance becomes a problem.
3/ On fragmentation, I don't understand why 'SHOULD set DF' has been
demoted to 'MAY set DF', and I'm not fully convinced that a few badly
configured fire-walls that prevent path MTU discovery are sufficient reason
not to say 'MUST set DF'. But, I don't really care about this strongly
enough to argue, as it's implementors that will suffer the extra complexity
and so if they're not fighting, I'd better shut up.

Arguments 1 & 2 need an academic paper from us. Then, if we convince
everyone, we have a way to change ECN later in specific diffserv classes.
But we need to move ECN on now, despite this. Hence, rough concensus.

I just read through the whole thing in one sitting to check for
inconsistencies given the recent fiddling around with it. I found some bugs
you might want to change with the RFC editor (don't think we need another
last call to do this?, but two of the inconsistencies I've found might?,
unfortunately). 

Details:

Bugs
----
p8, p39, p54(x3): The terms 'fourth ECT code-point' and 'fourth ECN
code-point' are used to mean ECT(1), but they are never defined and it's
counter-intuitive to call it this (as it's actually the third code-point,
but happened to be the fourth to be defined chronologically).

p12 section 5.3: reassmembled -> reassembled

p13 sec 6.1: [RFC2001] -> [RFC2581]

p15 sec 6.1.1: SYN packet -> SYN segment (many places)

p15 sec 6.1.1: Very last bullet has been line-wrapped on to the end of the
previous one.

p37 sec 12: "When ECN (Explicit Congestion Notification [RFC2481]) is used..."
->          "When ECN (Explicit Congestion Notification) is used..."

Lack of clarity 
---------------
(We can live with these, but if you go to draft 04 for other reasons,
consider these).

Secs 5 & 12. Needs to be clarified that ECT code-points aren't the only
ones for use by ECN capable transports - CE code-point is used by these
transports too. Those of us who know the history understand this, but it
will be confusing to newcomers.

p8: Fig 1: The label with the RFC2481 names of the bits doesn't make it
clear these are obsolete names (the text does). Perhaps the label should be:
"The obsolete RFC2481 names for the ECN bits"

p18 Sec 6.1.2 & section 6.1.3: Is it valid to refer to academic papers
[Floyd94] and [Floyd98] for the fine details of an IETF standard?

p55 sec 20.2:
  "multicast duplication procedures ... SHOULD NOT be deployed within tunnels
   configured for full ECN functionality."
AFAIK, a router doesn't know a tunnel has been built around it, so this is
rather a wild statement. Better to say that research is required to make
such multicast duplication procedures compatible with tunnels.

Self-inconsistencies
--------------------
(But I know what you probably mean, so others should too, however the first
two really do need to be resolved.)

p2: "...all the mechanisms specified here are incrementally deployable."
p24 sec 9.1: 
  "When ECN
   becomes widely deployed, then simple tunnels likely to carry ECN-
   capable traffic will have to be changed."
p37 sec 12:
  "All IP tunnels MUST implement one of the two alternative approaches
   described above."

Section 5 mandates the behaviour of ECN-capable transports in general, but
section 6 says "This document only addresses the addition of ECN Capability
to TCP..."
  "Upon the receipt by an ECN-Capable transport of a single CE packet,
   the congestion control algorithms followed at the end-systems MUST be
   essentially the same as the congestion control response to a *single*
   dropped packet."
(Also repeated for emphasis at the start of section 5.1).
I suggest you use the phrase "...transports that are TCP-compatible ...
MUST...".
If you really did mean to be this draconian for *all* transports, I would
object strongly.

Section 5.2 (picky):
  "...the congestion response of the end nodes to a dropped data packet is
   at least as strong as the congestion response to a received CE
   packet."
If being picky, this implies the response to CE may be stronger than to drop.

p12 sec 5.2 "..."pure" ACK packets MUST NOT indicate ECN-Capability..."
p19 sec 6.1.4 "...pure acknowledgement packets ... should be sent with the
not-ECT codepoint"
I assume this latter is strictly a MUST.

p22 sec 7:
  "We argue that the addition of ECN to the IP architecture will not
   significantly increase the current vulnerability of the architecture
   to unresponsive flows."
p35 sec 10:
  "We recommend that any "penalty box" ... 
   first change from marking to dropping packets"
If it's not advantageous to mark, why is switching to dropping a
punishment? Oops! This is rather fundamental - as I said, we'll attack this
in the research community - no need to resolve now.

p54 sec 20.2:
  "The assignment of the fourth ECN codepoint to ECT(1) precludes the
   use of this codepoint for other purposes."
Strictly, the multicast use should be separately listed, as it is not
precluded - it can be made compatible.

Final thought
-------------
Would it be sensible to use a next draft, if there is one, to set aside one
of the TCP reserved bits for ECN nonce experiments? 

Bob

At 07:31 30/03/01 -0500, [email-masked] wrote:
>	Title		: The Addition of Explicit Congestion Notification (ECN)
>                          to IP
>	Author(s)	: K. Ramakrishnan, S. Floyd, D. Black
>	Filename	: draft-ietf-tsvwg-ecn-03.txt
>	Pages		: 59
>	Date		: 29-Mar-01
>	
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-03.txt

________________________________________________________
Notice: This contribution is the personal view of the 
author and does not necessarily reflect the technical nor 
commercial direction of British Telecommunications plc.
________________________________________________________
Bob Briscoe      http://www.labs.bt.com/people/briscorj/

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg