Re: [v6ops] draft-vyncke-v6ops-james discussion

["[e-mail]" <[e-mail]>]

Justin,
> Considering what we observed, i.e., all DOs going through with size < 32 bytes, and most of the DOs going through with 32 bytes <= size < 64> bytes, I'd say what you see is expected and not different from other results.
Great!  We are eager to start using PDMv2 (encrypted, of course!) across the internet to get the great performance data that is needed.  
Just FYI, in some of our other testing that is still preliminary, we did see that PDM (the smaller 28 bytes DO) was not getting through to some of the very large sites on the Alexa list.   Our working hypothesis is that this is due to potential blocking at the destination site.  We are working with a CDN provider as we speak to test from their internal network to our servers which will return PDM to them.
For people who may not be as familiar with our work as Justin is, here is a link to the PDMv2 draft which has been adopted by the IPPM WG.
https://datatracker.ietf.org/doc/draft-elkins-ippm-encrypted-pdmv2/

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
[phone] 

    On Tuesday, August 16, 2022 at 06:25:39 AM PDT, Justin Iurman <[e-mail]> wrote:  
 
 Hi Nalini,

On 8/16/22 13:31, [e-mail] wrote:
> Fernando,
> 
>> IIRC, Nalini's measurements seem to disagree with this. -- buy my take
>> is that they have been performed across a limited set of endpoints for
>> them to be statistically significant.
> 
> Our testing point for FTPs were to:
> 
> 1. PDM-Warsaw
> 2. PDM-Toronto
> 3. PDM-Seattle
> 4. PDM-Mumbai
> 5. PDM-Melbourne
> 6. PDM-Frankfurt
> 
> So 6 cities and 4 continents.
> 
> Europe
> North America
> Asia
> Australia
> 
> Our testing showed Destination Options and Fragment Headers in real 
> application data traffic successfully crossing the core of the Internet.
> 
> In testing from the IETF Hackathon to one of our servers, we showed DoH 
> and Fragment Headers successfully crossing the IETF network.  Others 
> have shown success from South Africa to Warsaw.
> 
> We are working with others to expand our data collection points as well 
> as investigating exactly WHY and WHERE EH's may be blocked.
> 
> I do indeed think this has to do with methodology.    I think everyone 
> is getting correct results based on what they tested.  But, IMHO, the 
> more interesting question is exactly WHY our results are different.

As discussed in Philly, I still think that you see all DOs going through 
due to the size of PMDv2. Following your draft, you only need a 24-byte 
Extension Header for the unencrypted option, while you need a 40-byte 
Extension Header for the encrypted one.

Unencrypted PDMv2 (24 bytes):

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next header  | Header length |            Padding            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Option Type  | Option Length | Vrsn  |    Reserved Bits    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Random Number          |f|  ScaleDTLR  |  ScaleDTLS  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Global Pointer                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      PSN This Packet          |    PSN Last Received          |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Delta Time Last Received    |    Delta Time Last Sent      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Encrypted PDMv2 (40 bytes):

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next header  | Header length |            Padding            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Option Type  | Option Length | Vrsn  |    Reserved Bits    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Random Number          |f|                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                              :
|                      Encrypted PDM Data                      :
:                          (30 bytes)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Considering what we observed, i.e., all DOs going through with size < 32 
bytes, and most of the DOs going through with 32 bytes <= size < 64 
bytes, I'd say what you see is expected and not different from other 
results.

Justin

> Thanks,
> 
> Nalini Elkins
> CEO and Founder
> Inside Products, Inc.
> www.insidethestack.com
> [phone]
> 
> 
> On Monday, August 15, 2022 at 10:58:27 PM PDT, Fernando Gont 
> <[e-mail]> wrote:
> 
> 
> Hi, Geoff,
> 
> On 16/8/22 00:59, Geoff Huston wrote:
>  >>
>  >> The authors are experimenting with the impact of various kinds of
>  >> extension headers on IPv6 carriage across the dual stack Internet.
>  >> I'm interested in people's views of the experiment and how it might
>  >> best proceed.
>  >
>  > It’s somewhat interesting that there are number of different
>  > measurement approaches that have been discussed recently, with quite
>  > radically different measured outcomes. Maybe we should spend some
>  > time to try and understand why there are such different outcomes from
>  > these measurements.
> 
> My recollection might be failing but... don't most of our measurements
> actually agree?  (i.e., drop rate is too high, and it gets worse as the
> length of the ipv6 header chain increases).
> 
> IIRC, Nalini's measurements seem to disagree with this. -- buy my take
> is that they have been performed across a limited set of endpoints for
> them to be statistically significant.
> 
> Thoughts?
> 
> Thanks,
> -- 
> Fernando Gont
> e-mail: [e-mail] <mailto:[e-mail]>
> PGP Fingerprint: 7F7F 686D 8AC9 3319 EEAD C1C8 D1D5 4B94 E301 6F01
> 
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail] <mailto:[e-mail]>
> PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/v6ops 
> <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops