Subject: [tcpm] WGLC for draft-ietf-tcpm-accecn-reqs (06)

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 10 Jul 2014 09:43:08 +0100

I have read this and previous versions of this document and think this 
is a useful document and the present document should be published.

I'd finally note that I think this document clearly captures the scope 
of the planned work to define the new mechanism - I don't see a need for 
RFC2119 language to achieve this goal in this case.

Detailed comments below.

Gorry

---
Datatracker link to the document is
https://datatracker.ietf.org/doc/draft-ietf-tcpm-accecn-reqs/
---
Para 1, Section 1::
- This introduces the term "more accurate" in the first instance, 
perhaps the ID should clarify that it is "more accurate than the method 
proposed in RFC 3819" - to explain the "more". (I know it's also 
explained at the end, but this early explanation wouldn't be hard to add.)
---
Section 1:
/or document deviations./
- I think the meaning is that if an implementation does not adhere, it 
needs to document deviations, but this form  of words (using "or") could 
be confused by a non-native reader.
---
Section 1:
/  ECN feedback for SCTP
    [I-D.stewart-tsvwg-sctpecn] delivers a counter for the number of CE
    marked segments between CWR chunks, but also comes at the cost of
    increased overhead./
- Can we avoid endorsing this individual draft? I'm very supportive of 
the idea of adding ECN to SCTP, but the specific method proposed in 
sctpecn is technically only a proposal, and I think we should be careful 
not to endorse the method. Could this be written as:
/  ECN feedback for SCTP has been proposed in
    [I-D.stewart-tsvwg-sctpecn]. This delivers a counter for the number
    of CE
    marked segments between CWR chunks, but also comes at the cost of
    increased overhead./
- publication of the accecn draft may finally provide the environment in 
which SCTP ECN becomes important to progress?
---
Last para, section 1:
/simply called ACK/
               ^
- insert /an/
---
Section 4:
/Nagle's Algorithm/
- Insert (RFC896)?
---
Section 4:
/Given there are known problems with the ECN Nonce (as
            identified above)/
- Oh I've just seen an email from Bob (sorry) that I need to reply 
on-list about this, but if I understand correctly, the txt "above" in 
"(as identified above)" was removed to avoid a rathole that wasn't 
needed for this draft. Should the text in brackets be updated or removed?
---
Section 5:
/5.  Design Approaches/
- Given an RFC lasts forever, it could be worth preceding the text in 
this section to say the information is intended as an input to future 
work in the IETF to standardise a method and that it does not endorse 
any of these methods!
---
Section 5.2.  Using Other Header Bits
- It may be useful to note that assignment of the bits requires IETF 
action (again to prevent the text being cited in the future by someone 
wishing to advocat a new scheme).
---
Section 8:
/ECN feedback information should only be used if the other information	
contained in a received TCP segment indicates that the congestion was	
on-path/
- I agree in this addition, but I'm not sure what off-path congestion 
would be :-), maybe we could write something like:
/ECN feedback information must only be used if the other information	
contained in a received TCP segment indicates that the segment was	
on-path/
---
You could consider refering (informative) to draft-welzl-ecn-benefits, 
in the introduction, esepecially if this ID happens to be adopted by a 
WG before accecn is published.
---

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 11 Jul 2014 11:33:26 +0100

Gorry,

Thx. I agree with all your points and with your suggested rewording 
where provided. Assuming my co-authors also agree, we'll make sure 
your points get dealt with as soon as the WGLC ends.

I've answered your questions inline...

At 09:43 10/07/2014, Gorry Fairhurst wrote:

>I have read this and previous versions of this document and think 
>this is a useful document and the present document should be published.
>
>I'd finally note that I think this document clearly captures the 
>scope of the planned work to define the new mechanism - I don't see 
>a need for RFC2119 language to achieve this goal in this case.
>
>Detailed comments below.
>
>Gorry
>
>---
>perhaps the ID should clarify that it is "more accurate than the 
>method proposed in RFC 3819" - to explain the "more". (I know it's 
>also explained at the end, but this early explanation wouldn't be hard to add.)
>---
>Section 1:
>- I think the meaning is that if an implementation does not adhere, 
>it needs to document deviations, but this form  of words (using 
>"or") could be confused by a non-native reader.
>---
>Section 1:
>/  ECN feedback for SCTP
>- Can we avoid endorsing this individual draft? I'm very supportive 
>of the idea of adding ECN to SCTP, but the specific method proposed 
>in sctpecn is technically only a proposal, and I think we should be 
>careful not to endorse the method. Could this be written as:
>- publication of the accecn draft may finally provide the 
>environment in which SCTP ECN becomes important to progress?
>---
>Last para, section 1:
>/simply called ACK/
>               ^
>- insert /an/
>---
>Section 4:
>/Nagle's Algorithm/
>- Insert (RFC896)?
>---
>Section 4:
>on-list about this, but if I understand correctly, the txt "above" 
>in "(as identified above)" was removed to avoid a rathole that 
>wasn't needed for this draft. Should the text in brackets be updated 
>or removed?

CURRENT:
            Given there are known problems with the ECN Nonce (as
            identified above),
SUGGESTED:
            Given there are known problems with ECN Nonce deployment (as
            identified above),

Also, on reflection,

CURRENT:
                               this document only requires that the
            integrity of the more accurate ECN feedback can be assured as
            an inherent part of the new more accurate ECN feedback
            protocol;
SUGGESTED:
                               this document only requires that the
            integrity of the more accurate ECN feedback protocol can 
be assured;
REASONING:
Integrity protection could be provided by an independent generic 
approach (e.g. draft-moncaster-tcpm-rcv-cheat); it doesn't have to be 
an inherent part of the AccECN protocol.

>---
>Section 5:
>/5.  Design Approaches/
>- Given an RFC lasts forever, it could be worth preceding the text 
>in this section to say the information is intended as an input to 
>future work in the IETF to standardise a method and that it does not 
>endorse any of these methods!
>---
>action (again to prevent the text being cited in the future by 
>someone wishing to advocat a new scheme).
>---
>Section 8:
>- I agree in this addition, but I'm not sure what off-path 
>congestion would be :-), maybe we could write something like:

SUGGESTED:
    ECN feedback information should only be used if the other information
    contained in a received TCP segment indicates that it was genuinely
    part of the flow and not spoofed - i.e. [...]

>---
>You could consider refering (informative) to 
>draft-welzl-ecn-benefits, in the introduction, esepecially if this 
>ID happens to be adopted by a WG before accecn is published.
>---

Thx

Bob

>_______________________________________________
>tcpm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tcpm

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: [email-masked]
Date: Fri, 11 Jul 2014 11:35:52 +0100

These changes work for me.

Gorry