RE: Quick review of ECN for QUIC: draft-johansson-quic-ecn-03

[Ingemar Johansson S <[e-mail]>]

Hi
Thanks for the review , comments inline

/Ingemar

From: Bob Briscoe [mailto:[e-mail]]
Sent: den 26 juni 2017 01:31
To: Ingemar Johansson S <[e-mail]>
Cc: QUIC IETF mailing list <[e-mail]>
Subject: Quick review of ECN for QUIC: draft-johansson-quic-ecn-03

Ingemar,

As just promised (on tcpm - pasted below) here's a rushed write-up of the high order bits of my review of your draft-johansson-quic-ecn-03.
This is purely a list of my immediate reactions to sentences in the draft. I will need longer to think about the protocol as a whole, whether this is the best approach, whether there might be a better approach, and the open issues you list.

2.1
It would be useful to first describe how the protocol would work across a network without Byzantine middlebox behaviour and without hobbled operating systems that cannot access the ECN field of IP packets. Then separately describe fall-back in the face of various ECN failures separately.
[IJ] OK


Preferably, let's try to think of a way to support ECN on the very first QUIC connection setup datagrams (see comments pasted below about copying the techniques in draft-bagnulo-tcpm-generalized-ecn, which depends on draft-ietf-tcpm-accurate-ecn for this capability).
[IJ] Yes, that can be a good idea. The original intention was to be conservative and avoid that ECN negotiation in QUIC “black-holes” the connection setup. But given the discussion around draft-bagnulo-tcpm-generalized-ecn it is quite possible that one can do ECN negotiation already at setup.


In a similar vein, you might want to look at (and even cite) RFC7860 for requirements about ECN feedback (it was specifically about TCP, but there is stuff there relevant to QUIC too).
[IJ] Hmm, do you mean some other RFC ?


2.1.1
The argument for sending an ECN negotiation frame in a packet on its own only only makes sense if loss is more likely for packets with a non-zero IP-ECN field. Therefore, this should not necessarily be a long-term requirement on the protocol.
[IJ] Agree, wrote up presentation slides for the QUIC interim (did not get air time then to present it). One question was actually if one should move ECN negotiation to the QUIC connection setup.

Why always use CE to test traversal of the IP-ECN field? Setting the ECT codepoint that will be used throughout the connection also tests for zeroing the ECN field, without risking losing visibility of a CE marking introduced in the network.
[IJ] Admit, that I selected CE for lack of better knowledge, ECT(0) or ECT(1) (depending on ECN experimental use) may be better.


Define "a failed challenge/response phase". Can't it fail for a half-connection, not necessarily for the whole connection?
[IJ] In some cases a challenge reponse can fail for one half-connection, still it should be possible to  use ECN in one data direction. This needs some extra consideration and clarification.


2.1.2
The mode mechanism of RFC6679 needs to be described, not just referenced. Note that draft-ietf-tsvwg-ecn-experimentation intends to update RFC6679 in this respect (removing the use of the ECN nonce).
[IJ] Yes, added this without thinking, more work is needed.


2.3
Nit: You assign the names E1 and E2 for the fields for the length of each encoding of ECT(0) and ECT(1). It would be less illogical if they were called E0 and E1.
[IJ] Yes, you are right :-), will correct this.

The feedback gives the number of marked bytes. It needs to specify which headers are (not) included in the byte count. And if a datagram with zero bytes is ECN-marked, how do you propose to feed that back (in AccECN it feeds back marked packets and marked bytes)?
[IJ] Yes, this is not clear, the same ambiguity is also in draft-ietf-quic-recovery-04 as sent_bytes is not explained.



It says 1 octet overhead if ECN is not supported. Can't the ends send no ECN feedback at all if they have disabled ECN during the challenge response?
[IJ] Yes it is a possibility to include the ECN byte count even if ECN is not supported as the format is self-contained, this should be clarified.


2.4
It suggests using a given pattern to detect the need for fall-back. That's a good idea. I think any particular connection should only need to include two IP-ECN codepoints in the pattern: the relevant ECT codepoint and CE.

You might also want to look at this expired I-D: draft-moncaster-tcpm-rcv-cheat which uses CE randomly to verify that the receiver feedback is not cheating. You might be able to integrate that into the path traversal testing, although I accept that a deterministic pattern allows the remote peer to detect problems, whereas a random one doesn't.

It suggests a generic ECN fall-back draft. It is hard to describe fall-back independent of any specific protocol.
[IJ] Thanks, this section needs more work.


2.6
Nit: s/remark/re-mark/ because remark means something different.
[IJ] OK



A couple of months ago, we were discussing using timestamps on feedback, so that fewer ACKs could be sent without losing timing info. Are you planning to include that idea in this draft?
[IJ] Support for detailed timstamps is already available in the QUIC protocol ACKs


That's it for now.



Bob


-------- Forwarded Message --------
Subject:

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

Date:

Sun, 25 Jun 2017 23:17:42 +0100

From:

Bob Briscoe <[e-mail]><mailto:[e-mail]>

To:

Ingemar Johansson S <[e-mail]><mailto:[e-mail]>, [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>

CC:

[e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>, marcelo bagnulo braun <[e-mail]><mailto:[e-mail]>



Ingemar,



The draft already says this work shoul be transferable to SCTP. I might

also add a note that it could also benefit QUIC, altho I'd like to see

some detail before presuming this will work.



Coincidentally, I just read your ECN in QUIC draft yesterday. And, also

coincidentally, one of my main comments was going to be that it seems

disappointing that it only "sends an ECN negotiation frame when

connection setup is completed." Retransmission timeouts have to be

conservative during connection set-up whatever the protocol. So the

background level of congestion loss will then lead to unnecessarily

protracted intermittent delays, which will particularly hit short QUIC

flows. So I was going to suggest that you might be able to protect QUIC

connection setup from random congestion loss by an approach similar to

ECN++.





I cannot guarantee that I will have time to write up the other comments

from my review in time for you to use it before the IETF deadline (I am

about to take a week off, returning on 3 Jul). But I will try to do a

quick summary for the QUIC list now.







Bob



On 25/06/17 19:03, Ingemar Johansson S wrote:

> Hi

>

> I support this work.

> In addition, parts of the findings and recommendations in this TCP generalized ECN work may also be useful for the specification of the ECN support in QUIC, currently outlined in (https://tools.ietf.org/id/draft-johansson-quic-ecn-03.txt ).

>

> Regards

> Ingemar Johansson

>



--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/