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

[Bob Briscoe <[e-mail]>]

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:
> 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).
[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.

>> ——
>> 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.
> [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.
[BB] Done (New section "3.2.8 General Fall-back for all Control Packets 
and Retransmissions")


>> - 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]: 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

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