Subject: Re: [tcpm] Working group acceptance call draft-bagnulo-tcpm-generalized-ecn-04

From: Bob Briscoe <[email-masked]>
Date: Mon, 3 Jul 2017 00:27:02 +0100

Gorry,

Thx for your (as always) detailed and useful review. My replies tagged 
[BB] inline are my personal opinion, without having consulted with my 
co-author (Marcelo).

On 28/06/17 10:40, Gorry Fairhurst wrote:
>
> I support adoption of this work. I think there this is useful, and I 
> will review future versions. I would also like to contribute 
> measurements to inform the deployment of ECN methods.
>
> However, I query the inclusion of SCTP-specific text in this draft, 
> and suggest this can be removed and contributions made to the related 
> TSVWG work item to update the SCTP Spec. (Please see suggestions below.)
>
> Best wishes,
>
> Gorry
>
> —
> TEXT (SCTP):
> The present document also considers the implications for common
> derivatives and variants of TCP, such as SCTP [RFC4960], if the
> experiment is successful.
> - I am not sure this is appropriate, in particular, I doubt it is 
> helpful to explicitly speculate about changes to addd ECN to SCTP that 
> have yet to be progressed in the IETF. I’d much prefer this to refer 
> to more general advice saying that similar methods may apply also to 
> other transports that provide ECN support. (But see later, because I 
> try to suggest a different approach).
> - Similarly I am not sure why section 5.1 is helpful in a TCPM document.
> —
> TEXT (SCTP):
> The following subsections discuss any interactions between setting
> ECT on all all packets and using the following popular variants or
> derivatives of TCP: SCTP, IW10 and TFO.
> - Section 5 discusses SCTP as a variant of TCP, I do not think this is 
> appropriate. While SCTP can - and does - share congestion control 
> mechanisms with TCP, it is regarded as a separate protocol. I think if 
> kept, a change in wording would be really helpful.
> —
> My recommendations to consider regarding SCTP:
>
> (1) I would encourage you to remove the SCTP-specific text and think 
> whether the draft could instead have a section saying something a 
> little like:
> /If the IETF specifies ECN for other IETF protocols, it is expected 
> that these specifications should also mark IP packets for their 
> transport flows in the same way as described in this specification for 
> TCP./
> … with detail as required. I would see such text as informative, but 
> very useful for UDP-based methods as well as for SCTP, DCCP, etc.
>
> (2) I suggest instead that if this is adopted by TCPM, some 
> appropriate text is proposed to the TSVWG document: 
> draft-ietf-tsvwg-rfc4960-errata. This document is a set of corrections 
> that TSVWG will use to update the annexe to refer to this EXP spec. 
> The paragraphs in this spec seem like a great starting point for such 
> text and would be welcome in TSVWG.
[BB] You're right. Our draft was wrong to get too specific about a draft 
on adding ECN to SCTP that was only an individual draft and was never 
adopted. Your proposed approach is a better one, which I would like to 
follow (if adopted).

> —
> TEXT (DCTCP):
> Finally, there are ongoing experimental efforts to promote the
> adoption of a slightly modified variant of DCTCP (and similar
> congestion controls)
> I dislike text in RFCs that can be seen in some way to promote 
> Internet deployment of protocols specified for constrained deployment. 
> Can we please consider more careful wording here?
>
> DCTCP is specified INFO - for use in controlled environments). I’d 
> much rather see the current draft as a generic issue for any transport 
> that uses the L4S ID to identify the ECN treatment.
[BB]: Personally, I would be happy to:
a) emphasize that DCTCP is only for controlled environs
b) generalize to the possibility of a L4S "TCP Prague" (DCTCP-like) 
protocol on the public Internet.

But, like you, I don't want to make this part about DCTCP/L4S too long 
so that it overshadows the main motivation which applies to existing TCP 
on the public Internet.

> ---
> TEXT (NiT):
> By using the ECN capability,
> switches performing Active Queue Management (AQM)
> - Why switches? Isn’t the IETF primarily concerned with routers? - I’d 
> suggest this is replaced by /network devices (e.g., routers, switches)/.
> ——
> TEXT (NiT):
> Therefore it is
> RECOMMENDED that the experimental AccECN specification
> [I-D.ietf-tcpm-accurate-ecn] is implemented (as well as the present
> specification), because it is expected that ECT on the SYN will give
> the most significant performance gain, particularly for short flows.
> - I think much care is needed to ensure this recommendation can not be 
> interpreted as a requirement to implement AccECN, … is it possible to 
> rewrite this as something like:
> - / Implementations of this specification are also RECOMMENDED to 
> implement the
> experimental AccECN specification
> [I-D.ietf-tcpm-accurate-ecn], because it is expected that ECT on the 
> SYN will give
> the most significant performance gain, particularly for short flows./
[BB] Agree with both the above nits.

> ——
> TEXT (NiT):
> SYN packets are dropped because having the the ECT(0)/ECT(1)/CE
> - Maybe should be /are dropped because they have/
> ——
> TEXT (?):
> to learn if the network clears SYN
> packet
> - Unsure what /clear/ mean here?
> - (The measurement block in 3.2.1.1. has several typos that make it 
> hard to read).
[BB] We have already dealt with both these points by removing the whole 
"MEASUREMENTS NEEDED ... " block from 3.2.1.1 in our local copy for the 
next rev, cos it does not add anything to more specific "MEASUREMENT 
NEEDED" text in the relevant Rationale section (S.4.2) after more 
context has been given about possible different fall-back strategies.

> ——
> TEXT (Question on retransmissions):
> It can ignore the prohibition in section
> 6.1.5 of RFC 3168 against setting ECT on retransmissions.
> - I am not sure this is quite thought through yet: When loss occurs as 
> a result of a path change - i.e. encountering a middlebox-like 
> behaviour that does not allow "normal" ECN on the new path, an updated 
> path may not allow ECN to work in the way it is envisaged. This is 
> actually a very similar case of ECN SYN negotiation. To me, this means 
> a need for some form of fall-back and caching may need to be invoked 
> when a retransmission is triggered and fails.
> - The measurement section probably would be improved in there was some 
> note made that network path changes need to be considered as a 
> potential cause of loss that could result in change of the ECN 
> handling of the end-to-end path.
> - When the retransmission occurs, TCP is already reacting to loss 
> detection. DCTCP and ABE both call loss out as a form of congestion 
> detection that can not be handled by the ECN logic - i.e. the cwnd is 
> reduced according to the loss reaction, not teh CE-marking. A CE-mark 
> in this case offers little extra congestion information - somehow the 
> text I think needs to be clearer here.
[BB] Yes, Padma had already made a similar point for a case without an 
ECT SYN where ECT retransmissions of the client's first data packet are 
not getting through. I suggested text that Padma was happy with for that 
case. But the route change case is more general and needs more thought 
so I won't rush to propose a fix tonight. But we will attempt to address 
this in the next rev.

> —
> TEXT (Comment racing different SYN options):
> So it is questionable whether
> sending two SYNs will be necessary, particularly given failures at
> well-maintained sites could reduce further once ECT SYNs are
> standardized.
> - I think there are also downsides in racing SYNs - So, I’d personally 
> urge more even more caution around the idea of sending two sets of 
> SYNs with different sets of capabilities for the same connection.
[BB] I agree. The normative protocol in S.3. doesn't race different 
SYNs. This is only proposed as a strategy in the relevant "Rationale" 
section (4.2.2) if the following condition is true:

    If blocking is too widespread for the "optimistic ECT and cache
    failures" strategy (S2B)

and measurements /so far/ have not found this to be necessary.

> —
> TEXT (Comment FIN/RST):
> 4.6. FINs
> - When the congestion state is re-used due to congestion state 
> sharing, a CE-marked segment **could** have implications on the shared 
> window. However, I think this could be just a corner case that we 
> could ignore - since there is no further protocol interaction after a 
> FIN or RST, I don’t really see this as important. Whatever, if we 
> allow ECT on other segments, it seems OK to allow them (and more 
> consistent).
> —
> COMMENT: [ecn-pam]
> - The ECN measurements did not include access-side infrastructure, 
> e.g., firewalls and ISP networks. This comment simply motivates the 
> need for measurements at the edge of the network.
[BB] We have been doing (a lot) of that, particularly in mobile networks.

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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 14 Jul 2017 20:03:54 +0100

Gorry,

I have prepared text that addresses your comments (and Padma's), ready 
to submit when the servers open (Michael Scharf has asked me to submit 
-00 without other changes, then put queued up changes in -01).

I have a couple of follow-ups...

On 03/07/17 00:27, Bob Briscoe wrote:
>> helpful to explicitly speculate about changes to addd ECN to SCTP 
>> that have yet to be progressed in the IETF. I’d much prefer this to 
>> refer to more general advice saying that similar methods may apply 
>> also to other transports that provide ECN support. (But see later, 
>> because I try to suggest a different approach).
>> - Section 5 discusses SCTP as a variant of TCP, I do not think this 
>> is appropriate. While SCTP can - and does - share congestion control 
>> mechanisms with TCP, it is regarded as a separate protocol. I think 
>> if kept, a change in wording would be really helpful.
>> —
>> transport flows in the same way as described in this specification 
>> for TCP./
>> draft-ietf-tsvwg-rfc4960-errata. This document is a set of 
>> corrections that TSVWG will use to update the annexe to refer to this 
>> EXP spec. The paragraphs in this spec seem like a great starting 
>> point for such text and would be welcome in TSVWG.
> [BB] You're right. Our draft was wrong to get too specific about a 
> draft on adding ECN to SCTP that was only an individual draft and was 
> never adopted. Your proposed approach is a better one, which I would 
> like to follow (if adopted).
[BB] I've looked at 4960. I'm afraid adding ECN to SCTP will require 
more than errata. The ECN appendix in RFC4960 only specified the wire 
protocol, not the behaviour. So there's nothing there about setting or 
not setting ECT on control packets, or how to respond or anything. I 
think a separate ECN draft will be necessary. 
draft-stewart-tsvwg-sctpecn was a good start, so this might be 
resurrected. I guess a whole protocol spec masquerading as errata could 
be added to draft-ietf-tsvwg-rfc4960-errata, but I doubt that was the 
intention.

In ECN++, I have generalized the title of the SCTP subsection to "TCP 
Derivatives" with just 2 paras. One just introductory:  what SCTP is, 
and that there have been some attempts to add ECN to it. Then the second 
saying "Experience from experiments on adding ECN support to all TCP 
packets ought to be directly transferable to derivatives of TCP, like 
SCTP or QUIC". I also referred to Ingemar's ECN-QUIC draft.

>> - I am not sure this is quite thought through yet: When loss occurs 
>> as a result of a path change - i.e. encountering a middlebox-like 
>> behaviour that does not allow "normal" ECN on the new path, an 
>> updated path may not allow ECN to work in the way it is envisaged. 
>> This is actually a very similar case of ECN SYN negotiation. To me, 
>> this means a need for some form of fall-back and caching may need to 
>> be invoked when a retransmission is triggered and fails.
>> - The measurement section probably would be improved in there was 
>> some note made that network path changes need to be considered as a 
> ECT SYN where ECT retransmissions of the client's first data packet 
> are not getting through. I suggested text that Padma was happy with 
> for that case. But the route change case is more general and needs 
> more thought so I won't rush to propose a fix tonight. But we will 
> attempt to address this in the next rev.
[BB] Done (New section "3.2.8 General Fall-back for all Control Packets 
and Retransmissions")

>> text I think needs to be clearer here.
[BB]: You might have missed the existing penultimate para in the 
rationale section on retransmissions (4.8)

    "Finally, the third argument is about over-reacting to congestion.
    The argument goes that, if a retransmitted packet is dropped, the
    sender will not detect it, so it will not react again to congestion
    (it would have reduced its congestion window already when it
    retransmitted the packet). Whereas, if retransmitted packets can be
    CE tagged instead of dropped, senders could potentially react more
    than once to congestion. However, we argue that it is legitimate to
    respond again to congestion if it still persists in subsequent round
    trip(s).

    Therefore, in all three cases, it is not incorrect to set ECT on
    retransmissions.
    "

Cheers

Bob