Subject: [Tsvwg] [Digest] Summaries about draft-ietf-tsvwg-ecn-ip-00.txt

From: Bob Briscoe <[email-masked]>
Date: Thu, 08 Mar 2001 10:56:04 +0000

tsvwg,

Here's a digest of the summaries of the off-line discussions 
that went on between:
1/ two of the authors of standards track "The Addition of Explicit 
Congestion Notification (ECN) to IP" 
(draft-ietf-tsvwg-ecn-{01|02}.txt Ramakrishnan, Floyd, Black) 
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-01.txt
and 
2/ the new "An Open ECN Service in the IP layer" 
(draft-ietf-tsvwg-ecn-ip-00.txt Briscoe, Crowcroft).
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-ip-00.txt

The 5 digests are:
1. Fourth ECN code-point
2. ECN & diffserv
3. ECN & fragmentation
4. IP's ECN service to other congestion control protocols
5. Summary (this one)

    DB> = David Black
    JC> = Jon Crowcroft
    SF> = Sally Floyd
    BB> = Bob Briscoe

BB>>Date: Wed, 21 Feb 2001 17:14:12 +0000
BB>>To: [email-masked], [email-masked], [email-masked]
BB>>From: Bob Briscoe <[email-masked]>
BB>>Subject: Important additions to ECN Proposed Standard?
BB>>Cc: Crowcroft Jon
BB>>
BB>>A final question:
BB>>
BB>>Do you think the Proposed Standard would be more manageable 
BB>>if it were in two parts: IP & TCP?

BB>>At 11:58 21/02/01 -0800, Sally Floyd wrote:
SF>Yep.  I always did. I liked the tunnels section in a separate draft
SF>also.  The IESG has clearly and repeatedly decreed otherwise.
SF>That is OK by me.

BB:Ah! 

BB>>>At 20:56 21/02/01 -0500, [email-masked] wrote:
DB>>>>
DB>>>>-- Summary
DB>>>>
DB>>>>I have serious problems and concerns with Section 5 - see above.

BB>>>Hope I've allayed them. If you intended ECN/TCP to be for BE only, I'd 
BB>>>be happy if you said so. I think it gets muddier tho. In the code 
BB>>>points that could be used by TCP apps, or could be used by r-t apps. 
BB>>>That's why the issue needs to be highlighted, not hidden.

DB>>>>For Section 6, I think it's possible to define behavior of the
DB>>>>fourth code point in a way that works for both the nonce and
DB>>>>the multicast "possibly marked" mechanisms.  We'd need to add
DB>>>>some text to make it perfectly clear that TCP does not work
DB>>>>with multicast, and hence use of ECN with multicast is not
DB>>>>being specified beyond the forwarding behavior of the fourth
DB>>>>code point.  We'd also need to add a few sentences to describe
DB>>>>the intent of the multicast "possibly marked" mechanism,
DB>>>>and similarly a few sentences describing the intent of the nonce.

BB>>>Now we've sorted this out, mentioning the pleasant dual use for 
BB>>>multicast would help the nonce proposal, I feel. Please also make sure 
BB>>>it is made clear research is ongoing. My main concern is the 
BB>>>implementation of this duplication on routers might be crap 
BB>>>performance.

DB>>>>I'd delete Sections 8-10 as they stray into areas that don't need
DB>>>>to be covered to get this ECN document done, and raise some issues.

BB>>>If Section 8 (svc i/f) is omitted, it will be needed in the future 
BB>>>(internal interface betw TCP & IP).
BB>>>
BB>>>Section 9 (Host algorithms) I'll be happy if the Proposed Standard 
BB>>>specifies it's for BE only. Otherwise, this section and section 5 
BB>>>stand or go together.
BB>>>
BB>>>Section 10. (Host requirements) This is akin to the service i/f 
BB>>>section. Can be omitted from your I-D, but will be needed somewhere, 
BB>>>for ECN UDP etc protocols to refer to. Perhaps I'll see what you 
BB>>>absorb from our I-D and maintain the balance for this purpose as a 
BB>>>separate I-D.

DB>>>>For Section 11, I have no problem with requiring Don't Fragment to
DB>>>>be set on ECN-capable packets, but I don't think the rationale
DB>>>>in that section applies to TCP, and hence would omit it.

BB>>>Hope I've convinced you it has to apply to all protocols or none.

DB>>>>For Section 12, I think it would be better to add a few sentences
DB>>>>on congestion proxies and why they would be exempt from the
DB>>>>requirements on routers rather than launching into the overall
DB>>>>rule-making framework of that section.

BB>>>This section was mainly to help security analysis. Again, as it's 
BB>>>wider than TCP, it could remain in a separate I-D.
BB>>>
BB>>>If we go for the nonce proposal, we can't authenticate anything in the 
BB>>>ECN field end-to-end (and have less need to). This was one aspect  I 
BB>>>was trying to establish.

DB>>>>Thanks for reading this far - comments, reactions?

BB>>>Thanks very much for reading it all and responding so fairly.

BB>At 20:57 22/02/01 -0500, [email-masked] wrote:
DB>>-- Summary
DB>>
DB>>- We still disagree on Section 5 (and hence 9).  FWIW, ECN
DB>>	is not only for BE - AF will almost certainly want to
DB>>	use it, so I would not agree to restrict ECN to BE.

BB>Agreed we're still disagreeing, but I'm not sure what's at 
BB>the bottom of it. I think it's to do with use of the passive 
BB>voice: 'PHBs are defined'. Perhaps I'm thinking of operators 
BB>doing the odd things, I think you're thinking more of 
BB>definition in standards.
BB>
BB>As I thought - unstated assumptions need stating.

DB>>- We agree on specifying the queue-based marking behavior for
DB>>	the fourth codepoint in Section 6.  Others can debate
DB>>	how to use it for multicast.

BB>Yup.

DB>>- I can deal with reorienting Section 8 into advice to
DB>>	future authors working on "ECN with <foo>"
DB>>	documents, but would prefer to stay away from
DB>>	defining a formal interface.

BB>OK.

DB>>- We disagree on the recommendations for host exposure
DB>>	of ECN in Section 10.

BB>We have a process agreed.

DB>>- Putting in "SHOULD set DF" will resolve the concern in Section
DB>>	11 - this is fine with me, despite my quibbles with the
DB>>	rationale for doing so.

BB>This is a disagreement still.

DB>>- I would strongly prefer turning Section 12 into a discussion of
DB>>	congestion control proxies rather than trying to lay out
DB>>	a general framework for everything that anyone might
DB>>	conceive of in the future.  Keeping the general framework
DB>>	in a separate I-D for future discussion makes sense, and
DB>>	I think that's acceptable to both of us.

BB>As well as the proxies stuff, I was trying to make it clear 
BB>whether ECT is intended to be read by routers, by receivers, 
BB>or both. It's not explicitly stated so far (it's obvious if 
BB>you think about it, but not stated).
BB>
BB>I suggest, as long as the former point is clearer in the 
BB>Proposed Standard, the proxies can be dealt with in a 
BB>parallel document.

DB>>Thanks,

BB>And thank-you for you attention to these matters.

At 20:28 23/02/01 -0500, [email-masked] wrote:
DB>>
DB>>On the few things that are left:
DB>>
DB>>-- PHB guidelines (5.1):
DB>>
DB>>On a procedural basis, I'm now convinced that the
DB>>proverbial "right" home for this is a diffserv
DB>>RFC 2475 update, and I'd like to avoid getting the ECN
DB>>draft mixed up in that.  Hence I don't plan to write a
DB>>formal guideline but rather note that PHB definitions
DB>>SHOULD NOT require that all markable packets be treated
DB>>as unmarkable, but MAY recommend conditions under which
DB>>ECN marking SHOULD or SHOULD NOT be used instead of
DB>>dropping packets.  Note that the use of SHOULD (rather
DB>>than MUST) provides the right bias while leaving an
DB>>escape hatch available for those who are absolutely,
DB>>positively sure that they know better.
DB>>
DB>>-- Relaxing ECN marking equivalence to drop (5.2)
DB>>
DB>>We disagree - you'll have to make your case for allowing
DB>>this sort of congestion control change to the tsvwg.  As
DB>>noted previously, I disagree with the intermediate position
DB>>of mandating this equivalence only for BE traffic.
DB>>
DB>>-- SHOULD vs. MUST set DF (11) 
DB>>
DB>>Based on subsequent emails, this'll be SHOULD set DF.
DB>>While I don't think you have a strong case, it
DB>>could be taken to the tsvwg.
DB>>
DB>>-- Summary of who looks at what (12)
DB>>
DB>>We agree that the set of rules approach in Section 12
DB>>of your draft is not the way to go.  Let's take a look
DB>>at the next version of the ECN draft next week and see
DB>>if adding the sort of summary of who does what to which
DB>>bits that you have in mind would significantly improve
DB>>clarity.  I want to get the content edits done first
DB>>in what little I have in the way of "copious spare time".
DB>>
DB>>--David

________________________________________________________
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