dispatch meeting minutes - IETF 102  - 9:30am Monday *chairs discuss ietf 103 deadlines (see slide) * ben schwartz presents his helium draft (see slides in materials) - lucas pardue will be doing another aspect of this work in httpbis this work - http connect works on TCP tunnel, questionable application for quic - ekr says nats make this into lies, ben agrees - cullen - asks ben to talk about the security properties -= ben replies proxy must (if udp aware) it should have address aware filtering characteristics.. 'full cone behavaior'? - adam roach asks if this is for real time, or is it for tunneling quic like things -= ben says his goal is to find a general purpose solution - adamn says that udp over tcp is a concern in that case -= ben says the goal is use quic as the substrate instead of tcp -= ben is interested in websocket like systems that run over quic -= goal is to run over http to be self proxying - so rejects datachannels as an idea. need to decouple what helium runs on and what http runs on - adam advocates for language about this problem -= ben says lucas has other ideas including new frame types wihch might apply easier to quic - harald alverstrand - says that http is not self proxying because ???? (sometihng about the host header) - harald is also concerned about layered congestion control as was adam - harald thinks you can find a cleaner way to tell a nat to forward packets and that he is sad - martin thomson acknowledges haralds concerns, but thinks the goals are solid. the approach needs work. is this TURN? -= ben says sort of. [back and forth re architecture vs sytnax, martin makes clear he is talking about architecture] -= helium has a best effort semantic that reflects a pessimistic view of connectivity on the internet - mike bishop - thinks base case of CONNECT via proxy with quic is important - mike bishop points out that websockets are in order and hol blocking - justin uberti - speaking to cc inside cc. I run a very large turn deployment and in practice it works better than you would think it should. - more ju - multiple tcp conns really help - bernard a - fixable with communication between the layers. might help to focus on the proxy issue. - subodh iyengar - are you assuming that the target server has no idea about the hybrid encap protocol? (ben - yes). there is a fundamental -                  diff between http proxying and the nat approach; in that the end http target participates. (walks that back) -                  but there is a way the target server participates.. such as GRE which enables direct server return -= ben says: the design more resembles a nat.  - ted hardie - you're assuming http/quic not just quic and that makes it hard to do application level dispatch - cullen; there's a lot of interest here. always questions in proxy protocols about whether it is ART or TSV            need more list discussion to peel the next layer of the onion until it can be dispatched            the dispatch list seems like the right place. 2 AD thumbs up. Will continue discussing HELIUM on dispatch email list