From detlef.bosau at web.de Fri May 1 04:38:58 2015 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 01 May 2015 13:38:58 +0200 Subject: [e2e] j'accuse NFV In-Reply-To: <20150501024931.B4CCF2C4066@rock.ICSI.Berkeley.EDU> References: <20150501024931.B4CCF2C4066@rock.ICSI.Berkeley.EDU> Message-ID: <554365D2.9020909@web.de> Am 01.05.2015 um 04:49 schrieb Vern Paxson: >> Perhaps my comment is a typical "Detlef" comment, but again I look at >> ... >> Sorry for the rant, but during the last years, I got crazy on these things. > It's okay, we know to just ignore your messages. > > Vern You may well ignore them, but that does not change reality. Of course, you can ignore reality as well. May I refer to *Title:* Beyond the Radio: Illuminating the Higher Layers of Mobile Networks *Author:* N. Vallina-Rodriguez, S. Sundaresan, C. Kreibich, N. Weaver, and V. Paxson *Bibliographic Information: *ICSI Technical Report TR-14-003 *Date:* December 2014 *Research Area: *Networking and Security *Type: *Technical Reports *PDF:* https://www.icsi.berkeley.edu/pubs/techreports/TR-14-003.pdf Let me only quote the abstract. > Cellular network performance is often viewed as primarily dominated by > the radio technology. > However, reality proves more complex: mobile operators deploy and > configure their networks > in different ways, and sometimes establish network sharing agreements > with other mobile > carriers. Moreover, regulators have encouraged newer operational > models such as Mobile > Virtual Network Operators (MVNOs) to promote competition. In this > paper we draw upon data > collected by the ICSI Netalyzr app for Android to develop a > characterization of how operational > decisions, such as network configurations, business models, and > relationships between > operators introduce diversity in service quality and affect user > security and privacy. We delve in > detail beyond the radio link and into network configuration and > business relationships in six > countries. We identify the widespread use of transparent middleboxes > such as HTTP and DNS > proxies, analyzing how they actively modify user traffic, compromise > user privacy, and > potentially undermine user security. In addition, we identify network > sharing agreements > between operators, highlighting the implications of roaming and > characterizing the properties > of MVNOs, including that a majority are simply rebranded versions of > major operators. More > broadly, our findings highlight the importance of considering > higher-layer relationships when > seeking to analyze mobile traffic in a sound fashion. And then, let's shorten the thing to come to the point. Or better, in this case to the colon: > Cellular network performance is often viewed as primarily dominated by > the radio technology. > However, reality proves more complex: Up to now, anything sounds fine. Up to now, one could think, we eventually learned that network performance is NOT primarily dominated by the radio technology. And I sincerely hoped to read, that mobile network performance IS primarily dominated by the radio channel's condition and in case of cellular networks by the cell occupation. When we have a longer look at the TR, we get one of those, frankly spoken, distracting discussions of the "higher layers" in mobile networks and we try to understand and to solve "problems" in wireless networks, which occur on the radio channel itself. If your signal, e.g., suffers total extinction due to multipath interference, you neither can help it by "management" or by "business models" or by netalyzr gadgets for ANDROID,. You may ignore my post - and in case of an extinct signal, you even don't need doing so - you will simply not receive it, because you are disconnected. No matter, how sophisticated your business model or how intelligent your upper layers will be. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Fri May 1 06:02:33 2015 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 01 May 2015 15:02:33 +0200 Subject: [e2e] j'accuse NFV In-Reply-To: <554365D2.9020909@web.de> References: <20150501024931.B4CCF2C4066@rock.ICSI.Berkeley.EDU> <554365D2.9020909@web.de> Message-ID: <55437969.8040509@web.de> In much shorter terms, from my personal experience, some people simply ignore the laws of physics. And this can be best observed in one single term: BANDWIDTH I don't remember the RFC, where "Bandwidth" was mentioned first, but it was taken synonymously for "throughput" or "net bit rate", even that was not properly discerned. (Please remember: Bandwidth has a well defined meaning in CE. This is neither "throughput" nor "net bit rate". ) That will hold in quite some scenarios, but latest when we talk about wireless networks, CS anc CE guys will talk completely at cross purposes and simply will not understand each other. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Fri May 1 08:38:04 2015 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 01 May 2015 17:38:04 +0200 Subject: [e2e] A very prominent example for the "bandwidth fallacy" and LFN in mobile networks. In-Reply-To: <55437969.8040509@web.de> References: <20150501024931.B4CCF2C4066@rock.ICSI.Berkeley.EDU> <554365D2.9020909@web.de> <55437969.8040509@web.de> Message-ID: <55439DDC.6050204@web.de> The following article deals with GPRS. > @article{ meyer, > author ="Michael Meyer and Joachim Sachs and Markus Holzke", > title ="{Performance Evaluation of A TCP Proxy in WCDMA Networks}", > journal ="IEEE Wireless Communications", > year = "2003", > month = "October" > } > Let me quote only a short passage from "TCP in the context of WCDMA": > Depending on the assigned data rate, > WCDMA offers links with small to large band- > width delay products. For simplicity, the working > assumption of a TCP RTT of 500 ms is used for > the following considerations. For 64 kb/s this > would result in a bandwidth delay product of 4 > kbytes, but for 384 kb/s it would be 24 kbytes. > The latter value is large enough to cause a link > underutilization for three to six round-trips > depending on the maximum segment size (MSS) > and the initial window size of TCP used for a > particular TCP connection. I intentionally will not delve into the gory details of GPRS here, but this nonsense is absolutely ludicrous. What the authors actually claim is that in a TCP connection including a GPRS link with 500 ms RTT, there is 24 kByte of data IN FLIGHT! The whole discussion of "bandwidth delay products" (or to avoid the abuse of "bandwidth" rate delay products) well makes sense in the context of long lines where actually a huge number of data is in flight along the line. Imagine a long fibre, which may well have a length of some hundred kilometres and offer a data rate of, say, 2 MBit/s. This is not the case in GPRS. The authors simply ignore the fact, that GPRS employs a *recovery layer*, which is necessary to provide for acceptable SDU corruption ratios at all. Depending on the QoS profile in use (I wrote this in this list several times) the simple transport latency for a packet to be delivered over the air interface from the base station to the mobile may reach SEVERAL MINUTES. Now, there are quite a few parameters which are important here. - The line coding scheme (IIRC QPSK in early GSM/GPRS versions, in more recent flavers 64 QAM or 256 QAM) - The channel coding scheme (four different ones, when I started to work with mobile networks) - The RLP in use: IP packets are not conveyed as one single piece here, the loss ratio would be far to high, typical payloads for Radio Link Protocols here are 20 to 24 byte. So there is some overhead depending on the RLP in use. - The scheduling scheme, GPRS allows up to 8 mobiles in one cell. All these things can be modified by management layers etc. And of course, the achievable throughput may be severely decreased, if,e.g., the channel coding scheme or the line coding scheme are chosen inappropriately. Nevertheless, the most important factor which dominates the achievable throughput is the radio channel itself. When even BPSK for line coding and the most robust channel coding, GPRS has to offer, don't succeed to deliver a RLP block in one or two attempts but a block needs up to 200 or 400 sending attempts until it eventually is successfully received, we can play "three man in a boat" with the tin of pine apples: We can hammer the management square, we can hammer the management flat, we can hammer the management to all forms known to geometry. The throughput won't increase. However, we would have an explanation for the 500 ms RTT. Which alone debunk the "perpetuum mobile" nonsense in the quoted paper. We all know the saying: "You cannot make a silk purse from a sows ear." -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From mattmathis at google.com Fri May 1 10:42:23 2015 From: mattmathis at google.com (Matt Mathis) Date: Fri, 01 May 2015 17:42:23 +0000 Subject: [e2e] j'accuse NFV In-Reply-To: <55437969.8040509@web.de> References: <20150501024931.B4CCF2C4066@rock.ICSI.Berkeley.EDU> <554365D2.9020909@web.de> <55437969.8040509@web.de> Message-ID: I tried to fight the "bandwidth" vs "data rate" battle years ago but came to realise that the memory, cache, bus, and CPU community (both HW and SW) were also misusing bandwidth, and had no conflicts with the "proper" use, and thus no motive to make the change. We are in the rather unique position of needing both concepts, so I always use "data rate" in my writing, but I have to admit that I often slip when speaking. Note that all jargon is always context sensitive. Ask a Orthopedist, Banker, Chemical Engineer and Computer Scientist what "process" means..... On Fri, May 1, 2015 at 6:40 AM Detlef Bosau wrote: > In much shorter terms, from my personal experience, some people simply > ignore the laws of physics. > And this can be best observed in one single term: > > BANDWIDTH > > I don't remember the RFC, where "Bandwidth" was mentioned first, but it > was taken synonymously for "throughput" or "net bit rate", even that was > not properly discerned. (Please remember: Bandwidth has a well defined > meaning in CE. This is neither "throughput" nor "net bit rate". ) > > That will hold in quite some scenarios, but latest when we talk about > wireless networks, CS anc CE guys will talk completely at cross purposes > and simply will not understand each other. > > > -- > ------------------------------------------------------------------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673 > detlef.bosau at web.de http://www.detlef-bosau.de > > _______________________________________________ > end2end-interest mailing list > end2end-interest at postel.org > http://mailman.postel.org/mailman/listinfo/end2end-interest > Contact list-owner at postel.org for assistance. > From detlef.bosau at web.de Fri May 1 12:20:38 2015 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 01 May 2015 21:20:38 +0200 Subject: [e2e] j'accuse NFV In-Reply-To: References: <20150501024931.B4CCF2C4066@rock.ICSI.Berkeley.EDU> <554365D2.9020909@web.de> <55437969.8040509@web.de> Message-ID: <5543D206.4000701@web.de> Am 01.05.2015 um 19:42 schrieb Matt Mathis: > I tried to fight the "bandwidth" vs "data rate" battle years ago but > came to realise that the memory, cache, bus, and CPU community (both > HW and SW) were also misusing bandwidth, and had no conflicts with the > "proper" use, and thus no motive to make the change. We are in the > rather unique position of needing both concepts, so I always use "data > rate" in my writing, but I have to admit that I often slip when speaking. > > Note that all jargon is always context sensitive. Ask a Orthopedist, > Banker, Chemical Engineer and Computer Scientist what "process" > means..... > Your general observation is correct, however in the particular case CS and CE, the "dual meaning" of "bandwidth" makes communication difficult. Particularly as the CE stuff is often difficult to understand (I'm a CS guy myself). Think of a simple WLAN cell. How often do we see the question "how does noise affect the bandwidth?" or "does cell occupation affect the bandwidth?" and it is difficult to explain, that neither noise nor cell occupation affects "the bandwidth". The frequency band used for packet transmission is always the same. What is affected is the allocation of a sending time (by the CA-mechanism) and the number of transmission attempts which is necessary to eventually have the packet received. The situation is more complex, when it comes to mobile networks and more sophisticated channel coding techniques, e.g., the multicode operations in HSDPA, where we fully exploit a spreading gain in noisy channels, when only one code is used, or we don't exploit the maximum spreading gain when the channel is less noisy and the full robustness isn't necessary, when we use several codes. Nevertheless, I well remember years of working with the NS2, where "bandwidth" was used as a characteristic parameter for a link - eventually to calculate the serialization delay of a packet. As far as I see, most of our simulators work in the same way. As a consequence, it is extremely difficult (although attempts were made) to model or to simulate the "delivery time" for a packet over an air interface. Once again to the multicode example. The situation becomes even more difficult when you talk to people, who don't use ALL 15 codes for ONE flow (you should do so, hence, when only one code is used, the others are left empty in order to fully exploit the spreading gain) but use multicode operations to share a transport block between several flows. At least for my purpose, dealing with these things turned to be a never ending story, which didn't provide me the answer to my two essential questions: 1. Will the packet be successfully delivered? 2. How long does it take to deliver the packet? And the tough problem is not the technologies. Modelling them is often tedious and nasty - but it is possible. The tough problem is to model the wireless channel. When I talked to some guys involved in the EURANE project, the problem was, that the models modelled always more transport blocks as "corrupted" than were in reality (when the calculated results where compared to observed ones) or less. But they hardly modelled the correct corruption ratios or the real TB discards, and this problem is propagated bottom up throughout all layers. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Fri May 1 14:53:39 2015 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 01 May 2015 23:53:39 +0200 Subject: [e2e] A very prominent example for the "bandwidth fallacy" and LFN in mobile networks. In-Reply-To: <56a97497-faf9-4375-a3e7-9931102e1cc2@reed.com> References: <20150501024931.B4CCF2C4066@rock.ICSI.Berkeley.EDU> <554365D2.9020909@web.de> <55437969.8040509@web.de> <55439DDC.6050204@web.de> <56a97497-faf9-4375-a3e7-9931102e1cc2@reed.com> Message-ID: <5543F5E3.6020703@web.de> In a sense, Ham is nothing else than "WiFi in big" :-) So, the problems should be pretty much the same. Perhaps, Ham misses the /CA and the line coding is certainly more simple than in WiFi, but the basics should be very similar. Am 01.05.2015 um 20:40 schrieb David P. Reed: > Detlef's comments make huge sense to me. I'm a Ham licensee and also > quite aware of physics and networks. The nonsense in the peer review > ed literature is shameful for the most part. > > On May 1, 2015, Detlef Bosau wrote: > > The following article deals with GPRS. > > @article{ meyer, > author ="Michael Meyer and Joachim Sachs and Markus Holzke", > title ="{Performance Evaluation of A TCP Proxy in WCDMA > Networks}", > journal ="IEEE Wireless Communications", > year = "2003", > month = "October" > } > > > > > Let me quote only a short passage from "TCP in the context of WCDMA": > > Depending on the assigned data rate, > WCDMA offers links with small to large band- > width delay products. For simplicity, the working > assumption of a TCP RTT of 500 ms is used for > the following considerations. For 64 kb/s this > would result in a bandwidth delay product of 4 > kbytes, but for 384 kb/s it would be 24 kbytes. > The latter value is large enough to cause a link > underutilization for three to six round-trips > depending on the maximum segment size (MSS) > and the initial window size of TCP used for a > particular TCP connection. > > > I intentionally will not delve into the gory details of GPRS here, but > this nonsense is absolutely ludicrous. > > What the authors actually claim is that in a TCP connection > including a > GPRS link with 500 ms RTT, there is 24 kByte of data IN FLIGHT! > > The whole discussion of "bandwidth delay products" (or to avoid the > abuse of "bandwidth" rate delay products) well makes sense in the > context of long lines where actually a huge number of data is in > flight > along the line. Imagine a long fibre, which may well have a length of > some hundred kilometres and offer a data rate of, say, 2 MBit/s. > > This is not the case in GPRS. > > > The authors simply ignore the fact, that GPRS employs a *recovery > layer*, which is necessary to provide for acceptable SDU corruption > ratios at all. > Depending on the QoS profile in use (I wrote this in this list several > times) the simple transport latency for a packet to be delivered over > the air interface from the base station to the mobile may reach > SEVERAL > MINUTES. > > Now, there are quite a few parameters which are important here. > - The line coding scheme (IIRC QPSK in early GSM/GPRS versions, in > more > recent flavers 64 QAM or 256 QAM) > - The channel coding scheme (four different ones, when I started > to work > with mobile networks) > - The RLP in use: IP packets are not conveyed as one single piece > here, > the loss ratio would be far to high, typical payloads for Radio Link > Protocols here are 20 to 24 byte. So there is some overhead > depending on > the RLP in use. > - The scheduling scheme, GPRS allows up to 8 mobiles in one cell. > > > All these things can be modified by management layers etc. And of > course, the achievable throughput may be severely decreased, if,e.g., > the channel coding scheme or the line coding scheme are chosen > inappropriately. > > Nevertheless, the most important factor which dominates the achievable > throughput is the radio channel itself. When even BPSK for line coding > and the most robust channel coding, GPRS has to offer, don't > succeed to > deliver a RLP block in one or two attempts but a block needs up to 200 > or 400 sending attempts until it eventually is successfully > received, we > can play "three man in a boat" with the tin of pine apples: We can > hammer the management square, we can hammer the management flat, > we can > hammer the management to all forms known to geometry. > > The throughput won't increase. > > However, we would have an explanation for the 500 ms RTT. > > Which alone debunk the "perpetuum mobile" nonsense in the quoted > paper. > > We all know the saying: "You cannot make a silk purse from a sows > ear." > > > -- Sent with *K-@ Mail > * > - the evolution of emailing. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From jamel at cin.ufpe.br Mon May 4 05:27:05 2015 From: jamel at cin.ufpe.br (Djamel Sadok) Date: Mon, 4 May 2015 09:27:05 -0300 Subject: [e2e] j'accuse NFV In-Reply-To: References: <1430346359454.75464@surrey.ac.uk> Message-ID: Hi, May be we could also give the end user flow the possibility to say that it does not want to have its data packets processed by any NFV or even black list some NFVs (types of functions) on the path. Would this be possible to achieve? would it render NFV ineffective? can both NFV and Not NFV (bypass it) on given flows live together? Djamel On Thu, Apr 30, 2015 at 10:14 PM, Matt Mathis wrote: > On Wed, Apr 29, 2015 at 3:26 PM, wrote: > > > Ah, j'accuse TLA. > > > > SDN is not is the same bucket, let me assure you. > > As for TCP, good algorithms are portable between protocols, bad algorithms > are dangerous at any scale. Once you fully deconstruct the protocol, I > don't care so much about the packet format. > > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > > Privacy matters! We know from recent events that people are using our > services to speak in defiance of unjust governments. We treat privacy and > security as matters of life and death, because for some users, they are. > _______________________________________________ > end2end-interest mailing list > end2end-interest at postel.org > http://mailman.postel.org/mailman/listinfo/end2end-interest > Contact list-owner at postel.org for assistance. > From kelsayed at gmail.com Mon May 4 06:29:04 2015 From: kelsayed at gmail.com (Khaled Elsayed) Date: Mon, 4 May 2015 15:29:04 +0200 Subject: [e2e] j'accuse NFV In-Reply-To: References: <1430346359454.75464@surrey.ac.uk> Message-ID: You mean like a hacking packet would say please don't process me via that nifty NFV firewall or something :-) Khaled On Mon, May 4, 2015 at 2:27 PM, Djamel Sadok wrote: > Hi, > > May be we could also give the end user flow the possibility to say that it > does not want to have its data packets processed by any NFV or even black > list some NFVs (types of functions) on the path. Would this be possible to > achieve? would it render NFV ineffective? can both NFV and Not NFV (bypass > it) on given flows live together? > > Djamel > > > On Thu, Apr 30, 2015 at 10:14 PM, Matt Mathis > wrote: > > > On Wed, Apr 29, 2015 at 3:26 PM, wrote: > > > > > Ah, j'accuse TLA. > > > > > > > SDN is not is the same bucket, let me assure you. > > > > As for TCP, good algorithms are portable between protocols, bad > algorithms > > are dangerous at any scale. Once you fully deconstruct the protocol, I > > don't care so much about the packet format. > > > > Thanks, > > --MM-- > > The best way to predict the future is to create it. - Alan Kay > > > > Privacy matters! We know from recent events that people are using our > > services to speak in defiance of unjust governments. We treat privacy > and > > security as matters of life and death, because for some users, they are. > > _______________________________________________ > > end2end-interest mailing list > > end2end-interest at postel.org > > http://mailman.postel.org/mailman/listinfo/end2end-interest > > Contact list-owner at postel.org for assistance. > > > _______________________________________________ > end2end-interest mailing list > end2end-interest at postel.org > http://mailman.postel.org/mailman/listinfo/end2end-interest > Contact list-owner at postel.org for assistance. > From jamel at cin.ufpe.br Mon May 4 10:55:28 2015 From: jamel at cin.ufpe.br (Djamel Sadok) Date: Mon, 4 May 2015 14:55:28 -0300 Subject: [e2e] j'accuse NFV In-Reply-To: References: <1430346359454.75464@surrey.ac.uk> Message-ID: To have a FW is difficult (performance wise) and sometimes illegal to have DPI on the subnet to build an IDS. But what happens when everyone bypasses NFVs? Still, it could be necessary to maintain both religions side by side. But how can a user check that its packets have not been NFV?ed by some functions? other than e2e encrypting? Djamel On Mon, May 4, 2015 at 10:29 AM, Khaled Elsayed wrote: > You mean like a hacking packet would say please don't process me via that > nifty NFV firewall or something :-) > > Khaled > > > On Mon, May 4, 2015 at 2:27 PM, Djamel Sadok wrote: > >> Hi, >> >> May be we could also give the end user flow the possibility to say that it >> does not want to have its data packets processed by any NFV or even black >> list some NFVs (types of functions) on the path. Would this be possible to >> achieve? would it render NFV ineffective? can both NFV and Not NFV (bypass >> it) on given flows live together? >> >> Djamel >> >> >> On Thu, Apr 30, 2015 at 10:14 PM, Matt Mathis >> wrote: >> >> > On Wed, Apr 29, 2015 at 3:26 PM, wrote: >> > >> > > Ah, j'accuse TLA. >> > > >> > >> > SDN is not is the same bucket, let me assure you. >> > >> > As for TCP, good algorithms are portable between protocols, bad >> algorithms >> > are dangerous at any scale. Once you fully deconstruct the protocol, I >> > don't care so much about the packet format. >> > >> > Thanks, >> > --MM-- >> > The best way to predict the future is to create it. - Alan Kay >> > >> > Privacy matters! We know from recent events that people are using our >> > services to speak in defiance of unjust governments. We treat privacy >> and >> > security as matters of life and death, because for some users, they are. >> > _______________________________________________ >> > end2end-interest mailing list >> > end2end-interest at postel.org >> > http://mailman.postel.org/mailman/listinfo/end2end-interest >> > Contact list-owner at postel.org for assistance. >> > >> _______________________________________________ >> end2end-interest mailing list >> end2end-interest at postel.org >> http://mailman.postel.org/mailman/listinfo/end2end-interest >> Contact list-owner at postel.org for assistance. >> > > From kelsayed at gmail.com Tue May 5 01:52:49 2015 From: kelsayed at gmail.com (Khaled Elsayed) Date: Tue, 5 May 2015 10:52:49 +0200 Subject: [e2e] j'accuse NFV In-Reply-To: References: <1430346359454.75464@surrey.ac.uk> Message-ID: Why is it important that the user checks that its packet have not been NVF'ed by some functions? Is the problem with NVF or the "functions"? I might be interested if my packets have been NATed or IDSed but whether that was through a real device or a virtual one, what is the difference other than maybe performance? On Mon, May 4, 2015 at 7:55 PM, Djamel Sadok wrote: > > To have a FW is difficult (performance wise) and sometimes illegal to have > DPI on the subnet to build an IDS. > > But what happens when everyone bypasses NFVs? > > Still, it could be necessary to maintain both religions side by side. But > how can a user check that its packets have not been NFV?ed by some > functions? other than e2e encrypting? > > Djamel > > > On Mon, May 4, 2015 at 10:29 AM, Khaled Elsayed > wrote: > >> You mean like a hacking packet would say please don't process me via that >> nifty NFV firewall or something :-) >> >> Khaled >> >> >> On Mon, May 4, 2015 at 2:27 PM, Djamel Sadok wrote: >> >>> Hi, >>> >>> May be we could also give the end user flow the possibility to say that >>> it >>> does not want to have its data packets processed by any NFV or even black >>> list some NFVs (types of functions) on the path. Would this be possible >>> to >>> achieve? would it render NFV ineffective? can both NFV and Not NFV >>> (bypass >>> it) on given flows live together? >>> >>> Djamel >>> >>> >>> On Thu, Apr 30, 2015 at 10:14 PM, Matt Mathis >>> wrote: >>> >>> > On Wed, Apr 29, 2015 at 3:26 PM, wrote: >>> > >>> > > Ah, j'accuse TLA. >>> > > >>> > >>> > SDN is not is the same bucket, let me assure you. >>> > >>> > As for TCP, good algorithms are portable between protocols, bad >>> algorithms >>> > are dangerous at any scale. Once you fully deconstruct the protocol, >>> I >>> > don't care so much about the packet format. >>> > >>> > Thanks, >>> > --MM-- >>> > The best way to predict the future is to create it. - Alan Kay >>> > >>> > Privacy matters! We know from recent events that people are using our >>> > services to speak in defiance of unjust governments. We treat >>> privacy and >>> > security as matters of life and death, because for some users, they >>> are. >>> > _______________________________________________ >>> > end2end-interest mailing list >>> > end2end-interest at postel.org >>> > http://mailman.postel.org/mailman/listinfo/end2end-interest >>> > Contact list-owner at postel.org for assistance. >>> > >>> _______________________________________________ >>> end2end-interest mailing list >>> end2end-interest at postel.org >>> http://mailman.postel.org/mailman/listinfo/end2end-interest >>> Contact list-owner at postel.org for assistance. >>> >> >> > From kelsayed at gmail.com Tue May 5 01:55:32 2015 From: kelsayed at gmail.com (Khaled Elsayed) Date: Tue, 5 May 2015 10:55:32 +0200 Subject: [e2e] j'accuse NFV In-Reply-To: References: <1430346359454.75464@surrey.ac.uk> Message-ID: But if endpoints have such choice to bypass or turn off, would there be any endpoint out there that would choose not to? On Mon, May 4, 2015 at 5:14 PM, David P. Reed wrote: > This argument presumes that firewalls work.... of course they can know > neither the meaning of the packet to the sender nor the meaning to the > receiver. So just as an air filter cannot protect your ears from shocking > utterances, the idea that a packet firewall ought to be entrusted to > protect communicators from mischief is silly... > > Of course the endpoints need to be able to shut down or to bypass such > "helpful" things as firewalls. They are at best kludges. > > On May 4, 2015, Khaled Elsayed wrote: > >> You mean like a hacking packet would say please don't process me via that >> nifty NFV firewall or something :-) >> >> Khaled >> >> >> On Mon, May 4, 2015 at 2:27 PM, Djamel Sadok wrote: >> >> Hi, >>> >>> May be we could also give the end user flow the possibility to say that >>> it >>> does not want to have its data packets processed by any NFV or even black >>> list some NFVs (types of functions) on the path. Would this be possible >>> to >>> achieve? would it render NFV ineffective? can both NFV and Not NFV >>> (bypass >>> it) on given flows live together? >>> >>> Djamel >>> >>> >>> On Thu, Apr 30, 2015 at 10:14 PM, Matt Mathis >>> wrote: >>> >>> On Wed, Apr 29, 2015 at 3:26 PM, wrote: >>>> >>>> Ah, j'accuse TLA. >>>> >>>> >>>> >>>> SDN is not is the same bucket, let me assure you. >>>> >>>> As for TCP, good algorithms are portable between protocols, bad >>>> >>> algorithms >>> >>>> are dangerous at any scale. Once you fully deconstruct the protocol, I >>>> don't care so much about the packet format. >>>> >>>> Thanks, >>>> --MM-- >>>> The best way to predict the future is to create it. - Alan Kay >>>> >>>> Privacy matters! We know from recent events that people are using our >>>> services to speak in defiance of unjust governments. We treat privacy >>>> >>> and >>> >>>> security as matters of life and death, because for some users, they are. >>>> ------------------------------ >>>> >>>> end2end-interest mailing list >>>> end2end-interest at postel.org >>>> http://mailman.postel.org/mailman/listinfo/end2end-interest >>>> Contact list-owner at postel.org for assistance. >>> >>> >>> ------------------------------ >>> >>> end2end-interest mailing list >>> end2end-interest at postel.org >>> http://mailman.postel.org/mailman/listinfo/end2end-interest >>> Contact list-owner at postel.org for assistance. >> >> >> ------------------------------ >> >> end2end-interest mailing list >> end2end-interest at postel.org >> http://mailman.postel.org/mailman/listinfo/end2end-interest >> Contact list-owner at postel.org for assistance. >> > > -- Sent with *K-@ Mail > * > - the evolution of emailing. > From jamel at cin.ufpe.br Tue May 5 03:29:25 2015 From: jamel at cin.ufpe.br (Djamel Sadok) Date: Tue, 5 May 2015 07:29:25 -0300 Subject: [e2e] j'accuse NFV In-Reply-To: <1430774654.590820355@apps.rackspace.com> References: <1430346359454.75464@surrey.ac.uk> <1430774654.590820355@apps.rackspace.com> Message-ID: nothing is wrong with e2e encryption. Perhaps all traffic will be encrypted in a few years anyway. I only want to find out if there could be a way to adopt NFV while leaving a choice for traffic that does not want to be NFV?ed perhaps because of the fear that some middlebox function (NFV) may alter some e2e http2/QUIC/SPDY/.. clever adaptation that booble engineers have just come up with. Djamel On Mon, May 4, 2015 at 6:24 PM, wrote: > What's wrong with e2e encryption as the right answer? I'm missing > something here. > > > > On Monday, May 4, 2015 1:55pm, "Djamel Sadok" said: > > > To have a FW is difficult (performance wise) and sometimes illegal to > have > > DPI on the subnet to build an IDS. > > > > But what happens when everyone bypasses NFVs? > > > > Still, it could be necessary to maintain both religions side by side. But > > how can a user check that its packets have not been NFV?ed by some > > functions? other than e2e encrypting? > > > > Djamel > > > > > > On Mon, May 4, 2015 at 10:29 AM, Khaled Elsayed > wrote: > > > > > You mean like a hacking packet would say please don't process me via > that > > > nifty NFV firewall or something :-) > > > > > > Khaled > > > > > > > > > On Mon, May 4, 2015 at 2:27 PM, Djamel Sadok > wrote: > > > > > >> Hi, > > >> > > >> May be we could also give the end user flow the possibility to say > that > > it > > >> does not want to have its data packets processed by any NFV or even > black > > >> list some NFVs (types of functions) on the path. Would this be > possible > > to > > >> achieve? would it render NFV ineffective? can both NFV and Not NFV > > (bypass > > >> it) on given flows live together? > > >> > > >> Djamel > > >> > > >> > > >> On Thu, Apr 30, 2015 at 10:14 PM, Matt Mathis > > > > >> wrote: > > >> > > >> > On Wed, Apr 29, 2015 at 3:26 PM, wrote: > > >> > > > >> > > Ah, j'accuse TLA. > > >> > > > > >> > > > >> > SDN is not is the same bucket, let me assure you. > > >> > > > >> > As for TCP, good algorithms are portable between protocols, bad > > >> algorithms > > >> > are dangerous at any scale. Once you fully deconstruct the > > protocol, I > > >> > don't care so much about the packet format. > > >> > > > >> > Thanks, > > >> > --MM-- > > >> > The best way to predict the future is to create it. - Alan Kay > > >> > > > >> > Privacy matters! We know from recent events that people are using > > our > > >> > services to speak in defiance of unjust governments. We treat > > privacy > > >> and > > >> > security as matters of life and death, because for some users, they > > are. > > >> > _______________________________________________ > > >> > end2end-interest mailing list > > >> > end2end-interest at postel.org > > >> > http://mailman.postel.org/mailman/listinfo/end2end-interest > > >> > Contact list-owner at postel.org for assistance. > > >> > > > >> _______________________________________________ > > >> end2end-interest mailing list > > >> end2end-interest at postel.org > > >> http://mailman.postel.org/mailman/listinfo/end2end-interest > > >> Contact list-owner at postel.org for assistance. > > >> > > > > > > > > _______________________________________________ > > end2end-interest mailing list > > end2end-interest at postel.org > > http://mailman.postel.org/mailman/listinfo/end2end-interest > > Contact list-owner at postel.org for assistance. > > > From detlef.bosau at web.de Tue May 5 15:43:26 2015 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 06 May 2015 00:43:26 +0200 Subject: [e2e] j'accuse NFV In-Reply-To: References: <1430346359454.75464@surrey.ac.uk> Message-ID: <5549478E.7040005@web.de> Am 04.05.2015 um 14:27 schrieb Djamel Sadok: > Hi, > > May be we could also give the end user flow the possibility to say that it > does not want to have its data packets processed by any NFV or even black > list some NFVs (types of functions) on the path. Would this be possible to > achieve? would it render NFV ineffective? can both NFV and Not NFV (bypass > it) on given flows live together? > > Djamel > I think, we're going to mix up layers here. Let me again refer to the TR "Beyond the Radio: Illuminating the Higher Layers of Mobile Networks". And quote the following: > These middleboxes can poten- > tially modify user traffic, compromise user privacy > by injecting HTTP headers that uniquely identify > users or reveal their location, ???? To my understanding, HTTP traffic uses TCP. (And let me well note, that this is some kind of implementation, we could well put this in question.) To my understanding, TCP privacy is a PURE end to end issue. Nothing else. When there is even the remote possibility that a TCP flow's privacy can be compromised by a middle box, this is either the case in Germany, where the de-mail project suffers exactly from this problem http://en.wikipedia.org/wiki/De-Mail or something is made fundamentally wrong. In his talk "A new way to look on networking" in 2006, Van Jacobson mentioned three requirements for any kind of message switching system, which he thinks to be inevitable. Any message must be 1) idempotent, 2) its integrity must be ensured, 3) its authenticity must be ensured. As long as these three requirements are fulfilled, anything else MUST NOT matter. (And yes, I could add the "J'accuse TCP" piece here which Lloyd requested, because TCP datagrams AREN'T idempotent. The content is - but the protocol handling isn't, think about DUP ACKs.) Detlef From debarshisanyal at gmail.com Tue May 5 23:14:09 2015 From: debarshisanyal at gmail.com (Debarshi Sanyal) Date: Wed, 6 May 2015 11:44:09 +0530 Subject: [e2e] Regarding use of Reed-Solomon code in wireless networks Message-ID: Hi, Hi, We were working on design of wormhole detection methods in MANETs. To achieve detection, we propose to measure the time taken for a test nonce to move from one node to it's neighbor node. If the time taken is larger than the expected time for a packet to travel between two neighbor nodes, the link is probably a wormhole link. Now to combat channel errors, is it worth encoding the nonce with Reed-Solomon code? Our understanding is that propagation time between neighbor nodes in commodity wi-fi setups is much smaller than the time taken to encode and decode a nonce (say, 64 bytes long). So delay variations in encode/decode process will easily mask any delay in propagation time. We would be immensely thankful if you could throw some light on this since we do not have access to hardware platforms to get real measurements. We are interested to know the approximate encode and decode times for RS code on common hardware platforms. Regards, Debarshi Kumar Sanyal KIIT University, Bhubaneswar, India From detlef.bosau at web.de Wed May 6 04:07:54 2015 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 06 May 2015 13:07:54 +0200 Subject: [e2e] Regarding use of Reed-Solomon code in wireless networks In-Reply-To: References: Message-ID: <5549F60A.8030000@web.de> Am 06.05.2015 um 08:14 schrieb Debarshi Sanyal: > Hi, > > Hi, > > We were working on design of wormhole detection methods in MANETs. > To achieve detection, we propose to measure the time taken for a test nonce > to move from one node to it's neighbor node. If the time taken is larger > than the expected time for a packet to travel between two neighbor nodes, > the link is probably a wormhole link. > > Now to combat channel errors, is it worth encoding the nonce with > Reed-Solomon code? ANY (emphasis on ANY) wireless network I know, employs a recovery layer. I should add: I do not know even one single exception. Hence, the time for a packet to "travel" from one node to a neighbour is highly volatile. In general, it isn't even stationary, hence it doesn't even make sense to observe or to measure an "average value" here or some kind of expectation. What RS codes is concerned: RS codes may be - and are - used in computer networks. A closer look to your hardware's documentation will exhibit, if your hardware uses RS codes or other coding schemes. That's a reason for my frequent comments on this issue: In summary, the quite sad truth is: packet latencies in wireless networks are pretty useless for any kind of - load analysis, - congestion analysis, - wormhole detection and the like, as you will run into the well known "cum hoc ergo procter hoc" fallacy almost for sure. > > Our understanding is that propagation time between neighbor nodes in > commodity wi-fi setups is much smaller than the time taken to encode and > decode a nonce (say, 64 bytes long). So delay variations in encode/decode > process will easily mask any delay in propagation time. > > We would be immensely thankful if you could throw some light on this since > we do not have access to hardware platforms to get real measurements. We > are interested to know the approximate encode and decode times for RS code > on common hardware platforms. > > > > > Regards, > Debarshi Kumar Sanyal > KIIT University, Bhubaneswar, India > _______________________________________________ > end2end-interest mailing list > end2end-interest at postel.org > http://mailman.postel.org/mailman/listinfo/end2end-interest > Contact list-owner at postel.org for assistance. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Wed May 6 04:53:08 2015 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 06 May 2015 13:53:08 +0200 Subject: [e2e] j'accuse NFV In-Reply-To: References: <51B1319A-37D1-45F0-B648-126CBBB5BE29@netapp.com> Message-ID: <554A00A4.5030609@web.de> Am 29.04.2015 um 14:46 schrieb Djamel Sadok: > added value is gained by combining / orchestrating both planes. NFV may > open the way to open network hardware and OS and perhaps cheaper one. > Software development is faster/cheaper than a new hardware project. Take Is it really cheaper? In a PM to Jon, I said the whole story reminds me a bit of vmware. When we need 100 WWW servers, we can setup a single machine with vmware, which then emulates 100 virtual ones - and install an own OS and WWW server on each one. Or we can use Apache and configure it for 100 tenants. What is cheaper? What is easier? "Virtualisation" is sometimes nothing else than a denial of cleaning up. And keeping redundant and unnecessary stuff forever and ever. Detlef (Who remembers the KISS principle. Keep It Small and Simple.) From kelsayed at gmail.com Wed May 6 05:17:40 2015 From: kelsayed at gmail.com (Khaled Elsayed) Date: Wed, 6 May 2015 14:17:40 +0200 Subject: [e2e] Regarding use of Reed-Solomon code in wireless networks In-Reply-To: References: Message-ID: Yes, it is usually a good idea to use RS encoding to combat channel problems. The time taken usually is function of the RS code word length and the parity bits. Usually it is very fast compared to other blocks like Viterbi decoder etc if you are talking about lower layers where Viterbi is common. On Wed, May 6, 2015 at 8:14 AM, Debarshi Sanyal wrote: > Hi, > > Hi, > > We were working on design of wormhole detection methods in MANETs. > To achieve detection, we propose to measure the time taken for a test nonce > to move from one node to it's neighbor node. If the time taken is larger > than the expected time for a packet to travel between two neighbor nodes, > the link is probably a wormhole link. > > Now to combat channel errors, is it worth encoding the nonce with > Reed-Solomon code? > > Our understanding is that propagation time between neighbor nodes in > commodity wi-fi setups is much smaller than the time taken to encode and > decode a nonce (say, 64 bytes long). So delay variations in encode/decode > process will easily mask any delay in propagation time. > > We would be immensely thankful if you could throw some light on this since > we do not have access to hardware platforms to get real measurements. We > are interested to know the approximate encode and decode times for RS code > on common hardware platforms. > > > > > Regards, > Debarshi Kumar Sanyal > KIIT University, Bhubaneswar, India > _______________________________________________ > end2end-interest mailing list > end2end-interest at postel.org > http://mailman.postel.org/mailman/listinfo/end2end-interest > Contact list-owner at postel.org for assistance. > From debarshisanyal at gmail.com Wed May 6 06:02:15 2015 From: debarshisanyal at gmail.com (Debarshi Sanyal) Date: Wed, 6 May 2015 18:32:15 +0530 Subject: [e2e] Regarding use of Reed-Solomon code in wireless networks In-Reply-To: References: Message-ID: Hi Detlef, Khaled, Thanks for sharing your views. For the detection mechanism to work, retransmission must be explicitly switched off (as retransmitting same nonce gives advantage to the wormhole attacker). One way to avoid actually measuring the delay is to stipulate that the response nonce from the receiver must come back after a SIFS delay as it happens for any ACK frame in IEEE 802.11. This is possible if minimal processing is involved at the receiver node. If the response doesn't come back after SIFS, the receiver is probably far away and is likely to be connected by a wormhole to this sender. That way, we should be able to flag at least long wormholes. Do you think the above heuristic will work in real networks? Now if the nonces are encoded with RS code, is it still possible for the receiver to decode the nonce, process it, encode it back with RS code and transmit it after a SIFS delay from the time of reception? Thank you in advance for your valuable comments. Regards, Debarshi Kumar Sanyal KIIT University, Bhubaneswar On 6 May 2015 at 17:47, Khaled Elsayed wrote: > Yes, it is usually a good idea to use RS encoding to combat channel > problems. > The time taken usually is function of the RS code word length and the > parity bits. > Usually it is very fast compared to other blocks like Viterbi decoder etc > if you are talking about lower layers where Viterbi is common. > > On Wed, May 6, 2015 at 8:14 AM, Debarshi Sanyal > wrote: > >> Hi, >> >> Hi, >> >> We were working on design of wormhole detection methods in MANETs. >> To achieve detection, we propose to measure the time taken for a test >> nonce >> to move from one node to it's neighbor node. If the time taken is larger >> than the expected time for a packet to travel between two neighbor nodes, >> the link is probably a wormhole link. >> >> Now to combat channel errors, is it worth encoding the nonce with >> Reed-Solomon code? >> >> Our understanding is that propagation time between neighbor nodes in >> commodity wi-fi setups is much smaller than the time taken to encode and >> decode a nonce (say, 64 bytes long). So delay variations in encode/decode >> process will easily mask any delay in propagation time. >> >> We would be immensely thankful if you could throw some light on this since >> we do not have access to hardware platforms to get real measurements. We >> are interested to know the approximate encode and decode times for RS code >> on common hardware platforms. >> >> >> >> >> Regards, >> Debarshi Kumar Sanyal >> KIIT University, Bhubaneswar, India >> _______________________________________________ >> end2end-interest mailing list >> end2end-interest at postel.org >> http://mailman.postel.org/mailman/listinfo/end2end-interest >> Contact list-owner at postel.org for assistance. >> > > From kelsayed at gmail.com Wed May 6 06:46:28 2015 From: kelsayed at gmail.com (Khaled Elsayed) Date: Wed, 6 May 2015 15:46:28 +0200 Subject: [e2e] Regarding use of Reed-Solomon code in wireless networks In-Reply-To: References: Message-ID: If it is performed using dedicated hardware, e.g. an FPGA, then of course it can be done. On Wed, May 6, 2015 at 3:02 PM, Debarshi Sanyal wrote: > Hi Detlef, Khaled, > > Thanks for sharing your views. > > For the detection mechanism to work, retransmission must be explicitly > switched off (as retransmitting same nonce gives advantage to the wormhole > attacker). > > One way to avoid actually measuring the delay is to stipulate that the > response nonce from the receiver must come back after a SIFS delay as it > happens for any ACK frame in IEEE 802.11. This is possible if minimal > processing is involved at the receiver node. > > If the response doesn't come back after SIFS, the receiver is probably far > away and is likely to be connected by a wormhole to this sender. That way, > we should be able to flag at least long wormholes. > > Do you think the above heuristic will work in real networks? > > Now if the nonces are encoded with RS code, is it still possible for the > receiver to decode the nonce, process it, encode it back with RS code and > transmit it after a SIFS delay from the time of reception? > > Thank you in advance for your valuable comments. > > > > > Regards, > Debarshi Kumar Sanyal > KIIT University, Bhubaneswar > > > > On 6 May 2015 at 17:47, Khaled Elsayed wrote: > >> Yes, it is usually a good idea to use RS encoding to combat channel >> problems. >> The time taken usually is function of the RS code word length and the >> parity bits. >> Usually it is very fast compared to other blocks like Viterbi decoder etc >> if you are talking about lower layers where Viterbi is common. >> >> On Wed, May 6, 2015 at 8:14 AM, Debarshi Sanyal > > wrote: >> >>> Hi, >>> >>> Hi, >>> >>> We were working on design of wormhole detection methods in MANETs. >>> To achieve detection, we propose to measure the time taken for a test >>> nonce >>> to move from one node to it's neighbor node. If the time taken is larger >>> than the expected time for a packet to travel between two neighbor nodes, >>> the link is probably a wormhole link. >>> >>> Now to combat channel errors, is it worth encoding the nonce with >>> Reed-Solomon code? >>> >>> Our understanding is that propagation time between neighbor nodes in >>> commodity wi-fi setups is much smaller than the time taken to encode and >>> decode a nonce (say, 64 bytes long). So delay variations in encode/decode >>> process will easily mask any delay in propagation time. >>> >>> We would be immensely thankful if you could throw some light on this >>> since >>> we do not have access to hardware platforms to get real measurements. We >>> are interested to know the approximate encode and decode times for RS >>> code >>> on common hardware platforms. >>> >>> >>> >>> >>> Regards, >>> Debarshi Kumar Sanyal >>> KIIT University, Bhubaneswar, India >>> _______________________________________________ >>> end2end-interest mailing list >>> end2end-interest at postel.org >>> http://mailman.postel.org/mailman/listinfo/end2end-interest >>> Contact list-owner at postel.org for assistance. >>> >> >> > From detlef.bosau at web.de Wed May 6 07:44:07 2015 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 06 May 2015 16:44:07 +0200 Subject: [e2e] Regarding use of Reed-Solomon code in wireless networks In-Reply-To: References: Message-ID: <554A28B7.80803@web.de> Am 06.05.2015 um 15:02 schrieb Debarshi Sanyal: > Hi Detlef, Khaled, > > Thanks for sharing your views. > > For the detection mechanism to work, retransmission must be explicitly > switched off (as retransmitting same nonce gives advantage to the wormhole > attacker). Even then the problem is to discern a wormhole from noise. Years ago, the community discussed the "loss differentiation problem" which focussed on the question whether a lost packet was due to congestion or due to corruption. In WiFi networks, the question is whether a lost packet is due to collision or due to corruption. Disabling retransmission in WiFi networks means disabling the MAC scheme. (NB: There is no such thing as collision DETECTION in WiFi.) From debarshisanyal at gmail.com Wed May 6 09:04:15 2015 From: debarshisanyal at gmail.com (Debarshi Sanyal) Date: Wed, 6 May 2015 21:34:15 +0530 Subject: [e2e] Regarding use of Reed-Solomon code in wireless networks In-Reply-To: <554A28B7.80803@web.de> References: <554A28B7.80803@web.de> Message-ID: On 6 May 2015 at 20:14, Detlef Bosau wrote: > Am 06.05.2015 um 15:02 schrieb Debarshi Sanyal: > > Hi Detlef, Khaled, > > > > Thanks for sharing your views. > > > > For the detection mechanism to work, retransmission must be explicitly > > switched off (as retransmitting same nonce gives advantage to the > wormhole > > attacker). > > Even then the problem is to discern a wormhole from noise. Years ago, > the community discussed the "loss differentiation problem" which > focussed on the question whether a lost packet was due to congestion or > due to corruption. In WiFi networks, the question is whether a lost > packet is due to collision or due to corruption. Disabling > retransmission in WiFi networks means disabling the MAC scheme. (NB: > There is no such thing as collision DETECTION in WiFi.) > I understand there is a fundamental problem here: corruption or collision. Independent of the cause, the receiver will attempt to repair the packet. If it fails, the sender must transmit a fresh nonce. The unfortunate downside is that if packets are lost due to collisions and the backoff mechanism of MAC is switched off, collisions will only increase. The wormhole is assumed to be passive: it will not corrupt the packet; it will only tunnel it over a longer distance. This assumption effectively means only noise can corrupt the packet. Active wormholes are definitely more difficult to detect. > _______________________________________________ > end2end-interest mailing list > end2end-interest at postel.org > http://mailman.postel.org/mailman/listinfo/end2end-interest > Contact list-owner at postel.org for assistance. > From detlef.bosau at web.de Wed May 6 12:15:29 2015 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 06 May 2015 21:15:29 +0200 Subject: [e2e] Regarding use of Reed-Solomon code in wireless networks In-Reply-To: References: <554A28B7.80803@web.de> Message-ID: <554A6851.2020609@web.de> Am 06.05.2015 um 18:04 schrieb Debarshi Sanyal: > > I understand there is a fundamental problem here: corruption or > collision. Independent of the cause, the receiver will attempt to > repair the packet. If it fails, the sender must transmit a fresh nonce. Exactly. And different from, e.g., Ethernet, you must mot switch off the mechanism, otherwise your packet may never reach the medium - and the receiver. > The unfortunate downside is that if packets are lost due to collisions > and the backoff mechanism of MAC is switched off, collisions will only > increase. Yes. Does WiFi have a backoff mechanism? I simply don't have it in mind. It would be most reasonable to desynchronise competing senders. (If you happen to know the details, please let me know. ) > > The wormhole is assumed to be passive: it will not corrupt the packet; > it will only tunnel it over a longer distance. I see. And your idea is, to observe the time a packet travels and to assess, whether this unduly long. > This assumption effectively means only noise can corrupt the packet. My objection is, that a normal packet, which is not redirected over a wormhole link may see large transport times as well, when. e.g., there is high load on a net or severe noise. So the problem is to find a significant limit to discriminate "noise delay" or "collision delay" from "wormhole delay". -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Wed May 6 15:05:57 2015 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 07 May 2015 00:05:57 +0200 Subject: [e2e] j'accuse NFV In-Reply-To: References: <1430346359454.75464@surrey.ac.uk> <1430774654.590820355@apps.rackspace.com> Message-ID: <554A9045.2060100@web.de> Am 05.05.2015 um 12:29 schrieb Djamel Sadok: > nothing is wrong with e2e encryption. Perhaps all traffic will be encrypted > in a few years anyway. > > I only want to find out if there could be a way to adopt NFV while leaving > a choice for traffic that does not want to be NFV?ed perhaps because of the > fear that some middlebox function (NFV) may alter some e2e > http2/QUIC/SPDY/.. clever adaptation that booble engineers have just come > up with. > > Djamel > There is a quite helpful paper, which you may want to reed: http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf Unfortunately, we often talk about some "end to end principle", which doesn't exist and which the mentioned paper did not want to establish. To me, it is a framework, some very thought out advice how rationales can be found to answer the questions - where network functions should be placed and - why. So if we have, e.g., some kind of transport protocol, which provides for an ordered, reliable byte stream, the virtual channel between the end poins IS strictly virtual. A packet, once it is sent to the channel by the senmder "disappears" in the channel and "appears again" not before the receiver. So, to my understanding, and I'm a bit nasty here because this way of thinking is not necessarily shared by all readers here, a very basic problem of middle boxes is - where to place them and - how to alter a flow in some determined manner! This is like placing a door on a soccer field: When a ball is shot, he left the player's foot and it is in the game gain, when it is received by another player. In a packet switching network, anything what happens between entering and leaving the path should be completely transparent. So the question is once again: Where should we place middleboxes? During the last weeks, I've seen some discussion about Baran's work on the history list. So let me say, why I think my thought is nasty: Think about TCP and path changes. Some people even think about a "multipath TCP". When I consider Baran's work, Baran had a strong emphasis on path redundancy. So, with respect to a certain packet, we agree upon a sender and a receiver. But do we agree upon anything more? The more I think about it, the more I tend to give the answer: No, we don't. And the very strength of the e2e way of thinking is THAT WE DON'T. E.g., when a packet misses its receiver because some node or link along the path fails, the sender may retransmit a packet - and the packet may take a different route from the sender to the receiver. So, where shall middle boxes be placed? That doesn't mean, they were no rules for packet forwarding, of course they are. But it does mean, that a "path" between sender and receiver may be not completely visible from "within" the network but something, which may be visible from "outside" the network. >From a view "within a network", there even might be no awareness, that a certain path even exists. >From a view "outside the network", the path exists and may work pretty fine. It is difficult to think that way. But the more I think about it, the more I think, I'm in my own way, when I think about networks. And particularly with respect to Baran's work and the basic idea of robustness by path redundancy, I try to leave the idea of "concrete paths" - and hence focussing on middle boxes or concrete functions placed on certain places along a path. Perhaps, I want to define some requirements for packet forwarding from the outside. (A classical example is a packet's TTL) But mainly, from an outside perspective, I'm interested that a network DOES the forwarding job. And not in HOW it is done. E.g., I see some author's who want to drop greedy routing. Why? A possible (and very convincing!) argument is: For the purpose of load sharing! And latest in this context, talking about middle boxes and the like doesn't really make sense. From ingemar.s.johansson at ericsson.com Tue May 26 04:38:08 2015 From: ingemar.s.johansson at ericsson.com (Ingemar Johansson S) Date: Tue, 26 May 2015 11:38:08 +0000 Subject: [e2e] TCP HyStart patch deployment Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA32145DE4@ESESSMB205.ericsson.se> Hi Does anybody know if the TCP Cubic HyStart patch described in the link below is being used widely ? It does not seem to be implemented in the latest Linux code. http://patchwork.ozlabs.org/patch/85945/ Regards Ingemar ================================= Ingemar Johansson M.Sc. Senior Researcher Ericsson AB Wireless Access Networks Labratoriegr?nd 11 971 28, Lule?, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson at ericsson.com www.ericsson.com "No man has a good enough memory to be a successful liar" Abraham Lincoln =================================