I would like to see working path MTU of some form for many different
reasons.
I would also like to see larger practical MTUs.
However, history suggests that both goals may be more aspirational than
practical.
I tend to be very skeptical of any anlysis that says that user traffic
is changing to X, and that because X has property Y, we should plan our
networks for property Y. I am not at all sure I have ever seen this
proven correct.
All I was saying is that thinking about overhead in terms of a single
average packet size is mathematically correct but practically misleading.
Yours,
Joel
On 3/28/19 5:18 PM, john leddy.net wrote:
Joel,
It would be good to factor in the ever growing amount of video on the
Internet (and other large data transfer applications vs voice traffic).
If larger MTU's could reliably be used, I think you would see a large
amount of traffic starting to use something larger than 1500 byte Cells.
Getting to a reliable PMTU mechanism would be a great way to drive
efficiency.
Use of larger packets should generate less TCP Ack traffic as well in
general.
I'm assuming the voice concern was around efficiency not about whether a
voice application would work with the increased overhead of an extension
header?
John
On March 28, 2019 at 11:51 AM Robert Raszuk <[email protected]> wrote:
Hi Joel,
Is your hidden message to express that neither TCP nor UDP with voice
app should use IPv6 at all as overhead is just too big even without
additional extension headers ?
Best,
R.
On Thu, Mar 28, 2019, 16:44 Joel M. Halpern < [email protected]
<mailto:[email protected]>> wrote:
One needs to be very careful about packet size reasoning.
For TCP, something like 1/3 of all packets are tiny (acks). A lot
less
than 1/3 of the bytes are in tiny packets :-)
For voice traffic, almost all packets are small.
Yours,
Joel
On 3/28/19 4:36 PM, Rajiv Asati (rajiva) wrote:
> Hi Ron,
>
> Very Interesting idea that you presented during SPRING session
today. Seems useful.
>
> Two comments/clarification -
>
> 1. One of the slides indicated that small packet size on the
Internet was ~500B and calculated ~10% due to Routing EH overhead
accordingly. Of course, if we look at mid packet size (800-1000B)
or large packet size (1000~1400B), then the overhead would be a
lot less.
>
> We should also look at the % mix of small packets vs mid vs
large size to calculate the impact. If mid to large packets were
dominant (say, as much as >70% given >80% of traffic is video (ABR
etc) per the latest VNI studies ), then the overhead impact due to
non-compressed SID usage on the traffic would be even less over all.
>
> 2. Also, what % of savings do we get by using compressed RH vs
non-compressed RH ? 24B vs 64B per packet !!
>
>
> Cheers,
> Rajiv
>
> _______________________________________________
> spring mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/spring
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected] <mailto:[email protected]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
