[ippm] 答复: About Path Congestion Concept, welcome to discuss//Re: About path congestion metric, welcome to discuss

[Dangjuanna <[e-mail]>]

Dear Jose Ignacio Alvarez-Hamelin,
Thanks for your reply.
I have been reading draft AURA carefully for long time. I am so happy that we have the same interest in the path topics. I also have one team to research it which is one of my researches. And I will continue to contribute my idea around my target researches to our WG in future.
I have concerned the path or the path congestion for four years.  When receiving your email and Morton’s email, I was so excited.
As you know, I2 is the first measurement message received by the receiver node.  In this measurement, the minimum path delay is got and the  receiver node find the baseline time.  The second measurement is for the actual path delay.  The receiver will receive the second of the query message  at I3.
So dpr = I3 -I2 could be not negative.
As well known, it’s a difficult topic because traffic is non-stationary. But we have the mission to solve it.
I will arrive at IETF 104 tomorrow.
I am very much looking forward to seeing you.

Best wishes,
Joanna

发件人: Jose Ignacio Alvarez-Hamelin [mailto:[e-mail]]
发送时间: 2019年3月22日 21:10
收件人: Dangjuanna <[e-mail]>
抄送: MORTON, ALFRED C (AL) <[e-mail]>; [e-mail]
主题: Re: [ippm] About Path Congestion Concept, welcome to discuss//Re: About path congestion metric, welcome to discuss

Dear Joanna,

I have read your proposition, and I work on Internet measurements for long time, I have some questions and comments.

First, as Al Morton already pointed out, there is our work on the delay measurements (https://tools.ietf.org/html/draft-ietf-ippm-route-04)  which is a first step to measure congestion.

I would like to have a clear definition of congestion, which is, even in the specialized bibliography, a rough and variable concept.

Then, do you really tried to measure paths in the proposed way? If you perform this in the Internet you will find several things: first, if are measure average RTTs the results will largely varies along the time window and also in two consecutive windows; second, for a fixed window and two consecutive hops your dpr = I3 -I2 could be negative. Even though using other statistics (median, percentiles) you will find odds results.

If you take attention to our draft AURA, we work carefully to obtain something with certain statistic significance and sense. The problem is that traffic is non-stationary and have a short and long range correlations, yielding on a heavy tailed distribution; which in turn is not easy at all to treat it. This is the reason why you cannot just make a couple of measurements and get something significative in the Internet. My research group is sending a work to IMC 2019 on the congestion analysis, where we deal with real and large links in the Internet.

Best wishes,

J. Ignacio Alvarez-Hamelin
http://cnet.fi.uba.ar/en/

===================8<-----------------------
Enviado desde mi CarroT

On 15 Mar 2019, at 00:26, Dangjuanna <[e-mail]<mailto:[e-mail]>> wrote:
Hi everyone,
In the past few days, I learned about the hot spots of discussion on the mailing list. I feel that everyone is currently keen on the definition of the field that the message carries, but the test method is so equally important.
I think path congestion and increased network traffic are the most realistic and grounded issues. I hope that everyone will pay more attention to the resolution of some practical problems.
For example, path quality detection, especially path congestion.


1.       My multipath concurrent measurements can support not only E2E measurements, but also hop-by-hop data feeds. In other words, it can be seamlessly compatible with popular protocols such as IOAM or Postcard mode.

draft-dang-ippm-multiple-path-measurement-01.txt (https://tools.ietf.org/id/draft-dang-ippm-multiple-path-measurement-01.txt).

2.       My congestion test method uses not only the delay measurement, but also the throughput of the path.

draft-dang-ippm-congestion(https://tools.ietf.org/html/draft-dang-ippm-congestion-01)

3.       Regarding the congestion measurement of delay, I think the method of one-way delay measurement is optimal. This method does not support clock synchronization, which I think is very important.

4.       I think its principle of RTT-like measurements determines its accuracy is not enough. Moreover, the PING/TRACEROUTE method requires the CPU or NP to process, and my method can be processed directly on the data surface, so the accuracy and timeliness are stronger.

Regards,
Joanna

From: Dangjuanna
Sent: 2019年3月11日 19:56
To: 'MORTON, ALFRED C (AL)' <[e-mail]<mailto:[e-mail]>>; 'ippm@ietf..org' <[e-mail]<mailto:[e-mail]>>
Subject: RE: About Path Congestion Concept, welcome to discuss//Re: About path congestion metric, welcome to discuss

Dear Morton,
I’m very happy to discuss with you.
I have read “AURA” WG draft carefully and made the detailed notes.
Certainly, We are all concerned about the measurement of the path. Especially  I am more concerned with the measurement indicators and measurement methods of path congestion.
“AURA” WG draft describe there is path congestion requirement.  Just right, I provided the idea of congestion measurement.
Do you agree with me? I guess you should be very interested at my approach.
I am looking forward your reply.

Regards,
Joanna

From: Dangjuanna
Sent: 2019年3月11日 9:16
To: 'MORTON, ALFRED C (AL)' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: About Path Congestion Concept, welcome to discuss//Re: About path congestion metric, welcome to discuss

Dear Morton，
Thank you for your reply.
Last weekend I have looked through your draft named draft-ietf-ippm-route-03.  I value your thoughts very much.
Indeed, some focus of our thinking is on the same place. On this point, I am very happy that you are also concerned about this point. My current focus is mainly on path congestion, in the scenario of equal-cost multi-path (ECMP) mode and unequal-cost multiple (UCMP) mode.. First, I consider how to measure path congestion.
Next I will read the draft you suggested.  I will ask you in time if I have any questions.
If you have any good ideas or corrections, you are welcome to discuss more.

Best wishes,
Joanna

From: MORTON, ALFRED C (AL) [mailto:[e-mail]]
Sent: 2019年3月8日 20:58
To: Dangjuanna <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: About Path Congestion Concept, welcome to discuss//Re: About path congestion metric, welcome to discuss

Hi Joanna,

Your proposal sounds similar to parts of the current WG draft:
https://tools.ietf.org/html/draft-ietf-ippm-route-03

particularly section 5 and higher (where I would relate
delay to congestion), although discovering
the Path Ensemble is the first step (earlier sections).

Please take a look at the “AURA” WG draft and comment.

thanks,
Al
(for the AURA co-authors)

From: ippm [mailto:[e-mail]] On Behalf Of Dangjuanna
Sent: Wednesday, March 6, 2019 2:31 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [ippm] About Path Congestion Concept, welcome to discuss//Re: About path congestion metric, welcome to discuss

Hi  everyone,
Recently I have submitted the draft named draft-dang-ippm-congestion.
There are some questions I need to discuss with the experts.

Q1: Is path congestion required? Is this requirement strong?
  Import ServiceA Traffic to the path1
                  \
                   \
                   NodeA----------NodeN1----------NodeN2----------NodeB
                                 Figure: Path1
As figure Path1 is shown,
[Premise] Path1 is from Node A to NodeB. Path1 may be MPLS TE, SR TE Tunnel or VXLAN.
[Requirement] Get the congestion degree of Path1 in order to make sure the service experience.

Before, everyone was very concerned about the congestion of single device nodes. Along with the network development，we should pay more attention to the business perspective. Therefore, the path perspective of carrying the service is also required. I understand that the requirement for path congestion exists.

And I think this demand will become more and more important.

Q2: What is path congestion?
For the sake of explanation, I introduce a concept named Path Queue. The PathA Queue is activated if congestion occurs at any node along the Path1. Furthermore, when the PathA Queue is activated, it indicates that the path has been congested.


What do you think of it?
I am very happy and open to get everyone's thoughts.

Thank you,
Joanna

发件人: Dangjuanna
发送时间: 2019年3月4日 17:38
收件人: '[e-mail]<mailto:[e-mail]>' <[e-mail]<mailto:[e-mail]>>
主题: About path congestion metric, welcome to discuss

Hi everyone,
I have submit a new individual draft named A One-Path Congestion Metric for IPPM.
Welcome to discuss.
Best wishes,

Joanna Dang

===============================================

A new version of I-D, draft-dang-ippm-congestion-00.txt has been successfully submitted by Joanna Dang and posted to the IETF repository.



Name:               draft-dang-ippm-congestion

Revision:  00

Title:                  A One-Path Congestion Metric for IPPM

Document date:       2019-03-04

Group:               Individual Submission

Pages:               10

URL:            https://www.ietf.org/internet-drafts/draft-dang-ippm-congestion-00.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Ddang-2Dippm-2Dcongestion-2D00.txt&d=DwMFoQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=exkhZ59YMOdAl1AT9h6-LU4ANJmxljU9DMm2LQK8kfo&s=E_x2gKnItmjl9VuFNkNWQ1-CfncBwCR2D1hc94GkayM&e=>

Status:         https://datatracker.ietf.org/doc/draft-dang-ippm-congestion/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Ddang-2Dippm-2Dcongestion_&d=DwMFoQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=exkhZ59YMOdAl1AT9h6-LU4ANJmxljU9DMm2LQK8kfo&s=-ys-69SjqOJE-9lQMpKHbXH4HE99YKGxttzi50gknms&e=>

Htmlized:       https://tools.ietf.org/html/draft-dang-ippm-congestion-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Ddang-2Dippm-2Dcongestion-2D00&d=DwMFoQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=exkhZ59YMOdAl1AT9h6-LU4ANJmxljU9DMm2LQK8kfo&s=hxkSD1MJ-25fxiiLU0smIjx55XaaF_ybVYEfWS4hlok&e=>

Htmlized:       https://datatracker.ietf.org/doc/html/draft-dang-ippm-congestion<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Ddang-2Dippm-2Dcongestion&d=DwMFoQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=exkhZ59YMOdAl1AT9h6-LU4ANJmxljU9DMm2LQK8kfo&s=ww_tStxieJflH150r-Jkv8mG2ypLC7l-2eTXnVdWHMI&e=>





Abstract:

   This memo defines a metric for one path congestion across Internet

   paths.  The traditional mode evaluates network congestion based on

   the bandwidth utilization of the link.  However, there is a lack of

   E2E path congestion that is truly service oriented.  So A Path

   Congestion Metric is required.









Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.



The IETF Secretariat



_______________________________________________
ippm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ippm