<mailto:ippm-cha...@ietf.org>;
spring@ietf.org<mailto:spring@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>
Subject: RE: [spring] Monitoring metric to detect and locate congestion
Two key differences. (1) you want to do this purely in data plane fast path.
(2) you don’t want to
Hi Haoyu,
thanks for your remarks. Let me pick up your numbering
1. IOAM information could be added by a passed router, if there's interest.
The draft doesn't exclude that. But that's not in focus either. I didn't make
up my mind, whether and which IOAM information may add value to such
me
from the draft).
Regards,
Ruediger
Von: MORTON, ALFRED C (AL)
Gesendet: Sonntag, 1. März 2020 22:25
An: Geib, Rüdiger ; rob...@raszuk.net
Cc: spring@ietf.org; ippm-cha...@ietf.org; i...@ietf.org
Betreff: RE: [spring] Monitoring metric to detect and locate congestion
Hi Rudiger,
I’m looking at
,
Al
From: ippm [mailto:ippm-boun...@ietf.org] On Behalf Of ruediger.g...@telekom.de
Sent: Thursday, February 27, 2020 5:42 AM
To: rob...@raszuk.net
Cc: spring@ietf.org; ippm-cha...@ietf.org; i...@ietf.org
Subject: Re: [ippm] [spring] Monitoring metric to detect and locate congestion
Hi Robert
Cc: ippm-cha...@ietf.org<mailto:ippm-cha...@ietf.org>;
spring@ietf.org<mailto:spring@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>
Subject: RE: [spring] Monitoring metric to detect and locate congestion
Two key differences. (1) you want to do this purely in data plane fast path.
ng@ietf.org<mailto:spring@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>
Subject: Re: [spring] Monitoring metric to detect and locate congestion
The point is not to assure all egress ports are inspected.
The point of any really useful end to end path probing is to find out if
combination of
Song ; Robert Raszuk
Cc: ippm-cha...@ietf.org; spring@ietf.org; i...@ietf.org
Subject: RE: [spring] Monitoring metric to detect and locate congestion
This is a good point. In this way, the probe is generically used to collect
node data.
At each node, the probe will be send to the slow path to get
Haoyu Song
Sent: Friday, February 28, 2020 4:44 AM
To: Robert Raszuk
Cc: ippm-cha...@ietf.org; spring@ietf.org; i...@ietf.org
Subject: Re: [ippm] [spring] Monitoring metric to detect and locate congestion
Can the combination ingress+egress queuing information on each transit node be
collected by
: ruediger.g...@telekom.de; ippm-cha...@ietf.org; spring@ietf.org;
i...@ietf.org
Subject: Re: [spring] Monitoring metric to detect and locate congestion
The point is not to assure all egress ports are inspected.
The point of any really useful end to end path probing is to find out if
combination of
.org; spring@ietf.org;
> i...@ietf.org
> *Subject:* 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 pra
...@ietf.org; spring@ietf.org;
i...@ietf.org
Subject: 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 ea
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 fundame
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.
...@ietf.org
Betreff: Re: [spring] Monitoring metric to detect and locate congestion
Hi,
As I mentioned in my first mail I am a big supporter of end to end path
measurement - mainly have been focusing on hop by hop timestamping approach.
So my comments were not really to discourage in any way end to end
>
>
>
> Regards,
>
>
>
> Ruediger
>
>
>
>
>
> *Von:* Robert Raszuk
> *Gesendet:* Mittwoch, 26. Februar 2020 14:19
> *An:* Geib, Rüdiger
> *Cc:* ippm-cha...@ietf.org; SPRING WG ; i...@ietf.org
> *Betreff:* Re: [spring] Monitoring metric to detect and
.
Regards,
Ruediger
Von: Robert Raszuk
Gesendet: Mittwoch, 26. Februar 2020 14:19
An: Geib, Rüdiger
Cc: ippm-cha...@ietf.org; SPRING WG ; i...@ietf.org
Betreff: Re: [spring] Monitoring metric to detect and locate congestion
Hi,
Two clarifications:
[RG1] the measurements pass the routers on
Hi,
Two clarifications:
[RG1] the measurements pass the routers on forwarding plane.
Well if I have 20K CEs and would like to measure this end to end that means
it better run on a router ... I can not envision installing 20K new PCs
just for this. At min such end point it should run on a well de
Hi Robert,
Thanks, my replies in line marked [RG1]
I have read your draft and presentation with interest as I am a big supporter
and in some lab trials of end to end network path probing.
Few comments, observations, questions:
You are essentially measuring and comparing delay across N paths t
Hi Ruediger,
I have read your draft and presentation with interest as I am a
big supporter and in some lab trials of end to end network path probing.
Few comments, observations, questions:
You are essentially measuring and comparing delay across N paths traversing
known network topology (I love
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
* Add
20 matches
Mail list logo
