Subject: Re: [v6ops] draft-xie-v6ops-network-happyeyeballs

From: Davey Song <[email-masked]>
Date: Mon, 3 Dec 2018 15:46:43 +0800

I checked related work in IPPM WG and quote RFC 2681 for round-trip delay
metric.  I'm looking forward to more input from IPPM to fit NHE usecase.

btw, thanks for your mail to IPPM.

Davey

On Fri, 30 Nov 2018 at 07:01, Tommy Pauly <[email-masked]> wrote:

> Even with non-customer traffic, is syslog really the state of the art for
> sending data back to servers? Do you want anyone and everyone to see this
> information?
>
> Regarding the active measurements themselves, I think the draft would
> benefit from referencing some of the RFCs and drafts from the IPPM Working
> Group. We have various documents on one-way and two-way active measurements
> (OWAMP/TWAMP). You can also take a look at some standard ways of reporting
> the metrics themselves, as described here:
> draft-ietf-ippm-initial-registry-08.
>
> Thanks,
> Tommy
>
> > On Nov 27, 2018, at 5:22 AM, JORDI PALET MARTINEZ <jordi.palet=
> [email-masked]> wrote:
> >
> > Hi Mikael,
> >
> > I got the impression that when I originally proposed this, syslog was a
> privacy issue because it is sending data from "customers traffic" from
> their own devices to the ISP.
> >
> > But in the actual proposal, the data is NOT from any customer, neither
> identifying the customer at all.
> >
> > So not sure to understand if we have failed to clearly describe the way
> we are measuring, or you'd in mind the previous document?
> >
> > Regards,
> > Jordi
> >
> >
> >
> > -----Mensaje original-----
> > De: v6ops <[email-masked]> en nombre de Mikael Abrahamsson <
> [email-masked]>
> > Organización: People's Front Against WWW
> > Fecha: martes, 27 de noviembre de 2018, 12:45
> > Para: Ron Bonica <[email-masked]>
> > CC: "[email-masked] list" <[email-masked]>
> > Asunto: Re: [v6ops] draft-xie-v6ops-network-happyeyeballs
> >
> >    On Mon, 26 Nov 2018, Ron Bonica wrote:
> >
> >> This week, please review and comment on
> >> draft-xie-v6ops-network-happyeyeballs.
> >
> >    I think it's a great idea to tell the operator about problems, that
> kind
> >    of telemetry can really help in operating the network.
> >
> >    However, the proposed method of doing it (syslog) and the information
> it
> >    reports (IP addresses and domains the user is communicating with) has
> huge
> >    privacy implications. Also you have no idea who might be grabbing
> this
> >    information before it even makes it to the ISP).
> >
> >    I think at a minimum there needs to be an encrypted and verified
> mechanism
> >    (https perhaps?) for doing the reporting, so you know where the
> report
> >    goes.
> >
> >    I see three entities that have interest in this information, it's the
> ISP,
> >    the operating system manufacturer, and the web site which is having
> >    problems. If HE fails, I see very little harm (privacy) in telling
> the
> >    website about it using the address family that actually did work. So
> that
> >    could be included. For the device manufacturer, they have "send
> >    diagnostics information to vendor", so here customers can opt in. For
> the
> >    ISP, I have no idea. Here it might be better to define an API between
> the
> >    device vendor and the ISP, so that the device vendor can report
> problems
> >    seen, at an aggregate? I have personally been involved in getting
> >    operational people from my employer talking to device vendors to
> figure
> >    out what might be wrong, and automating this would be great.
> >
> >    Also, the DNSSEC implications are glossed over grossly. We should
> take for
> >    granted that end devices are running validating resolvers and handle
> that
> >    use-case.
> >
> >    So I'm supportive of the problem statement and it would help ISPs
> greatly
> >    if they could get telemetry from end devices, I just have great
> concerns
> >    over the method proposed in this draft.
> >
> >    --
> >    Mikael Abrahamsson    email: [email-masked]
> >
> >    _______________________________________________
> >    v6ops mailing list
> >    [email-masked]
> >    https://www.ietf.org/mailman/listinfo/v6ops
> >
> >
> >
> >
> > **********************************************
> > IPv4 is over
> > Are you ready for the new Internet ?
> > http://www.theipv6company.com
> > The IPv6 Company
> >
> > This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
> >
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Davey Song <[email-masked]>
Date: Mon, 3 Dec 2018 16:02:29 +0800

Yes, the running code and data-based analysis is important. As we met in
IETF103, the authors plan to setup a open source repo in Github doing the
following steps :

#1 To develop a methord (packets capturing and analysis) to measure and
collect the data on the delay of IPv4-fallback issue in dualstack network.
We would like to invite network operators to test in their network. This
step is helpful for us to understand how severe the problem is. It may vary
for different ISPs.

#2 if #1 proves it a valid problem to solve, then we are going to develop a
active monitoring tool based on NHE draft. We would like to ask volunteers
to try and implement in some ISPs network to study the impact and gains.

#3 We will see later the result of #1 and #2, and decide how to proceed any
document in IETF.

For each step, peer review and comments from IETF are helpful.

Best regards,
Davey

On Sat, 1 Dec 2018 at 00:55, Lencse Gábor <[email-masked]> wrote:

>
>
> 11/29/2018 11:53 PM keltezéssel, Tommy Pauly írta:
> >
> >> On Nov 27, 2018, at 7:52 AM, JORDI PALET MARTINEZ <jordi.palet=
> >> In the previous related work, I was told otherwise: let's the ISPs do
> it, not the O/S vendors ...
> > I think the point being made here is that open source software can be
> created and distributed to ISPs to run in their networks; it doesn't
> necessarily require any standard or draft to do it.
>
> I think you are completely right that the software can be written
> without an I-D, however, I think that its specification would benefit
> from a matured draft.
>
> Gábor
>
> > Thanks,
> > Tommy
> >> Regards,
> >> Jordi
> >>
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 03 Dec 2018 10:13:02 +0100

The reason for using syslog is because it is widely deployed by ISPs.

Not all the ISPs have other ways of collecting data.

So, it is a matter of simplicity towards deploying it, not looking for the "state of the art" measurement system.

What we can do is to provide instead of just syslog, support for IPPM systems and let the ISPs to choose what they have in their own network.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Tommy Pauly <[email-masked]>
Fecha: viernes, 30 de noviembre de 2018, 0:01
Para: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
CC: "[email-masked] list" <[email-masked]>
Asunto: Re: [v6ops] draft-xie-v6ops-network-happyeyeballs

    Even with non-customer traffic, is syslog really the state of the art for sending data back to servers? Do you want anyone and everyone to see this information?
    
    Regarding the active measurements themselves, I think the draft would benefit from referencing some of the RFCs and drafts from the IPPM Working Group. We have various documents on one-way and two-way active measurements (OWAMP/TWAMP). You can also take a look at some standard ways of reporting the metrics themselves, as described here: draft-ietf-ippm-initial-registry-08.
    
    Thanks,
    Tommy
    
    > On Nov 27, 2018, at 5:22 AM, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
    > 
    > Hi Mikael,
    > 
    > I got the impression that when I originally proposed this, syslog was a privacy issue because it is sending data from "customers traffic" from their own devices to the ISP.
    > 
    > But in the actual proposal, the data is NOT from any customer, neither identifying the customer at all.
    > 
    > So not sure to understand if we have failed to clearly describe the way we are measuring, or you'd in mind the previous document?
    > 
    > Regards,
    > Jordi
    > 
    > 
    > 
    > De: v6ops <[email-masked]> en nombre de Mikael Abrahamsson <[email-masked]>
    >    I think it's a great idea to tell the operator about problems, that kind 
    >    However, the proposed method of doing it (syslog) and the information it 
    >    reports (IP addresses and domains the user is communicating with) has huge 
    >    privacy implications. Also you have no idea who might be grabbing this 
    >    I think at a minimum there needs to be an encrypted and verified mechanism 
    >    (https perhaps?) for doing the reporting, so you know where the report 
    >    goes.
    > 
    >    I see three entities that have interest in this information, it's the ISP, 
    >    problems. If HE fails, I see very little harm (privacy) in telling the 
    >    website about it using the address family that actually did work. So that 
    >    diagnostics information to vendor", so here customers can opt in. For the 
    >    ISP, I have no idea. Here it might be better to define an API between the 
    >    device vendor and the ISP, so that the device vendor can report problems 
    >    operational people from my employer talking to device vendors to figure 
    >    Also, the DNSSEC implications are glossed over grossly. We should take for 
    >    granted that end devices are running validating resolvers and handle that 
    >    use-case.
    > 
    >    So I'm supportive of the problem statement and it would help ISPs greatly 
    >    if they could get telemetry from end devices, I just have great concerns 
    > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
    > 
    > 
    > 

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.