On 27 Jul 2016, at 20:51 , Joe Touch <[email protected]<mailto:[email protected]>> wrote:
On 7/27/2016 8:27 AM, Spencer Dawkins at IETF wrote: Hi, Joe, On Wed, Jul 27, 2016 at 10:18 AM, Joe Touch <[email protected]<mailto:[email protected]>> wrote: Olle, On 7/27/2016 5:41 AM, Olle E. Johansson wrote: > ... > > This mess caused me sadly to suggest that we need to discuss breaking the > assumption that TCP delivery is always reliable > and implement retransmits even over TCP in the STUN protocol. STUN was > designed to discover middleboxes > with a focus on NAT. This is just another middle box to discover. None of this is news. One of the "features" of middleboxes is "transparent" TCP relaying. That device always destroys TCP reliable delivery semantics. This has been known since the mid 90s'. Right. IIRC, you and I were part of a number of conversations about this in PILC, while working on https://www.ietf.org/rfc/rfc3135.txt. Yup - I'm just observing that this (mis)behavior has been seen in the wild since the mid 90s. It was the topic of much discussion at the Web Caching Workshops of that era. My reason for asking Olle to bring this forward is that we're having a lot of conversations (starting at the IAB with https://www.iab.org/activities/workshops/marnew/ and headed toward IETF working groups) with wireless carriers about encryption and about UDP-based transports, and I wanted to level-set on what people are (still) seeing these days. Sure - my point is that the term "transparent proxy" is common, and ALL such animals break TCP semantics *by design*. Yes, it's possible to recover TCP semantics at a higher layer using transaction confirmations, but that just sets up a game of mutual escalation - once you do that, someone will invent a transparent transaction proxy and you'll be back where you started. IMO, transparent proxies should be considered the errors the are, detected, and removed. Fully agree. And the best solution I can imagine for this removal, avoiding at the same time mutual escalation, is precisely the idea of a controlled endpoint-path collaboration framework a-la-PLUS. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: [email protected] Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
