------------- Conex meeting minutes MONDAY, July 29, 2013 1300-1500 CEST note taker: Dirk Kutscher Agenda bashing, 5 mins Chairs ---------------------------------------------------------------------- Abstract mechanism, 20 mins Bob draft-ietf-conex-abstract-mech-07 http://datatracker.ietf.org/doc/draft-ietf-conex-abstract-mech/ http://www.ietf.org/proceedings/87/slides/slides-87-conex-0.pdf Bob Briscoe presenting Marcelo: (on slide #4): out of all requirements, which ones are already fulfilled by current specs? Bob: v6destopts does not reflect credit requiments yet Suresh: (on slide #4): proxy needs clarification Bob: transport layer proxy Marcelo: (on security consideration): need input from AD Martin: depends on text, better recap security-related text in security considerations section Marcelo: conceptual (high-level ideas) security considerations (also counter measures) could be useful to have Alissa: you already have a high-level of threats. Perhaps also ask for an early security directorate review Bob: ack Marcelo: next steps: new security sections, new text on audit ---------------------------------------------------------------------- TCP extensions, 20 mins Mirja http://tools.ietf.org/html/draft-ietf-conex-tcp-modifications-04 http://www.ietf.org/proceedings/87/slides/slides-87-conex-1.pdf Mirja presenting Jana: (on sender requirements): negotiating both SACK and ECN difficult to require (MUST), so that's why SHOULD is better Mirja: thinks have addressed open issues, need more reviews, could go to WGLC Jana: want to respond to e-mails on the mailing list Roberto: just read through document. Did not see answered to spoofing ECN packets issue. Mirja: probably not a conex issue, more of a general ECN issue Bob: conex is explicitly not doing congestion charging, i.e., it can work wel with fixed price charging Bob: whole Conex loop is designed to avoid ECN spoofing (abstract mech) Marcelo: next steps will depend on mailing list discussion Mirja: yes, there will probably also be changes to ipv6 draft ---------------------------------------------------------------------- Credits, 20 mins David https://datatracker.ietf.org/doc/draft-wagner-conex-credit/ http://www.ietf.org/proceedings/87/slides/slides-87-conex-2.pdf David presenting Mirja: #slide 12: surcharge seems to be the easiest variant. But's experimental anyway, need to figure out what realy works best Marcelo: do you think this should be added to abstract mechanisms? could be included as a high-level discussion... Mirja: final protocols needs to define credit very clearly. Mirja: either decide now (and maybe change later) or keep it open -- preference is to decide now Mirja: probably in ipv6 doc Marcelo: develop ipv6 doc into fullfleshed protocol document? Bob: yes, supporting to define credit in ipv6 doc (and not in tcp doc) Marcelo: OK, summary: add the definition of credit to ipv6 doc Mitch: thrilled by existence of this proposal. 802 tries to start something similar (credit). would be interested to extend this beyond tcp. some questions: RTT range: what do you expect for minimum and maximum RTT, in DC: 4 msec + several order of magnitudes more variable link capacity (PFC): issues with BDP RTT fairness -- TCP: do we care? David: out of scope for credit mechanism (independent) in DC, assuming lossless environment -- credits and marked packets will never be lost -- but RTT variations Mirja: there is draft on conex in DCs David: auditing needed for non-trusted environments Mitch: yes, but DC have multi-tenancy -- that's why credit is still important Marcleo: do you think do describe options for credit in abstract mech? Bob: perhaps credit doc could evolve in audit doc -- too many options for abstract mechanisms Marcelo: what's the impact of this decisions on tcp and abstract mechs? Mirja: propose to use the second definition (surcharge), and then there would be some changes in tcp doc Bob: need to assess potential security problems in parallel Marcelo: next steps: include credit definition in ipv6 doc and add corresponding text in tcp doc. finish old docs first, before starting new audit document ---------------------------------------------------------------------- Conex implementation, 10 mins David http://www.ietf.org/proceedings/87/slides/slides-87-conex-3.pdf David presenting no questions ---------------------------------------------------------------------- Network Performance Isolation in Data Centres using Congestion Policing draft-briscoe-conex-data-centre-01 10mins, Bob http://www.ietf.org/proceedings/87/slides/slides-87-conex-4.pdf http://www.ietf.org/id/draft-briscoe-conex-data-centre-01.txt Bob presenting Mitch: more precise congestion protocol than ECN? Bob: important things is how many signal you get per RTT (not per packet) Ning: proposing conex/ecn support in guest OSs? Bob: yes, implementations are starting, but takes some time. this approach would work for all traffic Ning: yes, it's a good idea, also for NFV Mitch: does it make sense to have a coarse version of conex for a tunnel and a more precise variant for actual packets? Bob: here, you could police both together Marcelo: need to finish use case documents, try to get more people interested Marcelo: need to re-charter to adopt new documents? Martin: need to finish old documents before starting new Bob: would be good to show this to other people to get them interested ---------------------------------------------------------------------- Network Performance Isolation using Congestion Policing draft-briscoe-conex-policing-00 5mins, Bob http://tools.ietf.org/html/draft-briscoe-conex-policing-00 http://www.ietf.org/proceedings/87/slides/slides-87-conex-5.pdf Bob presenting no questions