ECN-QUIC side meeting Nov 16 2017
Time : 16.00-17.00 
Location : Hullet Room, IETF-100 Singapore
Meeting chair: Ingemar Johansson 
Attendees : Lars Eggert, Gorry Fairhurst, Bob Briscoe, Stuart Cheshire, Magnus Westerlund, Koen De Schepper, Roni Even, Mirja Kühlewind (briefly), David Schinazi, Huawei-unknown, Akamai-unknown

Meeting notes
===========================================================
The note well was presented to all the attendees.

Summary:
 A design team will be formed with a limited number of persons with the following objective.
 + Update the ECN-QUIC wiki for QUIC v1 with 
  + simplified ECN capability exhange. The coarse outline is that each endpoint sets 
    ECT(0) or ECT(1) in the first packet, the receiving enpoint then echoes back this 
    information in a new ACK frame with ECN field. Both endpoints follow this procedure.
  + Subsequent data after ECN capability exchange is transmitted with Not-ECT. 
    This means that only the capability exchange does ECN. 
    Full ECN implemenation is left for a futuire QUIC v1.1 or whatever.
  + ACK frame with ECN field.
  + ECN wireline spec (i.e ACK frame with ECN) and capability exchange is mandatory to 
    implement in QUIC v1.0
  + Connection migrations aspects are defined, this means that ECN capability 
    exchange should be carried out also in the ping/pong and response to pong.
  + People in design team : Ingemar Johansson + WHO  ?

 + When wiki updates are finalized. Move to a draft and have a first review (suggested mid december). 

 + First draft submitted in time for QUIC interrim in Melbourne, Jan 23-25 2018. 
   Apple person (sorry missed the name) may go to Melbourne and can consider to present it. 
   Stuart offered to check the possibilities.

 + If delivery not possible for Melbourne meeting then it must be presented at IETF-101 in London.

 + First draft should be simple. Each added page reduces acceptance with 1% (Lars Eggert)

Other stuff:
 + ECN black holes are considered very rare these days, no additional work 
   should be done to handle this. 
   Gorry mentioned some happy eyeballs, it needs to be better explained what this implies?. 

 + ECN bleaching is a real problem that will hopefully go away over time but this must be 
   handled in the ECN capability exchange.

 + The earlier proposed ECN capability exchange is regarded as overly complicated, the updated 
   version will be much more simple.

 + The ECN field in the ACK frame is likely too large to be accepted, work is needed to 
   make this more compact. It is here helpful that ACKs are ACKed too and that deltas can 
   be encoded safely.  

 + ECN after capability negotiation is enabled after v1.0, this will also include a 
   specification of a ECN congestion response.

 + Timestamps (according to https://github.com/quicwg/base-drafts/wiki/Time-stamps-in-QUIC ) 
   are not included