Subject: ECN and Timestamps (was RE: DRAFT minutes for Seattle interim)

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 9 Oct 2017 10:46:01 +0000

Hi
Two comments on the discussion topics in the draft notes (thanks for producing the notes) :

+ ECN: Yes, I would very much like to be in the ECN design team :-)

+ Timestamp: I get the feeling that there is discussions on removing the timestamps. I have found ACK timestamps quite useful, these makes it possible to implement LEDBAT style congestion controls, which we believe can be useful for e.g. low priority transport in wireless access. It is however not strictly necessary to have a timestamp for each and every packet in the ACKs. In addition I don't see either that a floating point representation is necessary.

/Ingemar

> -----Original Message-----
> From: Mark Nottingham [mailto:[email-masked]]
> Sent: den 6 oktober 2017 21:36
> To: QUIC WG <[email-masked]>
> Cc: Lars Eggert <[email-masked]>
> Subject: DRAFT minutes for Seattle interim
> 
> ... are available at:
>   https://github.com/quicwg/wg-materials/blob/master/interim-17-
> 10/minutes.md
> 
> As always, corrections welcome, either as pull requests or through e-mail.
> 
> Thanks again to our scribes:
>   - Sean Turner
>   - Roberto Peon
>   - Martin Duke
>   - Ted Hardie
>   - Mike Bishop
> 
> Likewise, thanks to F5 and Martin Duke for hosting the meeting.
> 
> Cheers,
> 
> --
> Mark Nottingham   https://www.mnot.net/
>

---

From: Ian Swett <[email-masked]>
Date: Mon, 9 Oct 2017 10:02:39 -0400

Thanks Ingemar.  I agree that timestamps can be very useful.  The agreement
at the interim was to remove timestamps from the current draft and people
interested in ECN and Timestamps will create a proposal for each, as well
as a way to negotiate them.  The timestamp proposal can be similar to the
current one or completely different.  One could imagine having multiple
different timestamp and ECN formats for different congestion controllers,
but I think it makes sense to focus on one of each initially.

Would you be interested in working on an optional timestamp format as well
as an ECN format?

On Mon, Oct 9, 2017 at 6:46 AM, Ingemar Johansson S <
[email-masked]> wrote:

> + Timestamp: I get the feeling that there is discussions on removing the
> timestamps. I have found ACK timestamps quite useful, these makes it
> possible to implement LEDBAT style congestion controls, which we believe
> can be useful for e.g. low priority transport in wireless access. It is
> however not strictly necessary to have a timestamp for each and every
> packet in the ACKs. In addition I don't see either that a floating point
> representation is necessary.
>
>
> /Ingemar
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 10 Oct 2017 05:39:25 +0000

OK, then I understand.

Perhaps a later headache but…
If I take SCReAM as an example, in its basic form it works with timestamp (and normal ACKs that indicate packet loss), ECN  feedback is also used if enabled, but the delay based congestion control is always active, in other words there is no hard switch between loss based, delay based and  ECN based congestion control.
The feedback for all of this is bundled into the same RTCP ACK packet, sofar a proprietary non-standardized RTCP. A 16 bit ECN-CE marked bytes counter is always present in the feedback even though ECN is not enabled.

In the QUIC case I understand that there is a wish to create new frame types for timestamps and ECN. In the worst case we get the following ACK frame types :
ACK
ACK + TS
ACK + ECN
ACK + TS + ECN
Or do I misunderstand ?

To your question, yes, I think that I can join the timestamp design team as well if Ok with you.

/Ingemar

From: Ian Swett [mailto:[email-masked]]
Sent: den 9 oktober 2017 16:03
To: Ingemar Johansson S <[email-masked]>
Cc: Mark Nottingham <[email-masked]>; QUIC WG <[email-masked]>; Lars Eggert <[email-masked]>
Subject: Re: ECN and Timestamps (was RE: DRAFT minutes for Seattle interim)

Thanks Ingemar.  I agree that timestamps can be very useful.  The agreement at the interim was to remove timestamps from the current draft and people interested in ECN and Timestamps will create a proposal for each, as well as a way to negotiate them.  The timestamp proposal can be similar to the current one or completely different.  One could imagine having multiple different timestamp and ECN formats for different congestion controllers, but I think it makes sense to focus on one of each initially.

Would you be interested in working on an optional timestamp format as well as an ECN format?

On Mon, Oct 9, 2017 at 6:46 AM, Ingemar Johansson S <[email-masked]<mailto:[email-masked]>> wrote:
Hi
Two comments on the discussion topics in the draft notes (thanks for producing the notes) :

/Ingemar

> From: Mark Nottingham [mailto:[email-masked]<mailto:[email-masked]>]
> To: QUIC WG <[email-masked]<mailto:[email-masked]>>
> Cc: Lars Eggert <[email-masked]<mailto:[email-masked]>>
> 10/minutes.md<http://minutes.md>
>

---

From: Ian Swett <[email-masked]>
Date: Wed, 11 Oct 2017 11:28:44 -0400

On Tue, Oct 10, 2017 at 1:39 AM, Ingemar Johansson S <
[email-masked]> wrote:

> If I take SCReAM as an example, in its basic form it works with timestamp
> (and normal ACKs that indicate packet loss), ECN  feedback is also used if
> enabled, but the delay based congestion control is always active, in other
> words there is no hard switch between loss based, delay based and  ECN
> based congestion control.
>
> The feedback for all of this is bundled into the same RTCP ACK packet,
> sofar a proprietary non-standardized RTCP. A 16 bit ECN-CE marked bytes
> counter is always present in the feedback even though ECN is not enabled.
>
>
>
> In the QUIC case I understand that there is a wish to create new frame
> types for timestamps and ECN. In the worst case we get the following ACK
> frame types :
>
> ACK
>
> ACK + TS
>
> ACK + ECN
>
> ACK + TS + ECN
>
> Or do I misunderstand ?
>
>
I think you have it right, though how that's requested/negotiated and
framed is up to the (informal) design team, and I would greatly appreciate
your participation.

> *From:* Ian Swett [mailto:[email-masked]]
> *Sent:* den 9 oktober 2017 16:03
> *To:* Ingemar Johansson S <[email-masked]>
> *Cc:* Mark Nottingham <[email-masked]>; QUIC WG <[email-masked]>; Lars
> Eggert <[email-masked]>
> *Subject:* Re: ECN and Timestamps (was RE: DRAFT minutes for Seattle
> interim)
>
>
>
> Thanks Ingemar.  I agree that timestamps can be very useful.  The
> agreement at the interim was to remove timestamps from the current draft
> and people interested in ECN and Timestamps will create a proposal for
> each, as well as a way to negotiate them.  The timestamp proposal can be
> similar to the current one or completely different.  One could imagine
> having multiple different timestamp and ECN formats for different
> congestion controllers, but I think it makes sense to focus on one of each
> initially.
>
>
>