RE: ECN in QUIC

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

The two discussion points are now posted as issue (https://github.com/quicwg/base-drafts/issues/804 ) and (https://github.com/quicwg/base-drafts/issues/805 )

/Ingemar

From: Jana Iyengar [mailto:[e-mail]]
Sent: den 27 september 2017 21:18
To: Ingemar Johansson S <[e-mail]>
Cc: [e-mail]; Mirja Kühlewind <[e-mail]>; [e-mail]; Christian Huitema <[e-mail]>
Subject: Re: ECN in QUIC

General question. Is this Ok to discuss on this list or should we have the discussion on the tracker ?

We should have something on the tracker. Would you open an issue?

To summarize.. I can make the following observations :

1) ECN in ACK frame or dedicated ECN frame : Proponents of a dedicated ECN frame argue that adding extra ECN info in the ACK frame can increase the complexity of the ACK frame encoding and parsing. Ian Swett however as a very strong point in  his remark that ECN in a separate frame can give additional issues in the congestion control functionality, in other words, what we save (in complexity) in one part of the chain can cause extra cost and in the worst case incomprehensible code in another part of the chain. My takeaway is that it is best to have ECN in the ACK frame.

I agree with Ian's argument -- having ECN in a separate frame would make things harder for congestion control.

2) Detailed ECN marking info (2 bits/packet) or ECN marked bytes : I see some preference to implement something like what is suggested for RMCAT, I am not convinced that one need to impose the limitations of AccEcn as the latter is given by the limitations by TCP. Fig 2 and 3 in  https://tools.ietf.org/id/draft-johansson-quic-ecn-01.txt suggests two formats, my preference is the version presented in figure 3 (alt 2), it is padded at the end of the ACK frame. I copy the necessary parts below, it is not intended as a take it or leave it.

 I think we'll need to think carefully about framing, but let's do that on the issue.

- jana


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              First Ack Block Length (8/16/32/48)            ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  [Gap 1 (8)]  |       [Ack Block 1 Length (8/16/32/48)]     ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  [Gap 2 (8)]  |       [Ack Block 2 Length (8/16/32/48)]     ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                  ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  [Gap N (8)]  |       [Ack Block N Length (8/16/32/48)]     ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |ECE|ECE|... variable length, padded to full octets           ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The ECE field requires two bits encoding per
      frame.  The additional overhead amounts to ceil(N*2/8) octets
      where the N is the sum of the ACK block lengths.

/Ingemar


> -----Original Message-----
> From: Gorry Fairhurst [mailto:[e-mail]]
> Sent: den 25 september 2017 13:31
> To: Mirja Kühlewind <[e-mail]<mailto:[e-mail]>>
> Cc: Christian Huitema <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> Subject: Re: ECN in QUIC
>
> +1
>
> DCTP is not IETF standard - it's documenting a solution that is deployed in
> data centres - as it says - my hope is QUIC receives wider deployment.
>
> I suggest you start from AccECN, or examine the feedback discussed in
> RMCAT - which I think strove for equivalence to this.
>
> Gorry
>
> On 25/09/2017, 12:26, Mirja Kühlewind wrote:
> > There is Accurate ECN (draft-ietf-tcpm-accurate-ecn) in tcpm that changes
> the feedback defined in RFC3168 because we believe more accurate
> information in needed in future.
> >
> > Mirja
> >
> >
> >> Am 20.09.2017 um 21:02 schrieb Christian
> Huitema<[e-mail]<mailto:[e-mail]>>:
> >>
> >>
> >>
> >> On 9/20/2017 9:51 AM, Ingemar Johansson S wrote:
> >>> Detailed info about which packets are ECN marked can be useful but are
> not stricktly necessary. One alternative, that is presented in the ECN-QUIC
> draft is to count number of marked bytes.
> >>> That said, some like the detailed packet-level information type better. I
> have not yet been convinced that that this level of detail is necessary though.
> >> The problem is whether you can define a one size fit all ECN
> >> processing, that if possible should be compatible with ACK
> >> compression. There are at least two:
> >>
> >> * RFC 3168 says, echo ECN=1 if at least one of the acked packets had
> >> ECN set.
> >>
> >> * draft-ietf-tcpm-dctcp-10 suggests setting ECN so that the fraction
> >> of packet acked with ECN in 1RTT is the same as the fraction of
> >> packets with ECN set.
> >>
> >> So, which one?
> >>
> >> --Christian Huitema
> >>
>