Jose, There's some 'but this is the way we've always done it' here that needs to be cleaned up.
The 1500 byte MTU in ethernet was arrived at when buffer space was an issue. It's rather arbitrary. 10M clock rate rather than 1 or 10G like we have today. And the physical carrier of the day was RG5 coaxial cable (aka 10Base5). Packets shorter than 1500 are attributable to three things: - end-of-file packets where the content byte-count is less than 1500 - one-datagram messages of less than 1500 bytes - overhead messages such as Syns and Fins and their Acks. The character of the data probably changes as you get to mobile platforms -- expect an increase in short packets (a typical track report contains identity, timestamp and position -- things you can say in far less than 1500 bytes). Secondly, you got the notion right vis ethernet. Layer 2 frames tend to equal layer 3 datagrams. Which means that you need to fight every frame onto the air. The impact of congestion is significant. But a better perspective to start your thinking from is IEEE 802.16, (industry label WiMax) rather than 802.3 (or .11). In .16 the standard carefully is agnostic about what the content frames are (in reality they're ethernet, nobody is using ATM cells which was the issue at time of writing). And these subframes are aggregated into frames where several (all that a station is allowed to transmit in that time window) are shoved out the port head-to-tail. The jitter associated with the MAC (and contention access) is removed. To my knowledge 802.16 has no arbitrary max frame size -- dependent on number of stations and amount of traffic they have. In such a case, header compressions that save bytes will have a clear win (although I think we need a few other things higher on the priority list). On Thu, 2016-07-07 at 10:22 +0200, Jose Saldana wrote: > 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
