> On 5 Feb 2021, at 12:06, Jiayihao <[email protected]> wrote: > > - As mentioned in "http://acticom.de/internet-of-things-iot/ > <http://acticom.de/internet-of-things-iot/>", a typical payload size equals > just around 25 bytes per IPv6 datagram. Thus typically the saving rate will > be ((14+10+25)-(14+40+25))/(14+40+25)=38%. So typically, a 38% saving may be > a good motivation for having a short address. However, we'd like to postpone > quantitative analysis after we have a rough consensus on problems due to > addressing aspects.
Sorry, but I think you have to discuss the quantitive aspects of the problem as part of understanding whether this is worth doing or not. You have to ask if a 38% saving is worth the huge CAPEX and OPEX costs and feed that into the discussion. If we are going to argue for short packets that is another matter, and that would not simply be an addressing discussion. For example in a lot of applications the traffic is between a device and a gateway. If we allowed an out of band session setup we could support something like 500K sessions in the network with just a 4 byte network header. So classic Ether + Classic IPv6 + 25 = 79B Reduced address in IPv6 = 49B (0.62 of size) 4B n/w layer = 43B (0.54 of size) So about 50% is the best we can achieve. Of course many of you will realise that there exists a 4B session oriented packet format and is one that almost every router already supports. I think that this means that we need to have the conversation about small addresses within a much bigger context in terms of style of network communication and intended outcome and the scenarios document does not really do that analysis, but if the goal is simply minimum address size we do have an approach that we could in principle deploy today between a device and a gateway, and we should explore that. If the requirements is a connectionless service then we really have to understand how to balance the economic cost of deploying a new packet design against a 38% saving of packet size. Best regards Stewart
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
