[tcpm] Progress with draft-ietf-tcpm-accurate-ecn

Bob Briscoe <research@bobbriscoe.net> Fri, 15 March 2019 10:58 UTC

To: tcpm IETF list <tcpm@ietf.org>, Yuchung Cheng <ycheng@google.com>, Praveen Balasubramanian <pravb@microsoft.com>
From: Bob Briscoe <research@bobbriscoe.net>
Message-ID: <0d9977c9-e774-0498-4218-afe62ebb85fd@bobbriscoe.net>
Date: Fri, 15 Mar 2019 10:57:59 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------114F238141634174502E3168"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/EGM8m5tYjM8lWSaCpFa6v5sTkCQ>
Subject: [tcpm] Progress with draft-ietf-tcpm-accurate-ecn
Precedence: list

Hi folks,

A few weeks ago we had two main outstanding issues with AccECN:
* Unclear whether the AccECN Option is optional to implement
* Lack of consensus on how to address generic receive offload hardware

Last Monday, we posted a new revision of the draft:
https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-08

==AccECN TCP Option: Optional to implement==
Hopefully it is now very clear that the AccECN Option is optional to 
implement. Given middleboxes could block packets with it on, the sender 
of the option had to be able to not send it, and the potential receiver 
of the option had to be prepared not to receive it anyway. So there was 
no point trying to make it mandatory to implement.

@Praveen and possibly others have been uncertain of what the draft 
required, so pls check whether you are now happy that the text allows 
you to not do what you don't want to do.

==GRO Hardware==
Inherently, ECN and its feedback make headers toggle, which ejects the 
currently cached header from current GRO hardware.
@Yuchung likes DCTCP-style feedback 'cos it doesn't change if there's a 
run of unchanged markings and you often get unchanged runs with the step 
marking of DCTCP. However, some people would like to move from step to 
ramp-marking, which would allow DCTCP to be more responsive. There is no 
style of feedback (neither DCTCP, AccECN or anything) that hardware is 
currently optimized for when ECN is toggling randomly (as it is designed 
to). So ultimately we need NIC hardware to be optimized for the inherent 
variability of ECN.

Therefore, given DCTCP's inherent unreliable delivery, we've decided to 
forge ahead with AccECN as it is. Then NIC hardware developers will know 
which scheme it is worth optimizing for. That's the role of standards 
(even experimental ones).

==Forward Compatibility==

I ran through a full check of all the fields to check we'd specified 
what to do for every value that might be used in the future. We'd caught 
nearly all of them, but added a new section to capture these:
3.1.2 Forward Compatibility 
<https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-08#section-3.1.2>

==Implementation==
Mirja has ported her Linux implementation to a later Linux kernel and 
Olivier Tilmans is porting that to v5.0.
I just forwarded the invitation to work on TCP Prague the hackathon on 
the Sat before the IETF in Prague. The idea is particularly to update 
AccECN to the lastest draft revision.


Bob


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

[tcpm] Progress with draft-ietf-tcpm-accurate-ecn Bob Briscoe