Re: [Ecn-in-quic] ECN in QUIC, quick review input wanted

[Magnus Westerlund <[e-mail]>]

Hi,

I have done a review. I did edit in some editorial corrections. My 
comments are:

1. Requirement R.5 Editorial

I did change this requirement to what I assumed it meant to say. "must 
not be able" didn't make sense in the below.

* R.5 A QUIC implementation may not be able to verify ECN support in the 
OS network stack. The capability check should cover this case similar as 
if the network does not support ECN (see R6).

2. Comment on below note

"[In case duplicates are asked in QUIC: Once peer A receives the ACK 
frame it verifies that the number of ECT marked bytes(or packets) is 
equal to or greater than the number of transmitted ditto [ED note, 
"equal to or larger" in case duplicates are counted]"

This appear to be an issue we need to work through more. Using byte or 
packet counter where duplication sneaks in without making clear the 
level of duplication creates uncertainties in interpretation. At the 
same time suppressing a CE mark in a duplicated packet is also not 
without issues. The correct congestion response is knowing the actual 
number of delivered bytes and how much was congestion marked.

3. Clarification of IETF QUIC 1.0 minimal requirements.

## QUIC v1.0 limitation
Subsequent packets (after the 1st) should set the ECN bits to Not-ECT. 
This because v1.0 will only verify that the ECN capability exchange and 
the ACK+ECN frame operates correctly.

Should this be clarified, that initial capability exchange and acking 
with ECN information is proposed to be MUST be implemented. Where after 
initial exchange the setting of ECT is OPTIONAL. If a sender sets the 
ECN field to ECT after the initial one the sender MUST implement a 
congestion response to ACKs indicating ECN-CE marked packets. It is 
expected that future QUIC profiles will define if ECN sender capability 
is mandated.

4. ECN Feedback.

Frankly I don't quite understand why ACK and ECN must be in the same 
Frame. Yes, they need to be in the same IP packet, and have 
corresponding information coverage to make them useful. But, that I 
don't see require combined frames. What am I missing? Is it the case of 
retransmitting ACK frames, where one may have multiple ACK Frames from 
different times in the same frame alternatively, need to re-encode the 
corresponding ACK interval into one new frame?

5. ECN Feedback:

I think the text should clarify that the ECN fields covers exactly the 
same packets that are included in the ACK. Thus these field will 
normally report on a relative small number of received packets between 
each ACK. Retransmission of an ACK frame requires corresponding ECN 
information to be retransmitted to, or is this case simply re-encoded to 
cover previous non ackwlodeged ACKs + new received packets that are ACKed?

6. Editorial inconsistency in ECN Feedback.

"The wire specification below only address the ACK+ECN frame and assumes 
bytes marked as report metric."

Then alternative 1 is assumed and counts in packets.

7. ECN Feedback alt 3.

"All in all this alternative would mostly encode the ECN block as 3 
octects and sometimes as 4 or 6 octets."

Shouldn't this alternative result in 4 bytes or more. 2 bytes for ECT, 1 
byte for the non used ECT codepoint, and 1 byte for CE when nothing is 
marked. Then larger ACK blocks results in additional bytes for CE and/or 
ECT(Value Used).

8. Reduction of overhead

Isn't decoupling the ECN reporting from the actual ACK blocks 
problematic. Then you don't know over which packets the ECN information 
maps to.

The reasonable method to reduce for this initial phase is that zero 
values for the counter corresponding to the ACK block, i.e. only Non-ECT 
marked packets received are using regular ACK, not including the ECN frame.


Cheers

Magnus



Den 2017-12-17 kl. 14:43, skrev Ingemar Johansson S:
>
> Hi
>
> I hope that we will be able to write up a draft that describes ECN in 
> QUIC before the Melbourne Interim, but it is getting short on time and 
> the xmas holiday is soon here.
>
> I have now updated the ECN in QUIC wiki, based on my current best 
> understanding. Koen, Stuart and  Praveen have also worked on the wiki 
> + some extra input from experiments by Lars, many thanks!
>
> Please read at your earliest convenience through the sections
>
> https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#ecn-capability-check
>
> https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#ecn-feedback-wire-format 
> (it is sufficient to just read about alternative 1)
>
> https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#handling-of-lost-acks
>
> and
>
> https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#reduction-of-overhead
>
> Does this make sense ?
>
> /Ingemar
>
> ==================================
>
> Ingemar Johansson  M.Sc.
>
> Master Researcher
>
> Ericsson Research
>
> Network Protocols & E2E Performance
>
> Labratoriegränd 11
>
> 971 28, Luleå, Sweden
>
> Phone [phone]
>
> SMS/MMS [phone]
>
> [e-mail] <mailto:[e-mail]>
>
> www.ericsson.com
>
> The world is full of magical things patiently
>
>     waiting for our wits to grow sharper
>
> Bertrand Russell
> ==================================
>
>
>
> _______________________________________________
> Ecn-in-quic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecn-in-quic

-- 

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------