My two cents: We should share an idea of what "big" or "small" means when talking about packets.
In Ethernet the MTU is 1500 bytes, so packets circulating by the wired Internet are between 40 and 1500 bytes. See the histogram of a real trace here: http://es.slideshare.net/josemariasaldana/simplemux-traffic-optimization/2 So when I talk about a "small packet", I am thinking about 40-100 bytes. When I talk about "big packet" I am thinking about 1500 bytes. I assume that sending a 1500-byte packet is reasonably efficient in a network, be it wired or wireless. - But sending thousands of 40-byte packets is not efficient in a wired network. This is why in wired networks, Jumbo frames, up to 9198 bytes, can be used. - And sending 40-byte packets is not efficient at all in a wireless network, due to the overhead, and also to the contention mechanisms required before the actual sending of the data. This is why 802.11 includes aggregation mechanisms capable of sending a number of subframes into a single one. A-MPDU is able to send a number of subframes, each one with its own FEC, so they can be retransmitted individually (in order to avoid the trade-off highlighted by Rex: "The larger the packet, the larger the retransmission when it fails the CRC check.") So in my case, multiplexing small packets would mean to aggregate 15 or 20 small packets into a 1500-byte one. Of course, you can also aggregate in order to build bigger frames. So we can use: - small: 40-100 bytes - big: 1500 bytes - super-frame: about 9000 or more BR, Jose > -----Mensaje original----- > De: Rex Buddenberg [mailto:[email protected]] > Enviado el: jueves, 07 de julio de 2016 2:20 > Para: Dino Farinacci <[email protected]>; AshwoodsmithPeter > <[email protected]> > CC: [email protected]; José Ruiz Mas <[email protected]>; Anton Smirnov > <[email protected]>; LISP mailing list list <[email protected]>; Jose Saldana > <[email protected]> > Asunto: Re: [5gangip] [lisp] Bandwidth savings with LISP > > There's another variable. Noise, manifested in bit errors, is about three > orders of > magnitude greater in RF than in wireline. The larger the packet, the larger > the > retransmission when it fails the CRC check. > If you must, there are yet more variables such as the amount of FEC. > The more FEC, the fewer bit errors, but the FEC comes at a cost in capacity. > > Multivariable optimization problem. And some of the variables change from > moment to moment. > > On Wed, 2016-07-06 at 15:20 -0700, Dino Farinacci wrote: > > > > > > Hey Dino, > > > > > > > > > > > > > > > > > On the header size issue, one of the complaints I've made about > > > > > ICN/CCN etc. and 5G is the increased header sizes and the impact > > > > > that this has on the most expensive resource (by a wide margin), > > > > > the RF spectrum. > > > > > > > > So you are saying large packets would have the same disadvanage. > > > > Therefore, small headers on small payloads is the most optimal > > > > design space? > > > Not sure how that follows ;) I'm saying either compress or provide > > > an advantage to the RF link too, or both, but doing neither would be > > > a hard sell. Larger packet sizes of course reduce the relative > > > header tax so bigger is actually better I suppose. > > More headers mean larger packets. Less headers with multiple packets > > in a super-packet means larger packets. So the negative effect is the > > same. > > > > Dino > > > > _______________________________________________ > > 5gangip mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/5gangip _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
