RE: ECN in QUIC

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

Hi

And sorry for the sloth-ish response (you should see me type  a text message..).
To summarize the two main questions


  1.  ECN in ACK frame or in a separate frame : Given the recent discussion on the list and fear that the ACK frame is already enough complex, it seems unwise to try to cram in additional info in the ACK frames. So my personal feeling is that we should use a separate frame type for ECN , but this frame type must be a MUST to implement and support ! Comments are very welcome.
  2.  As regards to the level of detail : There are pros and cons with both alternatives (marked bytes or detailed indication). I would like to hear the opinions from others as well on this matter .

/Ingemar

From: Colin Perkins [mailto:[e-mail]]
Sent: den 16 augusti 2017 12:53
To: Ingemar Johansson S <[e-mail]>
Cc: QUIC IETF mailing list <[e-mail]>; Magnus Westerlund <[e-mail]>; Bob Briscoe ([e-mail]) <[e-mail]>; Praveen Balasubramanian <[e-mail]>; Eggert, Lars ([e-mail]) <[e-mail]>; marcelo bagnulo braun <[e-mail]>; Mirja Kühlewind <[e-mail]>; Piers O'Hanlon <[e-mail]>; De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]>
Subject: Re: ECN in QUIC


On 16 Aug 2017, at 10:33, Ingemar Johansson S <[e-mail]<mailto:[e-mail]>> wrote:

Hi

Finally back from vacation, and very grateful for the support to continue the work to add ECN in QUIC.
Just to recap.. there were two main topics raised at the meeting

1) ECN info in ACK frame or in dedicated frame : There were concerns about adding extra complexity in an already potentially complex ACK frame, one can have differing opinions about the complexity but can understand the concerns. As far as I am concerned, a separate frame type for ECN is possible, possibly one need to add information about the amount of not-ECT marked packets as well to keep the signaling robust, this needs further investigation though. One concern with a separate ECN frame is that it becomes a not-implemented or optional feature, is there any reason to be worried about this ?

2) More detailed ECN information : Earlier versions of the ECN in QUIC draft (seehttps://tools.ietf.org/id/draft-johansson-quic-ecn-01.txt ) provided with examples. We (Myself, Koen, Mirja and Praveen) discussed this and we could not come up with any use case where it is beneficial to know exactly how each packet is ECN marked. I know that this kind of detailed ECN information is suggested for the generic feedback for RMCAT and I personally have a problem to see the gain with the detailed ECN information also here. Input from others is very welcome here.

For the RMCAT format, we wanted per-packet loss and timing information, and it was as easy to feedback per-packet ECN information along with it as to design something different.

A benefit of per-packet ECN marking could be to allow a congestion controller that reacted differently to bursts of consecutive ECN marks than it did to isolated ECN marks, given the same fraction of marked packets (i.e., that reacted to ECN marking events rather than ECN marking rate, like how TCP responds to loss events). I don’t think we have such a thing, but certainly in the context of RMCAT where we’re experimenting with novel congestion control schemes for traffic that has very different characteristics to traditional bulk flows, it might be plausible. Per-packet marking information is also useful for troubleshooting.

Certainly we need to know number of NotECT, ECT(0), ECT(1), and ECN-CE marks since the last report, but I guess that’s already possible.

Cheers,
Colin





There are a consequences with detailed ECN marking information.
a) necessary to correlate with the list of transmitted packets, this increases amount of code on sender side, not sure of that is a large concern as lookup is anyway needed to process incoming ACKs
b) necessary to embed ECN information in ACK frame ?, at least this was my conclusion when I devised the detailed ECN marking info in the 01 version of the draft.

Comments are welcome
/Ingemar



==================================
Ingemar Johansson  M.Sc.
Master Researcher

Ericsson AB
Wireless Access Networks
Labratoriegränd 11
971 28, Luleå, Sweden
Phone [phone]
SMS/MMS [phone]
[e-mail]<mailto:[e-mail]>
www.ericsson.com<x-msg://103/www.ericsson.com>

A mistake is to commit a misunderstanding
                     Bob Dylan
==================================



--
Colin Perkins
https://csperkins.org/