Subject: Re: [ippm] draft on iOAM scalability improvement

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 20 Jun 2017 07:58:46 +0000

Hi Haoyu,

thanks for posting this well written draft. While reading the draft, I was wondering whether you have considered reversing the logic of your draft: Currently you start with identifying certain perceived "scalability issues" and offering associated solutions, but you only very briefly touch on the use-cases that would require those enhancements and don't detail the required data-fields. Given that the current focus of the work is to define data-fields for IOAM, would it make sense to describe the new use-cases and the required new data-fields first. The WG could then jointly discuss how to best fit these new data-fields in.

Thoughts?

Thanks, Frank

From: Haoyu song [mailto:[email-masked]]
Sent: Montag, 22. Mai 2017 19:23
To: [email-masked]; [email-masked]
Subject: draft on iOAM scalability improvement

Dear all,

We have submitted an iOAM related draft as follows.  Please kindly provide  comments and also let us know if you have any questions which will help us continue to improve the draft. Thank you very much!

https://datatracker.ietf.org/doc/draft-song-ippm-ioam-scalability/

Abstract:

   This document describes several scalability issues in current in-situ

   OAM documents and proposes corresponding solutions.  Specifically, we

   extend in-situ OAM to support more standard tracing data than is

   currently defined and add new features to avoid limitations on MTU,

   bandwidth, forwarding path length, and node processing capability.

Haoyu

---

From: David Mozes <[email-masked]>
Date: Thu, 22 Jun 2017 15:09:27 +0000

Hi  ,
I think there is an little mistake in the delay record. See below.

   transit delay:  4-octet unsigned integer in the range 0 to 2^30-1.
      It is the time in nanoseconds the packet spent in the transit
      node.  This can serve as an indication of the queuing delay at the
      node.  If the transit delay exceeds 2^30-1 nanoseconds then the
      top bit 'O' is set to indicate overflow.  When this field is part
      of the data field but a node populating the field is not able to
      fill it, the field position in the field must be filled with value
      0xFFFFFFFF to mean not populated.

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |O|                     transit delay                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I think it should be 2^31-1, because otherwise there is always 1 bit that is not used.

Let me know what do you think

Thx
David

From: Frank Brockners (fbrockne) [mailto:[email-masked]]
Sent: Tuesday, June 20, 2017 10:59 AM
To: Haoyu song <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: draft on iOAM scalability improvement

Hi Haoyu,

Thoughts?

Thanks, Frank

From: Haoyu song [mailto:[email-masked]]
Sent: Montag, 22. Mai 2017 19:23
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: draft on iOAM scalability improvement

Dear all,

https://datatracker.ietf.org/doc/draft-song-ippm-ioam-scalability/<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-ippm-ioam-scalability%2F&data=02%7C01%7Cdavidm%40mellanox.com%7Cbdf6a656408c4e654b3908d4b7b23555%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636335423410206267&sdata=c6Lxhd6%2FXLty2RjzLpLwooM8Zy3yJs3XtyipKkzRUsw%3D&reserved=0>

Abstract:

Haoyu

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 23 Jun 2017 02:42:31 +0000

Hi,

I have some suggestions on existing time related data fields.

1. The timestamp, for example the "timestamp seconds", is "absolute timestamp in seconds that specifies the time at which the packet was received by the node." So does this mean the timestamp is taken at the ingress? If so, it's worth to explicitly name it "ingress timestamp" or so. So that every device can have the identical behavior to take the timestamp to, for example, calculate the hop by hop delay.

2. The "transit delay", IMHO, is not easy to calculate in some devices, because of the architecture limitation. If we want to get this information, we can record the "egress timestamp" relative to the "ingress timestamp". Then, the transit delay can be calculated at any position that device can do this.

Thanks,
Tianran

From: ippm [mailto:[email-masked]] On Behalf Of David Mozes
Sent: Thursday, June 22, 2017 11:09 PM
To: Frank Brockners (fbrockne); Haoyu song; [email-masked]; [email-masked]
Subject: Re: [ippm] draft on iOAM scalability improvement

Hi  ,

Thx
David

From: Frank Brockners (fbrockne) [mailto:[email-masked]]
Sent: Tuesday, June 20, 2017 10:59 AM
To: Haoyu song <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: draft on iOAM scalability improvement

Hi Haoyu,

Thoughts?

Thanks, Frank

Dear all,

Abstract:

Haoyu

---

From: Haoyu song <[email-masked]>
Date: Fri, 23 Jun 2017 17:19:43 +0000

I agree. There is a tradeoff between node processing overhead and data carry overhead. It makes sense to define both of them and let user decide which data type is used based on their actual network situation.
Besides, the last improvement we introduced in the following draft, the "valid data bitmap" allows each node to decide which data to provide, if the source asks for both.
https://datatracker.ietf.org/doc/draft-song-ippm-ioam-scalability/

Haoyu
From: Tianran Zhou
Sent: Thursday, June 22, 2017 7:43 PM
To: David Mozes <[email-masked]>; Frank Brockners (fbrockne) <[email-masked]>; Haoyu song <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: draft on iOAM scalability improvement

Hi,

Thanks,
Tianran

From: ippm [mailto:[email-masked]] On Behalf Of David Mozes
Sent: Thursday, June 22, 2017 11:09 PM
To: Frank Brockners (fbrockne); Haoyu song; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [ippm] draft on iOAM scalability improvement

Hi  ,

Thx
David

Hi Haoyu,

Thoughts?

Thanks, Frank

Dear all,

Abstract:

Haoyu

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 27 Jun 2017 00:48:14 +0000

Haoyu,

Thank you for sharing a very well written draft — both in content and format!

The way in which I see the analysis presented, however, is a bit different than “scalability limitations”. I believe these proposals are optimizations for specific scaling requirements or for particular use cases. In fact, this draft seems to describe tradeoffs — and how to ponder the weights (precision, pak size, processing) depends on the use case and what to optimize (as opposed to a right vs. wrong answer).

So, under which conditions do you see these as useful?

Thanks!

— Carlos.

On May 22, 2017, at 1:22 PM, Haoyu song <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

Abstract:

Haoyu

---

From: Haoyu song <[email-masked]>
Date: Tue, 27 Jun 2017 01:48:48 +0000

Hi Carlos,

Thank you for the comments! You are right that in the draft we intend to describe some implementation tradeoffs depending on the data plane capability and those tradeoffs need to add some extra flexibility to the current iOAM header specification.
While IOAM data is very useful, its cost (bandwidth consumption and processing requirements) is not negligible. The protocol should strive to allow graceful tradeoffs at the beginning. I’m working on a revision of the draft to clarify it. Thanks!

Haoyu

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Monday, June 26, 2017 5:48 PM
To: Haoyu song <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: draft on iOAM scalability improvement

Haoyu,

Thanks!

— Carlos.

Dear all,

Abstract:

Haoyu

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 27 Jun 2017 02:04:02 +0000

Hi, Haoyu,

One of my points is that the draft talks about a number of “costs” (including also size) but we cannot say how negligible or not they are until we understand under which use case they are being considered.

Look forward to your next version, and in particular use-case applicability to the different costs and tradeoffs. That way, the WG will be able to see where to focus the need for protocol flexibility (at the cost of complexity).

Thanks!

— Carlos.

On Jun 26, 2017, at 9:48 PM, Haoyu song <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

Haoyu

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Monday, June 26, 2017 5:48 PM
To: Haoyu song <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft on iOAM scalability improvement

Haoyu,

Thanks!

— Carlos.

Dear all,

Abstract:

Haoyu

---

From: Haoyu song <[email-masked]>
Date: Tue, 27 Jun 2017 18:01:09 +0000

Hi Carlos,

We have listed quite a few use cases in the draft, although those use cases are more qualitative than quantitative now.  Please let me know what specific information you want to see.

We have done some rough analysis on ioam applicability on different type of platforms and did find some performance concerns as being laid out in the draft. But we still need more time to finish that work and we are not sure which level of detail should be included.

We can discuss more about this during the meeting. Thanks!

Haoyu

Sent: Monday, June 26, 2017 7:04 PM

Hi, Haoyu,

Thanks!

— Carlos.

Hi Carlos,

Haoyu

Haoyu,

Thanks!

— Carlos.

Dear all,

Abstract:

Haoyu