Re: [spring] Monitoring metric to detect and locate congestion

Hi Haoyu,

> which applies Eulerian Path algorithm to find the minimum set of paths
with network-wide coverage.

In practice networks use ECMP. ECMP decision may happen at each hop. Your
end to end flows get spread over all ECMP paths. So limiting number of
probed paths is inaccurate to the fundamental objective of the exercise.

That is infact main challenge with any end to end path probing today ... if
you do not cover all possible paths your packets may take between ingress
and egress you just do not get full picture of the network.

Thx a lot,
R.

On Thu, Feb 27, 2020 at 8:44 PM Haoyu Song <haoyu.song@futurewei.com> wrote:

> Hi Ruediger,
>
>
>
> I like the general idea that using pre-determined paths in SR to collect
> performance metrics. I think this approach provides some unique benefits
> compared with the other approaches. It is also coincident with some of
> related research work I’m doing.
>
> Here are some thoughts I have.
>
>    1. I think IOAM could be used as the standard approach for such
>    probing packets. It can collect the performance metrics mentioned in the
>    draft and does more.
>    2. An interesting problem raised by the draft but not fully addressed
>    is the method to plan the optimal paths. There is a work called INT-PATH (
>    https://ieeexplore.ieee.org/document/8737529) which applies Eulerian
>    Path algorithm to find the minimum set of paths with network-wide coverage.
>    However, the problem here seems different: you need path coverage
>    redundancy. My question is: do we really need the redundancy to achieve the
>    measurement goal? If so, what’s the best planning algorithm should be? In a
>    real and large scale network, we have constraint on where the probing
>    device(s) can be placed, and we usually want to monitoring the entire
>    network, so an efficient algorithm is necessary.
>
>
>
> Best regards,
>
> Haoyu
>
>
>
> *From:* ippm <ippm-bounces@ietf.org> *On Behalf Of *
> Ruediger.Geib@telekom.de
> *Sent:* Tuesday, February 25, 2020 11:55 PM
> *To:* ippm-chairs@ietf.org
> *Cc:* spring@ietf.org; ippm@ietf.org
> *Subject:* [ippm] Monitoring metric to detect and locate congestion
>
>
>
> Dear IPPM (and SPRING) participants,
>
>
>
> I’m solliciting interest in a new network monitoring metric which allows
> to detect and locate congested interfaces. Important properties are
>
>    - Same scalability as ICMP ping in the sense one measurement relation
>    required per monitored connection
>    - Adds detection and location of congested interfaces as compared to
>    ICMP ping (otherwise measured metrics are compatible with ICMP ping)
>    - Requires Segment Routing (which means, measurement on forwarding
>    layer, no other interaction with passed routers – in opposite to ICMP ping)
>    - Active measurement (may be deployed using a single sender&receiver
>    or separate sender and receiver, Segment Routing allows for both options)
>
>
>
> I’d be happy to present the draft in Vancouver... If there’s community
> interest. Please read and comment.
>
>
>
> You’ll find slides at
>
>
>
>
> https://datatracker.ietf.org/meeting/105/materials/slides-105-ippm-14-draft-geib-ippm-connectivity-monitoring-00
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F105%2Fmaterials%2Fslides-105-ippm-14-draft-geib-ippm-connectivity-monitoring-00&data=02%7C01%7Chaoyu.song%40futurewei.com%7C4f7ef087db7046424e2508d7ba915817%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637183005756536633&sdata=98D7jZDubbhdB3ext94tjEElItEBVyDUld6cQtND6O4%3D&reserved=0>
>
>
>
> Draft url:
>
>
>
> https://datatracker.ietf.org/doc/draft-geib-ippm-connectivity-monitoring/
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-geib-ippm-connectivity-monitoring%2F&data=02%7C01%7Chaoyu.song%40futurewei.com%7C4f7ef087db7046424e2508d7ba915817%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637183005756546590&sdata=sRAxvsAvs2nHOFme1%2FVZV%2FcFgvZ5AIFtFe5jInmfy7Q%3D&reserved=0>
>
>
>
> Regards,
>
>
>
> Ruediger
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>