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

["De Schepper, Koen (Nokia - BE/Antwerp)" <[e-mail]>]

Hi Ingemar, all,

Some comments from my side:

  *   Maybe a bit early to start discussing doc structure, but I would split the structure in receiver and sender functionality. That means we first describe (after an introduction) the ECN-echo/feedback wire-protocol functionality from the receiver. It is the only generic functionality that is required from the receiver. The rest is sender behavior. This draft is making sure that deployed QUIC stacks have this ECN-echo capability build in. For the sender we describe one mandatory sender behavior: ECN-Capability-Check, and one optional: ECN-based congestion control functionality (so below, also +1 from my side).



  *   In ECN Capability check section: "[ED note, should we say 'frame'?]"
No, as we want to couple ECN marking to packets. I assume the max packet sequence number in the ACK is the right total-packet counter (minus sender skipped sequence ranges, etc...).



  *   The ECN-Capability check figure better shows "ACK + ECN-counters" instead of "ACK + ECN field" Boxes A and B could then show the functions inside of them (B contains [ECN-feedback] and A [ECN capability check]). To avoid confusion, I would also put: "1st packet (ECT set)".



  *   The code example is using the TOS byte. We should avoid the same problem as with DiffServ including the ECN bits, ECN should not include/bleach the DiffServ bits. So better explicitly:

int iptos = ... (0 or optionally initialized with diffserv value, not using the 2 least significant bits)

int ect = ... (2 bit value between 0 and 3)

iptos = (iptos & 0xFC) | (ect & 0x03);

res = setsockopt(fd_out_rtp, IPPROTO_IP, IP_TOS,  &iptos, sizeof(iptos));

Maybe better to also copy the relevant ecn-getter lines in the draft:

ret = getsockopt(sock_fd, IPPROTO_IP, IP_TOS, (void*)&iptos, &optlen);

if(ret == -1) {

// getsockopt/socket failure, clean-up socket state (and/or exit);

...

}

ecn = iptos & 0x03;

diffserv = iptos & 0xFC; // if needed

Also, I'm not sure if we don't need to use a 1 byte type (unsigned char) instead of int. Using int might have a side effect that it might use the 8 MSBits (first byte) on a big indean platform, with all zeroes as a consequence. We better give a CPU-independent, well-tested and bug-free example.



  *   Do we still need to describe the 3 alternatives? If we agree, I think it is better to clean-up and don't offer alternatives, to avoid repeating discussions afterwards? If no one objects, we go for the packet counters only?


  *   I prefer also having ACK and ECN in the same frame, as they need to be handled at the same level, are both depending on each other and to avoid an extra frame-type header byte. Additionally, section 8.16.2 would be too complex too, otherwise. ECN-frames would have to be considered as equal to ACK-frames, and the spec should say that "Implementations MUST NOT generate packets that only contain ACK and/or ECN frames in response to packets which only contain ACK and/or ECN frames" ... Actually, everywhere in the spec where ACK-frame is mentioned, we would have to extent what is needed for ECN frames.



  *   I am also concerned that delta-based values could cause ambiguous duplication/retransmission cases. As mentioned in the previous mail, I don't think we need to couple the counts to the ACKed ranges in the ACK blocks. This will lead to a master-mind-game-like solver to reproduce the counters as every ACK might have different partly overlapping blocks. By trying to simulate the ACK behavior with reporting deltas on the running counters at the receiver end to those counter values at the previous ACK sent, I saw these 2 possible problems: 1) if assumed lost but reordered ACK packets trigger re-sending a delta, how do we undo them when we realize they have been received anyway? 2) if the ACK for the first packet is lost, how will we detect ECN-capability in a delta based feedback if only the first packet was marked ECT by the sender? As Bob mentioned, it will take another RTT to resend it and detect ECN capability. Maybe not such a problem for detection only, and when used for CC with all packets marked ECT, it will at least increment one counter (ECT or CE, unless it was bleached). Further to be thought about.




Koen.

From: Ecn-in-quic [mailto:[e-mail]] On Behalf Of Ingemar Johansson S
Sent: Monday, December 18, 2017 8:40 PM
To: Magnus Westerlund <[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

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]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Jana Iyengar ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>; Ian Swett <[e-mail]<mailto:[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-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]<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]>

----------------------------------------------------------------------