FWIW, as I am rather sure the ISP guy Michael mentions is yours truly, let me say that I have been working for commercial providers, where strongly structured procedures could make more difficult for this mechanism to work (though we should not neglect cumulative effects), and for the academic networking environment, where something like a text message could have real short-time effects...
Be goode, On 30 Jun 2015, at 20:08 , Michael Welzl <[email protected]<mailto:[email protected]>> wrote: On 30. jun. 2015, at 19.58, Joe Touch <[email protected]<mailto:[email protected]>> wrote: On 6/30/2015 10:54 AM, Michael Welzl wrote: On 30. jun. 2015, at 19.03, Joe Touch <[email protected]<mailto:[email protected]>> wrote: On 6/30/2015 2:17 AM, Michael Welzl wrote: On 30. jun. 2015, at 01.21, Joe Touch <[email protected]<mailto:[email protected]>> wrote: +1 On 6/29/2015 4:06 PM, joel jaeggli wrote: ignoring for a second the question of information leakage which is apparently intentional in this case; an icmp message is unlikley to hash onto the same path that the offending/failed flow would have been on in many networks. When you say "middlebox" you're opening up the set that includes NATs, and that means any message that isn't to the same address/port pair isn't likely traverse the same path. - "might not take the same path all the way due to ECMP" is how I'd put it. What makes you say "isn't likely to traverse the same path"? If you're tracing back through other NATs, and you're on the public side at some point along the path, the ICMP cannot be translated. Further, if you're on the private side of a NAT with multiple IP addresses (e.g., CGN), again the ICMP cannot be translated. These are a property of some of the very middleboxes you're trying to reach, not of ECMP. So *at best* this might be able to contact the first middlebox it encounters, Not true in my office. Am I really the only one? This message can traverse from the private to the public side of any NAT with only one IP address, but cannot traverse into the private side of a NAT or from private to public of CGN. I'm guessing you're testing only cases where the latter doesn't happen. Got it now, sorry for the confusion. So I don't really care much about the middlebox behind a NAT on the other side - it's *my* side I care about. The usage examples in the draft refer to talking people in my institution or at the airport where I'm sitting. I don't expect to be (or care about being) able to talk to a middlebox far, far away... chances are, the message is dropped long before anyway. It's a limitation; it might be useful to explain the limitation and why the remainder is still useful. ok ... (I'm also ignoring the fact that most middleboxes don't want to admit they exist, so this might be only providing another way for them to ignore you) That's a strange argument: Middleboxes often want to appear invisible except for *their* purposes. I.e., you're sending them more information that they already ignore (and intend to ignore), IMO. Still a strange argument :-) I can send them 100 other more things that they can ignore, how is that making anything worse? Could be a router, could be some administrator at the first-hop border router of my ISP, could be a person trying to run a public network at a conference or in an airport ... all these people I want to try to reach. Some of them have an interest in hearing feedback which they now can't get (at an airport, I wouldn't know who to talk to and wouldn't want to go around and ask, so why bother - but sending a short message is really not so painful). Sure. I'm just suggesting that you're working very hard to contact someone who doesn't want to pick up the phone. I'm not sure the effort will be worth the result. Not working hard at all :) this is a very simple draft, it's just a packet carrying text! This doesn't change much for anyone and is harmless as can be, I'd say - so it might be worth trying. It could be useful (and I heard that confirmed by an ISP today). Happy to give up if folks think it's useless, but not because it doesn't go through the NAT on the other end or because it's not rate-limited. I don't mind putting recommendations in there! I mean, else someone could quickly send 100 "open the port, you twit !" messages and fill up the logfile, god beware :-) How in the world would we cope with that? :-) I'd like to hear from the ISP side... or middlebox maintainer side. Surely some folks from that side must be here - would you want such a thing or do you think it's useless? That's the only interesting question for this draft IMO Cheers, Michael _______________________________________________ Int-area mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/int-area -- "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
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
