Re: ECN in QUIC

[Jana Iyengar <[e-mail]>]

>
> 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*
> <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]
> <[e-mail]>]
> > Sent: den 25 september 2017 13:31
> > To: Mirja Kühlewind <[e-mail]>
> > Cc: Christian Huitema <[e-mail]>; [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]>:
> > >>
> > >>
> > >>
> > >> 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
> > >>
> >
>
>
>