[rmcat] Following up on my ECN feedback question at the meeting today
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Thu, 17 November 2016 10:21 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD095129591 for <rmcat@ietfa.amsl.com>; Thu, 17 Nov 2016 02:21:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level:
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qxx7RP7p26gn for <rmcat@ietfa.amsl.com>; Thu, 17 Nov 2016 02:21:32 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0D7129641 for <rmcat@ietf.org>; Thu, 17 Nov 2016 02:21:32 -0800 (PST)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id A1AEF1B00266 for <rmcat@ietf.org>; Thu, 17 Nov 2016 12:19:14 +0000 (GMT)
Message-ID: <582D8488.1000200@erg.abdn.ac.uk>
Date: Thu, 17 Nov 2016 10:20:56 +0000
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: rmcat@ietf.org
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/RnZ9DJFFNNIsaFmxRVWcyV6S2lM>
Subject: [rmcat] Following up on my ECN feedback question at the meeting today
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rmcat/>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Nov 2016 10:21:43 -0000
I have some follow-up comments on things relating to the transport use of ECNthat may relate to draft-dt-rmcat-feedback-message-01. (1) My meeting comment on jabber was (I may have missed the point earlier in the talk) that I wanted to check if a new method could potentially hide the presence of a CE-Mark (specifically receiving a CE-marked packet and not reporting this seems like something we may wish to worry about and I could not work out is the proposal ever omitted ECN information). (2) Now looking at the design team draft, this statement is of course OK with me: "If ECN [RFC3168] is used, it is necessary to report on the 2-bit ECN mark in received packets, indicating for each packet whether it is marked not-ECT, ECT(0), ECT(1), or ECN-CE." And following this it seems to me that there are two very basic pieces of information that I’d love to be able to know as a sender when using an ECN-capable network: (2a) It *can* be important to know that an ECT(?) codepoint is being received at the IP layer. A sender may well know that it is sending either ECT(0) or ECT(1), but doesn’t definitely know these are being received unchanged (i.e., the path has not remarked these). - Reporting all ECN marks would clearly satisfy this - read no further if you plan to always do this. - A count of how many ECT marks were received is really helpful to know that the current ECN forwarding path is broken, it could even allow a sender to check that any chosen ECT(x) encoding is working, by independently setting x=0 or x=1, if it wishes. - Knowing which specific ECT(?) is received is potentially useful information. This could perhaps be used in a method to determine which flavour of ECN-marking is supported by a path, and more info about whether ECN is being handled correctly by a network (knowing middleboxes don’t do unwanted things can always utilise extra information). (As new info, the TSVWG is currently considering work proposing to eliminate the use of NONCE encoding where an apps sends ECT(0) and ECT(1) randomly. This could simplify the need to encode which ECT(?) codepoints were received - see draft-black-tsvwg-ecn-experimentation.) (2b) A sender must *at least* know if there were any CE marks in a reporting interval. - If you report each CE received than this is sufficient. But I have a word of caution. *If* an app looses a report with a CE-mark report it may never know, and does not impact user experience in terms of loss, but the CC still needs to respond to behave correctly for AQM, and may impact delay :-). - It can be very valuable for the sender to know if ANY CE-marked packets were received, even if sending not-ECN capable packets at this moment (where it is an error that indicates ECT(?) is unreliable). - Knowing how many CE-marks (or CE-marked bytes) per interval is probably really valuable for a CC. I’d think a sender could easily utilise more CE per packet information, and may need to do (e.g., to utilise L4S should that be wanted in future). - Knowing each CE-mark is something that any CC can utilise and could be needed for L4S. It could also help to know about whether bursts are being marked, rather than average rate. - Some AQMs may use shallow marking and that is something that COULD be nice to detect in future from per-packet CE-mark reports. (At the moment, I really think we don’t completely know yet how to do this). So to me, this suggests at least some counters per reporting interval are needed - and per-packet info will be much better. (3) In relation to "Feedback Frequency and Overhead", section 4. I have one less useful comment: Amortising overhead by reporting less often could perhaps result in a performance tradeoff. There may well be quite stringent timing implications if an RMCAT app wants to use "low latency" ECN - that’s something to be watched as the transport as the L4S work in TSVWG progresses, but it would be nice to know that the report interval does not constrain our options. I’m arguing that the WG may need to note this (or consider this), but I for one, don’t yet know how this will evolve in future. In case anyone needs it, draft-ietf-aqm-ecn-benefits-08 may have some more info. Best wishes, Gorry
- [rmcat] Following up on my ECN feedback question … Gorry Fairhurst
- Re: [rmcat] Following up on my ECN feedback quest… Michael Ramalho (mramalho)
- Re: [rmcat] Following up on my ECN feedback quest… Gorry Fairhurst
- Re: [rmcat] Following up on my ECN feedback quest… Bob Briscoe
- Re: [rmcat] Following up on my ECN feedback quest… Ingemar Johansson S