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

[Bob Briscoe <[e-mail]>]

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.

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

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

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.

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.

Define "a failed challenge/response phase". Can't it fail for a 
half-connection, not necessarily for the whole connection?

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

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.

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)?

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?

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.

2.6
Nit: s/remark/re-mark/ because remark means something different.


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?

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]>
To: 	Ingemar Johansson S <[e-mail]>, 
[e-mail] <[e-mail]>
CC: 	[e-mail] <[e-mail]>, marcelo bagnulo braun 
<[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/