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

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

Hi

 

Comments on most of the comments, marked [IJ]. 

/Ingemar

 

From: Magnus Westerlund 
Sent: den 18 december 2017 15:19
To: Ingemar Johansson S <[e-mail]>;
[e-mail]
Cc: Jana Iyengar ([e-mail]) <[e-mail]>; Ian Swett
<[e-mail]>
Subject: Re: [Ecn-in-quic] ECN in QUIC, quick review input wanted

 

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

[IJ] OK, makes sense.

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. 

[IJ] Based on an earlier discussion on the tracker (see Ian´s comment in
https://github.com/quicwg/base-drafts/issues/805 ) it is possible that this
is not an issue. But it needs to be verified in the transport draft that
this is indeed the case.

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. 

[IJ] Yes, definitely a +1 one on this, unless somebody objects, I can add
this

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? 

[IJ] I leave this as a separate discussion topic.

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?

[IJ] The idea is that the ECT(0),ECT(1) an CE deltas are stored for each
transmitted ECN feedback. If one ECN feedback is indicated as lost, then the
deltas are added to the next transmitted ECN feedback.

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. 

[IJ] Right, I will correct

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

[IJ] Yes, you are right, will correct this

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. 

[IJ] The rationale is that it is only strictly necessary with a prompt
transmission of ECN feedback when the CE counter increases. It is less
urgent to transmit ECN feedback  if the ECT(0) and ECT(1) counters increase
as these are only there to detect faults like bleaching. The proposal here
is to transmit ECN feedback at least once per RTT if either ECT(0) or ECT(1)
increases. In any case this is just an idea and it is possible that it
complicates the design more that its worth in overhead reduction.

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. 

[IJ] Yes, that is a possibility

 

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-for
mat (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] <mailto:[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]
<mailto:[e-mail]> 
----------------------------------------------------------------------