Subject: [ippm] WGLC on draft-ietf-ippm-active-passive-01

From: Brian Trammell <[email-masked]>
Date: Wed, 7 Oct 2015 12:47:12 +0200

Greetings, all,

WG last call on draft-ietf-ippm-active-passive-01 begins today, and will end Wednesday 21 October 2015. Please send any comments (including "I've read it and it's good" :) ) to the [email-masked] list.

Thanks, cheers,

Brian (chair hat)

---

From: Ionta Tiziano <[email-masked]>
Date: Thu, 8 Oct 2015 06:58:23 +0000

Hi
I've read the document and I agree with the contents.
Best
Tiziano Ionta

-----Messaggio originale-----
Da: ippm [mailto:[email-masked]] Per conto di Brian Trammell
Inviato: mercoledì 7 ottobre 2015 12.47
A: [email-masked]
Oggetto: [ippm] WGLC on draft-ietf-ippm-active-passive-01

Greetings, all,

Thanks, cheers,

Brian (chair hat)

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Joachim Fabini <[email-masked]>
Date: Tue, 13 Oct 2015 12:10:16 +0200

Hi Brian, Al, IPPM,

I've read it and it's good... ;) The active-passive-hybrid definition
and categorization helps enormously and should have been started years
ago - many thanks to Al for taking the initiative. I consider this work
to be relevant also for the scientific community. In particular the term
hybrid is used with many diverging meanings (commonly as a buzzword when
applying for new project funding), so I spent some time on reviewing and
reasoning about. Disclaimer: I've not been involved into earlier
discussions on this draft and it's the first time I read it. Consider it
to be an unbiased first-time-reader opinion.

Comments (sequential reading, _no_ priority ordering):

Sec. 3.4 (1) s/"a packet stream..."/"Additional packet streams..."/ to
be more generic? Any stream can be an aggregate of other streams, but
the second variant seems to be more accurate and flexible (thinking of
several streams with distinct sources and destinations for impairing
distinct sub-paths of the measurement path).

Sec. 3.4 (2) "The packets in the stream(s) of interest have fields (or
are augmented or modified to include fields) which are dedicated to
measurements"
Proposed (relaxing) addition: Instead of dedicated measurement fields an
aggregated set of packet header _values_ can be sufficient to identify
packets as being part of the active measurement stream.
Considering the hypothetical case of UDP BTC measurements, the traffic
is actively generated, so the method is active. But packets are not
marked, nor are there any specific fields like sequence numbers that can
be used to identify packets. And for a UDP BTC metric there is no need
for such. One could argue that packets of a UDP measurement stream can
be identified by SRC/DST IP addresses and port numbers, which is why
these fields are dedicated to measurement - but that's not intuitive.
Alternatively the two occurrences of "fields" could be replaced by
"fields or field values". The key is that these specific measurement
stream packets are selected/evaluated/measured in at least one
measurement location. Possibly nitpicking?

Sec. 3.4 (3) possible typo (known a' priori)

Sec. 3.4: not sure: does it make sense to mention in a note  possible
changes of packet type (Type-P) along the measurement path (e.g.
IPv4->IPv6, tunneling, addition of headers) and possible resulting
measurement issues? We address this issue in the IPv6 draft but my
feeling is that it can help to raise reader's awareness in this draft,
too. Type-P at the source does not necessarily mean same Type-P at the
destination (same observation is valid for passively observing
intermediate nodes)

Sec. 3.6: What about Passive Measurements and generating background
load? Consider the case of passive monitoring of a cellular link that
does on-demand capacity allocation. The measurement process observes the
measurement stream at ingress and egress. One might be tempted to
generated some background load that triggers allocation of additional
capacity on the link. Where does this method fit into: passive or
hybrid? I'm not sure. As a matter of consistency with the section on
active methods (where you mention background load traffic explicitly) it
might be appropriate to discuss this special case for passive methods, too.

Sec. 3.7: Last paragraph (sentence) is very long and difficult to
understand, including possible typos. Should "basis of reference events
as packet pass reference point" read "basis of reference events that are
generated as packet_s_ pass reference points"? Rephrasing can help here.

Sec. 3.8: The differentiation between hybride-active-passive is not
clear to me from the definition in 3.8. I believe that the definition of
"hybrid" {sh|c}ould be sharpened to delimit "hybrid" more accurately
from active and passive.

One particular case of hybrid measurement - imho the most compelling one
- is the one where passive measurements are combined with additions of
fields or changes of field values in intermediate
(observation/measurement) nodes. This includes all kinds of packet
markings, addition of header fields or changes in header field values in
intermediate nodes. However, to make the measurement hybrid, these
changes must be a _consequence_ or _result_ of actions undertaken by the
(otherwise passive) _measurement_ process.
My personal opinion on this:
a) Active: whenever the measurement process generates a dedicated stream
of measurement packets, where packets are identifiable either by
dedicated measurement fields (either in payload or header), and/or by
(possibly aggregated, i.e., set of) field values, the method/metric can
be categorized as active
b) Passive: whenever the measurement process observes an existing stream
of packets without changing/adding/removing any packet fields or field
values. The passive monitoring _must_not_ add/change/remove header
fields or header field values. Although passive monitoring might bias
the timing of the observed traffic to some extent (be it by setting
interfaces into promiscous mode or by inserting splitters into the path)
it does not do this _intentionally_. Open question: into which category
does the generation of background load for passive measurements fit?
c) Hybrid: the measurement acts exclusively on existing traffic, that
is, anything that is categorized as passive (b). However, the
_measurement_ process adds/changes/removes fields or changes packet
field values in (intermediate) nodes as part of the measurement (may be
header or payload). Obviously, IPv4 header updates that result from
forwarding rules (checksum, TTL) are NOT part of the measurement
process. Question: does "passive + background load" fit into hybrid?

Sec. 3.8: Possible Typo: Y.1540 define_s_ -> _d_?

Sec. 4: 1. Possible typo "effects" -> "biases"?

Sec. 4: "To keep simple, we consider the stream effect only when it is
present".
This statement imho conflicts with the main findings of RFC7312. Today's
networks store flow/stream state at layers below IP, so networks have a
"historic view". I doubt that this bias can be ignored - infact the bias
of past periods is visible during the current measurement period. A
mention of possible consequences in stateful networks with reference to
7312 could be a cheap solution (not sure if this is sufficient).

Sec. 4: ASCII diagram: it might improve readability to add axis labels
(don't know how this can be done easily, maybe split/break descriptions
of reference points onto several lines): y axis label: "Measurement
stream capacity", x axis label: "Stream characteristics known".
In this context its's also not clear to me whether stream
characteristics must be just "known" or if they must be
controled/generated/changed.

Sec. 4, 4.1, 4.2: Page 7: The examples (and detailed reasoning) are
excellent here to support and illustrate the categories defined before.
Still, I believe that an earlier clear categorization
active/passive/hybrid in sec. 3.8 can ease the reading.

Sec. 4.1., 4.2: I fully agree with the categorization. However, is the
"small effect" essential for these examples/statement? One could find
several cases when the bias onto measurements is substantial - anything
between a) "packets become too large when adding the PDM header and
results in <IPv6-fragementation-required> to the sending host", b) "Size
increase with PDM header makes stream to exceed a network threshold and
trigger channel capacity re-allocation" and c) "subsequent nodes on the
path drop these packets because of the measurement node modifications".
All of these actions should result in substantial bias of measurement
results. And even the change of field values could result in
intermediate nodes to apply distinct forwarding policies to the packets.

The point is that the measurement process _intends_ to introduce a
minimum bias but it's quite difficult to estimate the consequences onto
measurement results. If this _intention_ is key, then I'm fine with the
wording. Otherwise one could think about a possible rephrase.

Summarizing: I consider this draft and its definitions to be essential
for the work and discussions of IPPM and related working groups. It
tackles the definitions it is supposed to and treats them in adequate
depth. As a first-time reader I had the impression that some few
sentences and clarifications can substantially improve the
categorization and delimiting of active/passive/hybrid methods in sec.
3.4-3.8 - I consider this to be the key part of the draft.

regards
Joachim

On 07.10.2015 12:47, Brian Trammell wrote:
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>

---

From: <[email-masked]>
Date: Mon, 19 Oct 2015 22:12:11 +0000 (UTC)

IPPM, Al, Brian, Joachim,

I have read this draft and support its adoption.

Some comments:

1.  Throughout the document, "a' priori" should be "a priori".

2.  Joachim had made the comment on Sec 4.1 and Sec 4.2 on PDM, while discussing the statement:

"The method may have a small effect on the measured stream and other streams in the network."

Joachim's comments:

>>"Sec. 4.1., 4.2: I fully agree with the categorization. However, is the "small effect" essential for these examples/statement? One could find several cases when the bias onto >>measurements is substantial - anything between a) "packets become too large when adding the PDM header and results in <IPv6-fragementation-required> to the sending host", b) >>"Size increase with PDM header makes stream to exceed a network threshold and trigger channel capacity re-allocation" and c) "subsequent nodes on the path drop these packets because of the measurement node modifications". 

>>All of these actions should result in substantial bias of measurement results. And even the change of field values could result in intermediate nodes to apply distinct forwarding >>policies to the packets."

Indeed, all such can be the case if one is pushing up against the largest packet size on the network or against some type of boundary.  We have been working on our own PDM implementation as well as discussing it with commercial TCP/IP stack developers.  We will discuss this in detail in Yokohama.

On a more general note, I believe that when using hybrid modes, it becomes critical to not trigger such network events by careful implementation and planning.  One thing that I have seen network operators do when they know that they may have extra headers potentially added is to "leave room".  That is, for example, send a normal packet that is 1,430 rather than 1,480. If you have a packet that is 1,480 on a network with a 1,500 MTU, then just about anything you add is going to lead to fragmentation.

I wonder if we need to say something like "Testing needs to be planned carefully so that the impact of additional headers or markings in the packet do not lead to packet bias".
 Thanks,

Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

----- Original Message -----
From: Brian Trammell <[email-masked]>
To: [email-masked]
Cc: 
Sent: Wednesday, October 7, 2015 3:47 AM
Subject: [ippm] WGLC on draft-ietf-ippm-active-passive-01

Greetings, all,

Thanks, cheers,

Brian (chair hat)

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 19 Oct 2015 18:55:58 -0400

Thanks, Nalini! 
a few things to fix-up when submission opens again.
Al

> -----Original Message-----
> From: ippm [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, October 19, 2015 6:12 PM
> To: Brian Trammell; [email-masked]
> Subject: Re: [ippm] WGLC on draft-ietf-ippm-active-passive-01
> 
> >>"Sec. 4.1., 4.2: I fully agree with the categorization. However, is
> the "small effect" essential for these examples/statement? One could
> find several cases when the bias onto >>measurements is substantial -
> anything between a) "packets become too large when adding the PDM header
> and results in <IPv6-fragementation-required> to the sending host", b)
> >>"Size increase with PDM header makes stream to exceed a network
> threshold and trigger channel capacity re-allocation" and c) "subsequent
> nodes on the path drop these packets because of the measurement node
> modifications".
> 
> intermediate nodes to apply distinct forwarding >>policies to the
> packets."
> 
> 
> Indeed, all such can be the case if one is pushing up against the
> largest packet size on the network or against some type of boundary.  We
> have been working on our own PDM implementation as well as discussing it
> with commercial TCP/IP stack developers.  We will discuss this in detail
> in Yokohama.
> 
> On a more general note, I believe that when using hybrid modes, it
> becomes critical to not trigger such network events by careful
> implementation and planning.  One thing that I have seen network
> operators do when they know that they may have extra headers potentially
> added is to "leave room".  That is, for example, send a normal packet
> that is 1,430 rather than 1,480. If you have a packet that is 1,480 on a
> network with a 1,500 MTU, then just about anything you add is going to
> lead to fragmentation.
> 
> I wonder if we need to say something like "Testing needs to be planned
> carefully so that the impact of additional headers or markings in the
> packet do not lead to packet bias".
>  Thanks,
> 
> Nalini Elkins
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360
> 
> 
> WG last call on draft-ietf-ippm-active-passive-01 begins today, and will
> end Wednesday 21 October 2015. Please send any comments (including "I've
> read it and it's good" :) ) to the [email-masked] list.
> 
> Thanks, cheers,
> 
> Brian (chair hat)

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 20 Oct 2015 15:12:29 -0700

Hi Joachim, et. al,
I believe that characterization of a measurement method as active, passive
or hybrid must be based on its impact on the otherwise normal network
behavior. If the method alters the network behavior or treatment of the
data, then it is active measurement method. If the method does not change
network behavior in any aspect, then it is passive. Why I believe that is
important? Because from this point, marking method that does not affect
treatment of the flow by the network is passive, not active measurement
method since marked and unmarked packets are indistinguishable to the
network except for observer(s). But it the marking method applied in the
manner that would change how marked packets being processed comparing to
unmarked, then it is active method.

Regards,
Greg

On Tue, Oct 13, 2015 at 3:10 AM, Joachim Fabini <[email-masked]
> wrote:

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 20 Oct 2015 23:42:39 +0000

Thanks Greg!

A couple questions popped to mind.

1.       Under what conditions would marking or any other method be considered HYBRID?

2.       Based on what you say below,  how would you classify PDM?

Thanks again!

Mike

From: ippm [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Tuesday, October 20, 2015 6:12 PM
To: Joachim Fabini <[email-masked]>
Cc: [email-masked]
Subject: Re: [ippm] WGLC on draft-ietf-ippm-active-passive-01

Hi Joachim, et. al,
I believe that characterization of a measurement method as active, passive or hybrid must be based on its impact on the otherwise normal network behavior. If the method alters the network behavior or treatment of the data, then it is active measurement method. If the method does not change network behavior in any aspect, then it is passive. Why I believe that is important? Because from this point, marking method that does not affect treatment of the flow by the network is passive, not active measurement method since marked and unmarked packets are indistinguishable to the network except for observer(s). But it the marking method applied in the manner that would change how marked packets being processed comparing to unmarked, then it is active method.

Regards,
Greg

On Tue, Oct 13, 2015 at 3:10 AM, Joachim Fabini <[email-masked]<mailto:[email-masked]>> wrote:
Hi Brian, Al, IPPM,

regards
Joachim

On 07.10.2015 12:47, Brian Trammell wrote:
> Greetings, all,
>
> WG last call on draft-ietf-ippm-active-passive-01 begins today, and will end Wednesday 21 October 2015. Please send any comments (including "I've read it and it's good" :) ) to the [email-masked]<mailto:[email-masked]> list.
>
> Thanks, cheers,
>
> Brian (chair hat)
>
>
>
> [email-masked]<mailto:[email-masked]>

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

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 20 Oct 2015 23:56:02 +0000

Hi Mike,
very good questions, thank you.
Have to admit, I still don’t have good example of a hybrid measurement method if using the proposed criteria.
If IPv6 Destination Options Header inserted by the source of the flow, then use of it to perform PDM, in my view, would not change network behavior and thus be passive measurement. But if the header inserted only for the period of the measurement – active.
As you can see, impact on the network criteria makes some methods … hybrid. Perhaps that’s what hybrid methods are – active or passive, depending on how they’ve been performed?

                Regards,
                                Greg

From: ippm [mailto:[email-masked]] On Behalf Of Ackermann, Michael
Sent: Tuesday, October 20, 2015 4:43 PM
To: Greg Mirsky; Joachim Fabini
Cc: [email-masked]
Subject: Re: [ippm] WGLC on draft-ietf-ippm-active-passive-01

Thanks Greg!

Thanks again!

Mike

From: ippm [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Tuesday, October 20, 2015 6:12 PM
To: Joachim Fabini <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [ippm] WGLC on draft-ietf-ippm-active-passive-01

Hi Joachim, et. al,

Regards,
Greg

regards
Joachim

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 20 Oct 2015 22:35:32 -0400

Hi Greg,

I don’t see a clear way to include impact on normal network behavior
in a definition, because:

- the network behavior may be unknown.
- the network behavior may change.
- the network may react to any/every new packet.
- the network can react to any packet feature that is in clear view.

We have discussed that some methods intend to have small impact,
but we can never be certain that they will achieve this goal.

Al

To: Joachim Fabini

Hi Joachim, et. al,

Regards,
Greg

regards
Joachim

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 21 Oct 2015 04:28:52 +0000

Hi Al,
thank you for sharing you view. Perhaps I used “normal behavior” somewhat too often and without clearly linking it to treatment, processing on a packet to which the measurement method in question directly applied. As Mike and I discussed PDM, we’ve looked at the cases when the Optional header is already part of the packet and when the header must be added in order to support the PDM. In the first case I don’t see that PDM alters processing on the packet by the network while in the second there’s clear impact as the packet size must be increased.
Hope this example explains the context in which I’ve used “normal network behavior”.

                Regards,
                                Greg

From: ippm [mailto:[email-masked]] On Behalf Of MORTON, ALFRED C (AL)
Sent: Tuesday, October 20, 2015 7:36 PM
To: Greg Mirsky; Joachim Fabini
Cc: [email-masked]
Subject: Re: [ippm] WGLC on draft-ietf-ippm-active-passive-01

Hi Greg,

Al

Hi Joachim, et. al,

Regards,
Greg

regards
Joachim

---

From: Joachim Fabini <[email-masked]>
Date: Wed, 21 Oct 2015 09:19:55 +0200

Hi Greg, all,

it's an interesting aspect that you raise. There are several
perspectives to approach this issue - but I see all of them ending up in
categorizing value changes as hybrid. Below my reasoning:

One key observation is that networks do no longer behave like stateless
copper wires as we used to abstract them. Many networks and components
store internal state and per-session or per-flow information.
There is no way and no rule to predict the consequences of changing a
single bit in packet payload or packet headers along an unknown path.

Whenever an intermediate node _adds_a_new_ field (e.g., PDM) to an
observed packet, this changes the way the network treats the packet
according to our traditional copper wire abstraction (packetDelay =
defaultDelay + packetSize/linkCapacity). So there is no doubt that this
is a hybrid case, right?

But there is no way to infer the consequence of marking packets (i.e.,
changing values of header fields beyond the basics required for IPv4
routing, meaning TTL and Checksum for IPv4) in the general case.
My position is that this draft _must_ tackle the _most_general_ worst
case. That is, value changes (potentially) modify the way an unknown
path treats these packets.
I agree that in particular scenarios (white-box measurements) the path
and behavior of all of its links and systems might be known. In such a
case I see, indeed, an overlapping of hybrid and passive - in the sense
that the method is hybrid _and_ might be categorized as passive, too,
when the white-box analysis indicates that marking (in terms of value
changes) has no impact on the way the network treats the packets.

Still, my absolute preference is to address the most general case. Which
means, that any packet modification by _measurement_ processes_ in
intermediate nodes - this includes both, a) addition/deletion of fields
or b) modification of _values_, labels this measurement method to belong
to the hybrid category.

Another argument: Assume that there are several, overlapping
measurements of packets ongoing along the same path. Some of them (a)
strictly passive, observing, some of them (b) hybrid. The passive
measurement (a) relies on specific packet checksums or hashes to
identify a packet in subsequent intermediate nodes and has no knowledge
of (b). Now assume that the hybrid measurement process (b) marks some
packets (changes values, adds fields). This will potentially screw up
(a)'s ability to identify packets.

But let's put this into the context of the theoretical IPPM framework:
changing packet header values in intermediate nodes modifies the Type-P
of the packet. Your measurement process might use a superset of Type-P
(that ignores the marking) to categorize packets, other components might
use subsets (that do _not_ ignore the marking). In the general case and
for black-box paths, a measurement process can not predict the
consequences of markings in intermediate nodes onto the Type-P treatment
of all potential links and components along the path.

Just recently I found a surprisingly future-proof paragraph in RFC 2330
(RFC 2330, page 30, second paragraph):

"A closely related note: it would be very useful to know if a given
Internet component treats equally a class C of different types of
packets. If so, then any one of those types of packets can be used
for subsequent measurement of the component. This suggests we devise
a metric or suite of metrics that attempt to determine C."

Referencing this definition, one possible compromise could be the
following observation (with explicit reference to the paragraph above):
"hybrid measurements that mark packets of a class C in intermediate
nodes may be categorized as passive, too, when all parties accessing
these packets along the path (in between and including sender and
receiver) categorize both types of packets, before the marking and
afterwards, into the same class C".

Summarizing, my position is that whenever a measurement process changes
packet header values in intermediate nodes this categorizes the process
as hybrid.

Joachim

On 21.10.2015 06:28, Gregory Mirsky wrote:
> Hi Al,
> 
> thank you for sharing you view. Perhaps I used “normal behavior”
> somewhat too often and without clearly linking it to treatment,
> processing on a packet to which the measurement method in question
> directly applied. As Mike and I discussed PDM, we’ve looked at the cases
> when the Optional header is already part of the packet and when the
> header must be added in order to support the PDM. In the first case I
> don’t see that PDM alters processing on the packet by the network while
> in the second there’s clear impact as the packet size must be increased.
> 
> *From:*ippm [mailto:[email-masked]] *On Behalf Of *MORTON, ALFRED
> C (AL)
> *Sent:* Tuesday, October 20, 2015 7:36 PM
> *To:* Greg Mirsky; Joachim Fabini
> *Cc:* [email-masked]
> *Subject:* Re: [ippm] WGLC on draft-ietf-ippm-active-passive-01
> 
>  
> 
> Hi Greg,
> 
>  
> 
> *From:*ippm [mailto:[email-masked]] *On Behalf Of *Greg Mirsky
> *Sent:* Tuesday, October 20, 2015 6:12 PM
> *To:* Joachim Fabini
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [ippm] WGLC on draft-ietf-ippm-active-passive-01
> 
>  
> 
> Hi Joachim, et. al,
> 
> I believe that characterization of a measurement method as active,
> passive or hybrid must be based on its impact on the otherwise normal
> network behavior. If the method alters the network behavior or treatment
> of the data, then it is active measurement method. If the method does
> not change network behavior in any aspect, then it is passive. Why I
> believe that is important? Because from this point, marking method that
> does not affect treatment of the flow by the network is passive, not
> active measurement method since marked and unmarked packets are
> indistinguishable to the network except for observer(s). But it the
> marking method applied in the manner that would change how marked
> packets being processed comparing to unmarked, then it is active method.
> 
>  
> 
> Regards,
> 
> Greg
> 
>  
> 
> On Tue, Oct 13, 2015 at 3:10 AM, Joachim Fabini
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Brian, Al, IPPM,
> 
>> WG last call on draft-ietf-ippm-active-passive-01 begins today, and
> will end Wednesday 21 October 2015. Please send any comments (including
> "I've read it and it's good" :) ) to the [email-masked]
> <mailto:[email-masked]> list.
>>
>> Thanks, cheers,
>>
>> Brian (chair hat)
>>
>>
>>
>> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: "Ackermann, Michael" <[email-masked]>
Date: Wed, 21 Oct 2015 14:35:28 +0000

Joachim and All,

Great comments and the great  Active/Passive/Hybrid debate (that we have avoided having  for a couple years),   may finally be in the home stretch to resolution?  

We may not be able to conclude this over Email.  A live integrative conversion would be great, but may take hours?   We may want to provisionally plan on a BOF or after hours session for all who have interest or comments? 

Just a couple quick thoughts on what Joachim said below:

Methods like PDM and most Extension Headers should not be altered or even read by intermediate nodes.   PDM uses DOH for this reason.    We can site exceptions such as HOP by HOP EH's,  but PDM is exclusively DOH.    I guess that makes PDM "Usually"  Passive?     I say "Usually" because our intent is that PDM could be on all the time, OR,  PDM could be used as an exceptional debugging tool.   From what I understand right now,  the latter sense I would consider Hybrid.  

So, since I cannot totally ignore the global IPV6 EH debate,  I will add that it is conceivable that the presence of a DOH,  for PDM or any other purpose,  COULD elongate a packet to the point that an intermediate node is forced to process the packet in software, rather than hardware,  and that would alter network performance.  

I agree with Joachim that we need to consider that networks are getting more complex and that trend will continue.  This makes our Active/Passive/Hybrid debate more difficult,  but it also shows how important it is to understand and get right.  

I would also agree that any alterations made by an intermediate node should cause that method to be considered Hybrid.  

Thanks to all for the great discussions. 

Mike

-----Original Message-----
From: ippm [mailto:[email-masked]] On Behalf Of Joachim Fabini
Sent: Wednesday, October 21, 2015 3:20 AM
To: Gregory Mirsky <[email-masked]>; MORTON, ALFRED C (AL) <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: [email-masked]
Subject: Re: [ippm] WGLC on draft-ietf-ippm-active-passive-01

Hi Greg, all,

it's an interesting aspect that you raise. There are several perspectives to approach this issue - but I see all of them ending up in categorizing value changes as hybrid. Below my reasoning:

One key observation is that networks do no longer behave like stateless copper wires as we used to abstract them. Many networks and components store internal state and per-session or per-flow information.
There is no way and no rule to predict the consequences of changing a single bit in packet payload or packet headers along an unknown path.

Whenever an intermediate node _adds_a_new_ field (e.g., PDM) to an observed packet, this changes the way the network treats the packet according to our traditional copper wire abstraction (packetDelay = defaultDelay + packetSize/linkCapacity). So there is no doubt that this is a hybrid case, right?

But there is no way to infer the consequence of marking packets (i.e., changing values of header fields beyond the basics required for IPv4 routing, meaning TTL and Checksum for IPv4) in the general case.
My position is that this draft _must_ tackle the _most_general_ worst case. That is, value changes (potentially) modify the way an unknown path treats these packets.
I agree that in particular scenarios (white-box measurements) the path and behavior of all of its links and systems might be known. In such a case I see, indeed, an overlapping of hybrid and passive - in the sense that the method is hybrid _and_ might be categorized as passive, too, when the white-box analysis indicates that marking (in terms of value
changes) has no impact on the way the network treats the packets.

Still, my absolute preference is to address the most general case. Which means, that any packet modification by _measurement_ processes_ in intermediate nodes - this includes both, a) addition/deletion of fields or b) modification of _values_, labels this measurement method to belong to the hybrid category.

Another argument: Assume that there are several, overlapping measurements of packets ongoing along the same path. Some of them (a) strictly passive, observing, some of them (b) hybrid. The passive measurement (a) relies on specific packet checksums or hashes to identify a packet in subsequent intermediate nodes and has no knowledge of (b). Now assume that the hybrid measurement process (b) marks some packets (changes values, adds fields). This will potentially screw up (a)'s ability to identify packets.

But let's put this into the context of the theoretical IPPM framework:
changing packet header values in intermediate nodes modifies the Type-P of the packet. Your measurement process might use a superset of Type-P (that ignores the marking) to categorize packets, other components might use subsets (that do _not_ ignore the marking). In the general case and for black-box paths, a measurement process can not predict the consequences of markings in intermediate nodes onto the Type-P treatment of all potential links and components along the path.

Just recently I found a surprisingly future-proof paragraph in RFC 2330 (RFC 2330, page 30, second paragraph):

"A closely related note: it would be very useful to know if a given Internet component treats equally a class C of different types of packets. If so, then any one of those types of packets can be used for subsequent measurement of the component. This suggests we devise a metric or suite of metrics that attempt to determine C."

Referencing this definition, one possible compromise could be the following observation (with explicit reference to the paragraph above):
"hybrid measurements that mark packets of a class C in intermediate nodes may be categorized as passive, too, when all parties accessing these packets along the path (in between and including sender and
receiver) categorize both types of packets, before the marking and afterwards, into the same class C".

Summarizing, my position is that whenever a measurement process changes packet header values in intermediate nodes this categorizes the process as hybrid.

Joachim

On 21.10.2015 06:28, Gregory Mirsky wrote:
> directly applied. As Mike and I discussed PDM, we’ve looked at the 
> cases when the Optional header is already part of the packet and when 
> the header must be added in order to support the PDM. In the first 
> case I don’t see that PDM alters processing on the packet by the 
> network while in the second there’s clear impact as the packet size must be increased.
> 
> *From:*ippm [mailto:[email-masked]] *On Behalf Of *MORTON, 
> ALFRED C (AL)
> network behavior. If the method alters the network behavior or 
> treatment of the data, then it is active measurement method. If the 
> method does not change network behavior in any aspect, then it is 
> passive. Why I believe that is important? Because from this point, 
> marking method that does not affect treatment of the flow by the 
> network is passive, not active measurement method since marked and 
> unmarked packets are indistinguishable to the network except for 
> observer(s). But it the marking method applied in the manner that 
> would change how marked packets being processed comparing to unmarked, then it is active method.
> 
>  
> 
> Regards,
> 
> Greg
> 
>  
> 
> ago - many thanks to Al for taking the initiative. I consider this 
> work to be relevant also for the scientific community. In particular 
> the term hybrid is used with many diverging meanings (commonly as a 
> buzzword when applying for new project funding), so I spent some time 
> on reviewing and reasoning about. Disclaimer: I've not been involved 
> into earlier discussions on this draft and it's the first time I read 
> it. Consider it to be an unbiased first-time-reader opinion.
> 
> Proposed (relaxing) addition: Instead of dedicated measurement fields 
> an aggregated set of packet header _values_ can be sufficient to 
> identify packets as being part of the active measurement stream.
> marked, nor are there any specific fields like sequence numbers that 
> can be used to identify packets. And for a UDP BTC metric there is no 
> need for such. One could argue that packets of a UDP measurement 
> stream can be identified by SRC/DST IP addresses and port numbers, 
> which is why these fields are dedicated to measurement - but that's not intuitive.
> does on-demand capacity allocation. The measurement process observes 
> the measurement stream at ingress and egress. One might be tempted to 
> active methods (where you mention background load traffic explicitly) 
> it might be appropriate to discuss this special case for passive methods, too.
> 
> understand, including possible typos. Should "basis of reference 
> events as packet pass reference point" read "basis of reference events 
> that are generated as packet_s_ pass reference points"? Rephrasing can help here.
> 
> clear to me from the definition in 3.8. I believe that the definition 
> of "hybrid" {sh|c}ould be sharpened to delimit "hybrid" more 
> accurately from active and passive.
> 
> markings, addition of header fields or changes in header field values 
> in intermediate nodes. However, to make the measurement hybrid, these 
> changes must be a _consequence_ or _result_ of actions undertaken by 
> the (otherwise passive) _measurement_ process.
> a) Active: whenever the measurement process generates a dedicated 
> stream of measurement packets, where packets are identifiable either 
> by dedicated measurement fields (either in payload or header), and/or 
> by (possibly aggregated, i.e., set of) field values, the method/metric 
> can be categorized as active
> b) Passive: whenever the measurement process observes an existing 
> stream of packets without changing/adding/removing any packet fields 
> or field values. The passive monitoring _must_not_ add/change/remove 
> header fields or header field values. Although passive monitoring 
> might bias the timing of the observed traffic to some extent (be it by 
> setting interfaces into promiscous mode or by inserting splitters into 
> the path) it does not do this _intentionally_. Open question: into 
> which category does the generation of background load for passive measurements fit?
> field values in (intermediate) nodes as part of the measurement (may 
> be header or payload). Obviously, IPv4 header updates that result from 
> This statement imho conflicts with the main findings of RFC7312. 
> Today's networks store flow/stream state at layers below IP, so 
> networks have a "historic view". I doubt that this bias can be ignored 
> - infact the bias of past periods is visible during the current 
> measurement period. A mention of possible consequences in stateful 
> networks with reference to
> (don't know how this can be done easily, maybe split/break 
> descriptions of reference points onto several lines): y axis label: 
> "Measurement stream capacity", x axis label: "Stream characteristics known".
> several cases when the bias onto measurements is substantial - 
> anything between a) "packets become too large when adding the PDM 
> header and results in <IPv6-fragementation-required> to the sending 
> host", b) "Size increase with PDM header makes stream to exceed a 
> network threshold and trigger channel capacity re-allocation" and c) 
> "subsequent nodes on the path drop these packets because of the measurement node modifications".
> minimum bias but it's quite difficult to estimate the consequences 
> onto measurement results. If this _intention_ is key, then I'm fine 
> with the wording. Otherwise one could think about a possible rephrase.
> 
> will end Wednesday 21 October 2015. Please send any comments 
> (including "I've read it and it's good" :) ) to the [email-masked]

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 21 Oct 2015 17:37:17 +0000

Hi Joachim,
what a great analysis! I think that you have made definition of Hybrid measurement methods clear and unambiguous. The foresight of that paragraph from RFC 2330 is unbelievable as of Back to the Future (the Future IS today!). I agree and support your proposal to use it in definition of the Hybrid measurement methods. Frankly, I couldn't get my head around of a method that is passive and active at the same time. But I can see that a method may be active or passive in its instantiations as a measurement task depending on its effect on the measured flow and the network.

	Regards,
		Greg

-----Original Message-----
From: Joachim Fabini [mailto:[email-masked]] 
Sent: Wednesday, October 21, 2015 12:20 AM
To: Gregory Mirsky; MORTON, ALFRED C (AL); Greg Mirsky
Cc: [email-masked]
Subject: Re: [ippm] WGLC on draft-ietf-ippm-active-passive-01

Hi Greg, all,

Joachim

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 21 Oct 2015 22:20:11 -0400

Hi Joachim, Greg, and all,

The definitions and A-H-P categorization we've constructed
(and applied unambiguously to many different example methods now)
are dependent on aspects of the methods alone, and independent of
the networks to be tested or how those networks treat packets.
In the Cap-I Internet we cannot make many assertions about
packet treatment, and the Internet is the focus of IPPM's charter
(first sentence).

So, I believe this is a defendable statement:

Ref from 2330:
"A closely related note: it would be very useful to know if a
given Internet component treats equally a class C of different
types of packets. If so, then any one of those types of packets
can be used for subsequent measurement of the component.
This suggests we devise a metric or suite of metrics that attempt
to determine C."

Referencing this definition:
Hybrid methods of measurement that mark packets of a class C in intermediate
nodes should produce equivalent results to passive methods of measurement,
when all hosts accessing these packets along the path
(between and including sender and receiver)
treat packets from both categories of methods (with and without the marking)
as the same class C. The passive methods of measurement represent the
Ground Truth for comparisons of results between passive and hybrid methods,
and this comparison should be conducted to confirm the class C treatment.

Hope this works for everyone,
Al

> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Wednesday, October 21, 2015 1:37 PM
> To: Joachim Fabini; MORTON, ALFRED C (AL); Greg Mirsky
> Cc: [email-masked]
> Subject: RE: [ippm] WGLC on draft-ietf-ippm-active-passive-01
>
> Hi Joachim,
> what a great analysis! I think that you have made definition of Hybrid
> measurement methods clear and unambiguous. The foresight of that
> paragraph from RFC 2330 is unbelievable as of Back to the Future (the
> Future IS today!). I agree and support your proposal to use it in
> definition of the Hybrid measurement methods. Frankly, I couldn't get my
> head around of a method that is passive and active at the same time. But
> I can see that a method may be active or passive in its instantiations
> as a measurement task depending on its effect on the measured flow and
> the network.
>
>       Regards,
>               Greg
>
> packets. If so, then any one of those types of packets can be used for
> subsequent measurement of the component. This suggests we devise a
> metric or suite of metrics that attempt to determine C."
>

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 22 Oct 2015 02:27:51 +0000

Hi Al,
may I propose minor update to the proposed text:
s/with and without the marking/with and without any type of modification/

	Regards,
		Greg

-----Original Message-----
From: MORTON, ALFRED C (AL) [mailto:[email-masked]] 
Sent: Wednesday, October 21, 2015 7:20 PM
To: Gregory Mirsky; Joachim Fabini; Greg Mirsky
Cc: [email-masked]
Subject: RE: [ippm] WGLC on draft-ietf-ippm-active-passive-01

The definitions and A-H-P categorization we've constructed (and applied unambiguously to many different example methods now) are dependent on aspects of the methods alone, and independent of the networks to be tested or how those networks treat packets.
In the Cap-I Internet we cannot make many assertions about packet treatment, and the Internet is the focus of IPPM's charter (first sentence).

Ref from 2330:
"A closely related note: it would be very useful to know if a given Internet component treats equally a class C of different types of packets. If so, then any one of those types of packets can be used for subsequent measurement of the component.
This suggests we devise a metric or suite of metrics that attempt to determine C."

Referencing this definition:
Hybrid methods of measurement that mark packets of a class C in intermediate nodes should produce equivalent results to passive methods of measurement, when all hosts accessing these packets along the path (between and including sender and receiver) treat packets from both categories of methods (with and without the marking) as the same class C. The passive methods of measurement represent the Ground Truth for comparisons of results between passive and hybrid methods, and this comparison should be conducted to confirm the class C treatment.

> definition of the Hybrid measurement methods. Frankly, I couldn't get 
> my head around of a method that is passive and active at the same 
> time. But I can see that a method may be active or passive in its 
> instantiations as a measurement task depending on its effect on the 
> measured flow and the network.
>
>       Regards,
>               Greg
>
> perspectives to approach this issue - but I see all of them ending up 
> in categorizing value changes as hybrid. Below my reasoning:
>
> One key observation is that networks do no longer behave like 
> stateless copper wires as we used to abstract them. Many networks and 
> components store internal state and per-session or per-flow information.
> defaultDelay + packetSize/linkCapacity). So there is no doubt that 
> this is a hybrid case, right?
>
> case I see, indeed, an overlapping of hybrid and passive - in the 
> sense that the method is hybrid _and_ might be categorized as passive, 
> too, when the white-box analysis indicates that marking (in terms of 
> value
> Still, my absolute preference is to address the most general case. 
> Which means, that any packet modification by _measurement_ processes_ 
> in intermediate nodes - this includes both, a) addition/deletion of 
> fields or b) modification of _values_, labels this measurement method 
> to belong to the hybrid category.
>
> identify a packet in subsequent intermediate nodes and has no 
> knowledge of (b). Now assume that the hybrid measurement process (b) 
> marks some packets (changes values, adds fields). This will 
> potentially screw up (a)'s ability to identify packets.
>
> changing packet header values in intermediate nodes modifies the 
> Type-P of the packet. Your measurement process might use a superset of 
> Type-P (that ignores the marking) to categorize packets, other 
> components might use subsets (that do _not_ ignore the marking). In 
> the general case and for black-box paths, a measurement process can 
> not predict the consequences of markings in intermediate nodes onto 
> the Type-P treatment of all potential links and components along the path.
>
> Just recently I found a surprisingly future-proof paragraph in RFC 
> 2330 (RFC 2330, page 30, second paragraph):
>
> Summarizing, my position is that whenever a measurement process 
> changes packet header values in intermediate nodes this categorizes 
> the process as hybrid.
>
> Joachim
>
>
> > cases when the Optional header is already part of the packet and 
> > when the header must be added in order to support the PDM. In the 
> > first case I don’t see that PDM alters processing on the packet by 
> > the network while in the second there’s clear impact as the packet 
> > size
> must be increased.
> >
> > passive or hybrid must be based on its impact on the otherwise 
> > normal network behavior. If the method alters the network behavior 
> > or treatment of the data, then it is active measurement method. If 
> > the method does not change network behavior in any aspect, then it 
> > is passive. Why I believe that is important? Because from this 
> > point, marking method that does not affect treatment of the flow by 
> > the network is passive, not active measurement method since marked 
> > and unmarked packets are indistinguishable to the network except for 
> > would change how marked packets being processed comparing to 
> > unmarked,
> > I've read it and it's good... ;) The active-passive-hybrid 
> > definition and categorization helps enormously and should have been 
> > started years ago - many thanks to Al for taking the initiative. I 
> > consider this work to be relevant also for the scientific community. 
> > In particular the term hybrid is used with many diverging meanings 
> > (commonly as a buzzword when applying for new project funding), so I 
> > spent some time on reviewing and reasoning about. Disclaimer: I've 
> > not been involved into earlier discussions on this draft and it's 
> > the first time I read it. Consider it to be an unbiased first-time-reader opinion.
> >
> > Sec. 3.4 (1) s/"a packet stream..."/"Additional packet streams..."/ 
> > to be more generic? Any stream can be an aggregate of other streams, 
> > but the second variant seems to be more accurate and flexible 
> > (thinking of several streams with distinct sources and destinations 
> > for impairing distinct sub-paths of the measurement path).
> >
> > Sec. 3.4 (2) "The packets in the stream(s) of interest have fields 
> > (or are augmented or modified to include fields) which are dedicated 
> > to measurements"
> > Proposed (relaxing) addition: Instead of dedicated measurement 
> > fields an aggregated set of packet header _values_ can be sufficient 
> > to identify packets as being part of the active measurement stream.
> > Considering the hypothetical case of UDP BTC measurements, the 
> > traffic is actively generated, so the method is active. But packets 
> > are not marked, nor are there any specific fields like sequence 
> > numbers that can be used to identify packets. And for a UDP BTC 
> > metric there is no need for such. One could argue that packets of a 
> > UDP measurement stream can be identified by SRC/DST IP addresses and 
> > port numbers, which is why these fields are dedicated to measurement 
> > - but that's
> not intuitive.
> > Sec. 3.4: not sure: does it make sense to mention in a note  
> > possible changes of packet type (Type-P) along the measurement path (e.g.
> > feeling is that it can help to raise reader's awareness in this 
> > draft, too. Type-P at the source does not necessarily mean same 
> > Type-P at the destination (same observation is valid for passively 
> > observing intermediate nodes)
> >
> > load? Consider the case of passive monitoring of a cellular link 
> > that does on-demand capacity allocation. The measurement process 
> > observes the measurement stream at ingress and egress. One might be 
> > tempted to generated some background load that triggers allocation 
> > of additional capacity on the link. Where does this method fit into: 
> > passive or hybrid? I'm not sure. As a matter of consistency with the 
> > section on active methods (where you mention background load traffic 
> > explicitly) it might be appropriate to discuss this special case for 
> > passive
> methods, too.
> >
> > events as packet pass reference point" read "basis of reference 
> > events that are generated as packet_s_ pass reference points"? 
> > Rephrasing can
> help here.
> >
> > clear to me from the definition in 3.8. I believe that the 
> > definition of "hybrid" {sh|c}ould be sharpened to delimit "hybrid" 
> > more accurately from active and passive.
> >
> > - is the one where passive measurements are combined with additions 
> > of fields or changes of field values in intermediate
> > markings, addition of header fields or changes in header field 
> > values in intermediate nodes. However, to make the measurement 
> > hybrid, these changes must be a _consequence_ or _result_ of actions 
> > undertaken by the (otherwise passive) _measurement_ process.
> > by dedicated measurement fields (either in payload or header), 
> > and/or by (possibly aggregated, i.e., set of) field values, the 
> > method/metric can be categorized as active
> > might bias the timing of the observed traffic to some extent (be it 
> > by setting interfaces into promiscous mode or by inserting splitters 
> > into the path) it does not do this _intentionally_. Open question: 
> > into which category does the generation of background load for 
> > passive
> measurements fit?
> > c) Hybrid: the measurement acts exclusively on existing traffic, 
> > that is, anything that is categorized as passive (b). However, the 
> > be header or payload). Obviously, IPv4 header updates that result 
> > from forwarding rules (checksum, TTL) are NOT part of the 
> > measurement process. Question: does "passive + background load" fit into hybrid?
> >
> > Sec. 4: "To keep simple, we consider the stream effect only when it 
> > is present".
> > Sec. 4: ASCII diagram: it might improve readability to add axis 
> > labels (don't know how this can be done easily, maybe split/break 
> > Sec. 4.1., 4.2: I fully agree with the categorization. However, is 
> > find several cases when the bias onto measurements is substantial - 
> > All of these actions should result in substantial bias of 
> > measurement results. And even the change of field values could 
> > result in intermediate nodes to apply distinct forwarding policies 
> > to the
> packets.
> >
> > Summarizing: I consider this draft and its definitions to be 
> > essential for the work and discussions of IPPM and related working 
> > groups. It tackles the definitions it is supposed to and treats them 
> > in adequate depth. As a first-time reader I had the impression that 
> > some few sentences and clarifications can substantially improve the

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 22 Oct 2015 07:26:07 -0400

Sure Greg.  Joachim, any comment?

> Sent: Wednesday, October 21, 2015 10:28 PM
> To: MORTON, ALFRED C (AL); Joachim Fabini; Greg Mirsky
> Cc: [email-masked]
> The definitions and A-H-P categorization we've constructed (and applied
> unambiguously to many different example methods now) are dependent on
> aspects of the methods alone, and independent of the networks to be
> tested or how those networks treat packets.
> In the Cap-I Internet we cannot make many assertions about packet
> treatment, and the Internet is the focus of IPPM's charter (first
> sentence).
>
> subsequent measurement of the component.
> Hybrid methods of measurement that mark packets of a class C in
> intermediate nodes should produce equivalent results to passive methods
> of measurement, when all hosts accessing these packets along the path
> (between and including sender and receiver) treat packets from both
> categories of methods (with and without the marking) as the same class
> C. The passive methods of measurement represent the Ground Truth for
> comparisons of results between passive and hybrid methods, and this
> comparison should be conducted to confirm the class C treatment.
>

---

From: Joachim Fabini <[email-masked]>
Date: Thu, 22 Oct 2015 15:13:40 +0200

Hi Al,

excellent analysis and wording (as always, thanks :). I also support
Greg's proposal (when using "mark" and "marking" this would narrow the
scope - modifying is more general). Overall I'm perfectly fine with
these changes.

What's still open is Mike's comment. I'll reply to his email separately,
perhaps this one triggers yet another fine-tuning of the wording. In
particular the term "intermediate nodes" might be confusing and some
minor changes can help here.

thanks,
Joachim

---

From: Joachim Fabini <[email-masked]>
Date: Thu, 22 Oct 2015 16:06:33 +0200

Hi Mike,

Some arguments that I'd like to share (just thinking loudly). If I
understood your email correctly, main argument is that PDM is passive
because it appends the DO measurement header in the sending host and not
in intermediate hosts. Right?

To me this method still appears as hybrid because of two reasons:
a) the sending application is not aware of the monitoring and
b) at least one node along the path (in this case the sending host's
stack) triggers addition/deletion/modification of headers
_on_behalf_of_the_measurement_process_ as part of the measurement
method. Imho there is no need for an intermediate node (this might
require some fine-tuning in the draft text).

It's about measurement intent and roles, measurement methods may involve
distributed actors (like sender, receiver, intermediate nodes).
So, more specific: whenever the (potentially distributed) _measurement_
process/method inserts fields into (or modifies values of) passively
observed packets anywhere along the path, then this method is no longer
passive but hybrid.

If this constraint is not met, measurement header
additions/modifications could easily be shifted to another host upstream
in the path and state: "the modification is not co-located with (or
caused by) my observing instance" whenever I want my measurement method
to be labeled as "passive" instead of "hybrid".

The measurement intent is essential, as otherwise completely unrelated
packet modifications in intermediate nodes along the path could be
mis-interpreted to label the measurement as hybrid.

So I'd isolate the following (additional?) observations for passive
measurements to become hybrid:
a) measurement-"intent" must be present as the reason for adding fields
to or modifying values of observed packets along the path.
b) the instance that modifies packets (cf. (a)) need not (but may) be
co-located with passively observing measurement instances.
c) (not sure about this one): at least one observing instance of the
measurement process must be able to observe/read the modifications.

Al, what do you think? Is this covered by the current text or does it
require some addition?

thanks Mike for pointing out this issue,
Joachim

---

From: "Ackermann, Michael" <[email-masked]>
Date: Thu, 22 Oct 2015 14:19:52 +0000

Thanks Joachim

And let me echo your sentiments of the great work, wording,  analysis and comments from everyone in this recent dialogue.    THANKS TO ALL!     I am learning a lot and I feel like we are getting close to resolution.  
 Like Joachim, I like Greg's "Mark and Marking"  additions to Al's  great wording on this.     I would also like to suggest we include definitions of what Mark and Marking mean and what nodes can do this.   

And similarly it might make sense to define what an "Intermediate Node" is.     To me it is any node which sees the packet of a 5 Tuple, but is NOT one of the end point hosts.     Where this can get confusing, is when tunnels or proxies are involved, but it is a reality we need to deal with.  

Thanks again for the great work!  

Mike

-----Original Message-----
From: ippm [mailto:[email-masked]] On Behalf Of Joachim Fabini
Sent: Thursday, October 22, 2015 9:14 AM
To: MORTON, ALFRED C (AL) <[email-masked]>; Gregory Mirsky <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: [email-masked]
Subject: Re: [ippm] WGLC on draft-ietf-ippm-active-passive-01

Hi Al,

excellent analysis and wording (as always, thanks :). I also support Greg's proposal (when using "mark" and "marking" this would narrow the scope - modifying is more general). Overall I'm perfectly fine with these changes.

What's still open is Mike's comment. I'll reply to his email separately, perhaps this one triggers yet another fine-tuning of the wording. In particular the term "intermediate nodes" might be confusing and some minor changes can help here.

thanks,
Joachim

On 22.10.2015 13:26, MORTON, ALFRED C (AL) wrote:
>> The definitions and A-H-P categorization we've constructed (and 
>> applied unambiguously to many different example methods now) are 
>> dependent on aspects of the methods alone, and independent of the 
>> networks to be tested or how those networks treat packets.
>> for subsequent measurement of the component.
>> intermediate nodes should produce equivalent results to passive 
>> methods of measurement, when all hosts accessing these packets along 
>> the path (between and including sender and receiver) treat packets 
>> from both categories of methods (with and without the marking) as the 
>> same class C. The passive methods of measurement represent the Ground 
>> Truth for comparisons of results between passive and hybrid methods, 
>>> what a great analysis! I think that you have made definition of 
>>> Hybrid measurement methods clear and unambiguous. The foresight of 
>>> that paragraph from RFC 2330 is unbelievable as of Back to the 
>>> Future (the Future IS today!). I agree and support your proposal to 
>>> use it in definition of the Hybrid measurement methods. Frankly, I 
>>> couldn't get my head around of a method that is passive and active 
>>> at the same time. But I can see that a method may be active or 
>>> passive in its instantiations as a measurement task depending on its 
>>> effect on the measured flow and the network.
>>>
>>>       Regards,
>>>               Greg
>>>
>>> perspectives to approach this issue - but I see all of them ending 
>>> up in categorizing value changes as hybrid. Below my reasoning:
>>>
>>> stateless copper wires as we used to abstract them. Many networks 
>>> and components store internal state and per-session or per-flow
>> information.
>>> There is no way and no rule to predict the consequences of changing 
>>> a single bit in packet payload or packet headers along an unknown path.
>>>
>>> But there is no way to infer the consequence of marking packets 
>>> (i.e., changing values of header fields beyond the basics required 
>>> for IPv4 routing, meaning TTL and Checksum for IPv4) in the general case.
>>> My position is that this draft _must_ tackle the _most_general_ 
>>> worst case. That is, value changes (potentially) modify the way an 
>>> unknown path treats these packets.
>>> I agree that in particular scenarios (white-box measurements) the 
>>> path and behavior of all of its links and systems might be known. In 
>>> such a case I see, indeed, an overlapping of hybrid and passive - in 
>>> the sense that the method is hybrid _and_ might be categorized as 
>>> passive, too, when the white-box analysis indicates that marking (in 
>>> terms of value
>>> Which means, that any packet modification by _measurement_ 
>>> processes_ in intermediate nodes - this includes both, a) 
>>> addition/deletion of fields or b) modification of _values_, labels 
>>> this measurement method to belong to the hybrid category.
>>>
>>> measurements of packets ongoing along the same path. Some of them 
>>> (a) strictly passive, observing, some of them (b) hybrid. The 
>>> passive measurement (a) relies on specific packet checksums or 
>>> hashes to identify a packet in subsequent intermediate nodes and has 
>>> no knowledge of (b). Now assume that the hybrid measurement process 
>>> (b) marks some packets (changes values, adds fields). This will 
>>> Type-P of the packet. Your measurement process might use a superset 
>>> of Type-P (that ignores the marking) to categorize packets, other 
>>>> and unmarked packets are indistinguishable to the network except 
>>>> for observer(s). But it the marking method applied in the manner 
>>>> that would change how marked packets being processed comparing to 
>>>> unmarked,
>>>> (commonly as a buzzword when applying for new project funding), so 
>>>> I spent some time on reviewing and reasoning about. Disclaimer: 
>>>> I've not been involved into earlier discussions on this draft and 
>>>> it's the first time I read it. Consider it to be an unbiased 
>>>> first-time-
>> reader opinion.
>>>>
>>>> to be more generic? Any stream can be an aggregate of other 
>>>> streams, but the second variant seems to be more accurate and 
>>>> flexible (thinking of several streams with distinct sources and 
>>>> destinations for impairing distinct sub-paths of the measurement path).
>>>>
>>>> (or are augmented or modified to include fields) which are 
>>>> dedicated to measurements"
>>>> fields an aggregated set of packet header _values_ can be 
>>>> sufficient to identify packets as being part of the active measurement stream.
>>>> UDP measurement stream can be identified by SRC/DST IP addresses 
>>>> and port numbers, which is why these fields are dedicated to 
>>>> measurement
>>>> - but that's
>>> not intuitive.
>>>> "fields or field values". The key is that these specific 
>>>> measurement stream packets are selected/evaluated/measured in at 
>>>> least one measurement location. Possibly nitpicking?
>>>>
>>>> passive or hybrid? I'm not sure. As a matter of consistency with 
>>>> the section on active methods (where you mention background load 
>>>> traffic
>>>> explicitly) it might be appropriate to discuss this special case 
>>>> for passive
>>> methods, too.
>>>>
>>>> hybrid, these changes must be a _consequence_ or _result_ of 
>>>> actions undertaken by the (otherwise passive) _measurement_ process.
>>>> stream of measurement packets, where packets are identifiable 
>>>> either by dedicated measurement fields (either in payload or 
>>>> header), and/or by (possibly aggregated, i.e., set of) field 
>>>> values, the method/metric can be categorized as active
>>>> stream of packets without changing/adding/removing any packet 
>>>> fields or field values. The passive monitoring _must_not_ 
>>>> add/change/remove header fields or header field values. Although 
>>>> passive monitoring might bias the timing of the observed traffic to 
>>>> some extent (be it by setting interfaces into promiscous mode or by 
>>>> inserting splitters into the path) it does not do this _intentionally_. Open question:
>>>> field values in (intermediate) nodes as part of the measurement 
>>>> (may be header or payload). Obviously, IPv4 header updates that 
>>>> result from forwarding rules (checksum, TTL) are NOT part of the 
>>>> "Measurement stream capacity", x axis label: "Stream 
>>>> characteristics
>>> known".
>>>> the "small effect" essential for these examples/statement? One 
>>>> could find several cases when the bias onto measurements is 
>>>> substantial - anything between a) "packets become too large when 
>>>> adding the PDM header and results in <IPv6-fragementation-required> 
>>>> to the sending host", b) "Size increase with PDM header makes 
>>>> stream to exceed a network threshold and trigger channel capacity 
>>>> re-allocation" and c) "subsequent nodes on the path drop these 
>>>> packets because of the
>>> measurement node modifications".
>>>> groups. It tackles the definitions it is supposed to and treats 
>>>> them in adequate depth. As a first-time reader I had the impression 
>>>> that some few sentences and clarifications can substantially 
>>>> improve the categorization and delimiting of active/passive/hybrid 
>>>> methods in
>> sec.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 22 Oct 2015 15:06:37 -0400

Hi Mike, Joachim, and Greg,
(I didn't mean to overlook your comment, Mike, but to
work toward agreement one step at a time.)

I think I'm with Joachim on the subject of intent.
Joachim wrote:
> packet modifications in intermediate nodes along the path could be mis-
> interpreted to label the measurement as hybrid.
[ACM]
and with the title,
"IPv6 Option Header for Performance and Diagnostic Measurements",
I think we've established intent, even if this DOH is added to every
possible stream, partly because of reasons Joachim cited earlier
(it’s a bigger packet with DOH == implications).

> Al, what do you think? Is this covered by the current text or does it

[ACM]
I think we have a) and b) covered, when we say that:
"The packets in the stream of interest have fields or field values
(or are augmented or modified to include fields or field values)
which are dedicated to measurement."

I don't think that c) adds a significant criterion (as you suspected).

Joachim also indicated there might be a need to qualify Intermediate Nodes.
Mike and Greg were also concerned with use of the term "mark", so I think we need
to substitute terms from the method criteria: "augmented or modified".

We can again draw on RFC 2330 to help us with Path terminology:
https://tools.ietf.org/html/rfc2330#section-5

Referencing the RFC 2330 Section 13 notion of "class C" and
the RFC 2330 Section 5 terminology for paths:

Hybrid methods of measurement that augment or modify packets of a class C in
a host should produce equivalent results to passive methods of measurement,
when hosts accessing these packets along the path
(other than those performing augmentation/modification)
treat packets from both categories of methods
(with and without the augmentation/modification) as the same class C.
The passive methods of measurement represent the
Ground Truth for comparisons of results between passive and hybrid methods,
and this comparison should be conducted to confirm the class C treatment.

hope that does it,
Al

> Sent: Thursday, October 22, 2015 10:07 AM
> To: Ackermann, Michael; Gregory Mirsky; MORTON, ALFRED C (AL); Greg
> Mirsky
> Cc: [email-masked]
> packet modifications in intermediate nodes along the path could be mis-
> interpreted to label the measurement as hybrid.
>
> thanks Mike for pointing out this issue, Joachim
>
>
> > Great comments and the great  Active/Passive/Hybrid debate (that we
> have avoided having  for a couple years),   may finally be in the home
> stretch to resolution?
> >
> > We may not be able to conclude this over Email.  A live integrative
> conversion would be great, but may take hours?   We may want to
> provisionally plan on a BOF or after hours session for all who have
> interest or comments?
> >
> > Methods like PDM and most Extension Headers should not be altered or
> even read by intermediate nodes.   PDM uses DOH for this reason.    We
> can site exceptions such as HOP by HOP EH's,  but PDM is exclusively
> DOH.    I guess that makes PDM "Usually"  Passive?     I say "Usually"
> because our intent is that PDM could be on all the time, OR,  PDM could
> be used as an exceptional debugging tool.   From what I understand right
> now,  the latter sense I would consider Hybrid.
> >
> > So, since I cannot totally ignore the global IPV6 EH debate,  I will
> add that it is conceivable that the presence of a DOH,  for PDM or any
> other purpose,  COULD elongate a packet to the point that an
> intermediate node is forced to process the packet in software, rather
> than hardware,  and that would alter network performance.
> >
> > I agree with Joachim that we need to consider that networks are
> getting more complex and that trend will continue.  This makes our
> Active/Passive/Hybrid debate more difficult,  but it also shows how
> important it is to understand and get right.
> >
> > I would also agree that any alterations made by an intermediate node
> should cause that method to be considered Hybrid.
> >
> > To: Gregory Mirsky <[email-masked]>; MORTON, ALFRED C
> > (AL) <[email-masked]>; Greg Mirsky <[email-masked]>
> > Cc: [email-masked]
> Which means, that any packet modification by _measurement_ processes_ in
> > changing packet header values in intermediate nodes modifies the Type-
> P of the packet. Your measurement process might use a superset of Type-P
> changes packet header values in intermediate nodes this categorizes the
> process as hybrid.
> >
> > Joachim
> >
> >
> >> and categorization helps enormously and should have been started
> >> years ago - many thanks to Al for taking the initiative. I consider
> >> this work to be relevant also for the scientific community. In
> >> particular the term hybrid is used with many diverging meanings
> >> not been involved into earlier discussions on this draft and it's the
> >> first time I read it. Consider it to be an unbiased first-time-reader
> opinion.
> >>
> - but that's not intuitive.
> Rephrasing can help here.
> >>
> >> by (possibly aggregated, i.e., set of) field values, the
> passive measurements fit?
> >> from forwarding rules (checksum, TTL) are NOT part of the measurement
> > The information contained in this communication is highly confidential
> and is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you
> are hereby notified that any viewing, copying, disclosure or
> distribution of this information is prohibited. Please notify the
> sender, by electronic mail or telephone, of any unintended receipt and
> delete the original message without making any copies.
> >
> >  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan
> are nonprofit corporations and independent licensees of the Blue Cross
> and Blue Shield Association.
> >
> >

---

From: Joachim Fabini <[email-masked]>
Date: Fri, 23 Oct 2015 09:00:10 +0200

Hi Al,

agreed, one (final) minor tweak proposal below:

On 22.10.2015 21:06, MORTON, ALFRED C (AL) wrote:
> [...]

Proposed change in this phrase:
s/hosts accessing/hosts accessing and links transporting/
(where a better wording for "transporting" is highly welcome).

Including the links here is imho essential. One (admittedly strange)
example why we need this is Fig. 6a of
https://irtf.org/raim-2015-papers/raim-2015-paper18.pdf . Measurement
results are from a live network (384K DCH UMTS uplink).
A minimum _increase_ in packet size results in a systematic, substantial
_decrease_ of e2e packet delay.
Focusing on the delay block centered at 400 bytes payload and the
subsequent one it is visible that the limit is sharp: at one specific
payload size, one additional byte systematically decreases the e2e delay
by median 20ms of 75ms. So "passive" means for me, that we must exclude
the case of measurement augmentation triggering such strange _link_
behavior, too.

> hope that does it,

Yes, I hope that we're finally done. At least for me the picture of what
is hybrid and why we need this category has become much more clearer
during our discussion. Thanks again to all for your support and patience.
Joachim

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 23 Oct 2015 08:01:50 -0400

Thanks Joachim,
s/hosts accessing/hosts accessing and links transporting/
works for me, and thanks for providing a relevant example.

We seem to be winding-up this discussion,
Al

> Sent: Friday, October 23, 2015 3:00 AM
> To: MORTON, ALFRED C (AL); Ackermann, Michael; Gregory Mirsky; Greg
> Mirsky
> Cc: [email-masked]
> > Mike and Greg were also concerned with use of the term "mark", so I
> > think we need to substitute terms from the method criteria: "augmented
> or modified".
> >
> > Referencing the RFC 2330 Section 13 notion of "class C" and the RFC
> > 2330 Section 5 terminology for paths:
> >
> > Hybrid methods of measurement that augment or modify packets of a
> > class C in a host should produce equivalent results to passive methods
> > of measurement, when hosts accessing these packets along the path
> > (other than those performing augmentation/modification) treat packets
> > from both categories of methods (with and without the
> > augmentation/modification) as the same class C.
> > The passive methods of measurement represent the Ground Truth for
> s/hosts accessing/hosts accessing and links transporting/ (where a
> better wording for "transporting" is highly welcome).
>
> example why we need this is Fig. 6a of https://irtf.org/raim-2015-
> papers/raim-2015-paper18.pdf . Measurement results are from a live
> network (384K DCH UMTS uplink).
> >> because it appends the DO measurement header in the sending host and
> >> not in intermediate hosts. Right?
> >>
> >> It's about measurement intent and roles, measurement methods may
> >> involve distributed actors (like sender, receiver, intermediate
> nodes).
> >> So, more specific: whenever the (potentially distributed)
> >> _measurement_ process/method inserts fields into (or modifies values
> >> of) passively observed packets anywhere along the path, then this
> >> method is no longer passive but hybrid.
> >>
> >> additions/modifications could easily be shifted to another host
> >> upstream in the path and state: "the modification is not co-located
> >> with (or caused by) my observing instance" whenever I want my
> >> measurement method to be labeled as "passive" instead of "hybrid".
> >>
> >> The measurement intent is essential, as otherwise completely
> >> unrelated packet modifications in intermediate nodes along the path
> >> could be mis- interpreted to label the measurement as hybrid.
> >>
> >> a) measurement-"intent" must be present as the reason for adding
> >> fields to or modifying values of observed packets along the path.
> >> add that it is conceivable that the presence of a DOH,  for PDM or
> >> any other purpose,  COULD elongate a packet to the point that an
> >>> a
> >>> (i.e.,
> >>> worst
> >>> Type-
> >> P of the packet. Your measurement process might use a superset of
> >>>> consider this work to be relevant also for the scientific
> >>>> community. In particular the term hybrid is used with many
> >>>> diverging meanings (commonly as a buzzword when applying for new
> >>>> project funding), so I spent some time on reviewing and reasoning
> >>>> about. Disclaimer: I've not been involved into earlier discussions
> >>>> on this draft and it's the first time I read it. Consider it to be
> >>>> an unbiased first-time-reader
> >> opinion.
> >>>>
> >>>> of additional capacity on the link. Where does this method fit
> >>>> into: passive or hybrid? I'm not sure. As a matter of consistency
> >>>> with the section on active methods (where you mention background
> >>>> load traffic explicitly) it might be appropriate to discuss this
> >>>> special case for passive
> >> methods, too.
> >>>>
> >> sender, by electronic mail or telephone, of any unintended receipt
> >> and delete the original message without making any copies.
> >>>
> >> are nonprofit corporations and independent licensees of the Blue
> >> Cross and Blue Shield Association.
> >>>
> >>>
> >
> >

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 23 Oct 2015 15:17:58 +0000

I also like the additional of LINKS TRANSPORTING to the document.   An Intermediate Node may not be a host and may not even be reading the whole packet, but just the forwarding process COULD be affected.   (Hopefully not).  

Also echoing the thanks for this great dialogue over Email,  which has helped me start to formulate in my mind what Hybrid is and even some potential examples.    Great work guys!

THanks

Mike

-----Original Message-----
From: Joachim Fabini [mailto:[email-masked]] 
Sent: Friday, October 23, 2015 3:00 AM
To: MORTON, ALFRED C (AL) <[email-masked]>; Ackermann, Michael <[email-masked]>; Gregory Mirsky <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: [email-masked]
Subject: Re: [ippm] WGLC on draft-ietf-ippm-active-passive-01

Hi Al,

On 22.10.2015 21:06, MORTON, ALFRED C (AL) wrote:
> think we need to substitute terms from the method criteria: "augmented or modified".
> 

Proposed change in this phrase:
s/hosts accessing/hosts accessing and links transporting/ (where a better wording for "transporting" is highly welcome).

Including the links here is imho essential. One (admittedly strange) example why we need this is Fig. 6a of https://irtf.org/raim-2015-papers/raim-2015-paper18.pdf . Measurement results are from a live network (384K DCH UMTS uplink).
A minimum _increase_ in packet size results in a systematic, substantial _decrease_ of e2e packet delay.
Focusing on the delay block centered at 400 bytes payload and the subsequent one it is visible that the limit is sharp: at one specific payload size, one additional byte systematically decreases the e2e delay by median 20ms of 75ms. So "passive" means for me, that we must exclude the case of measurement augmentation triggering such strange _link_ behavior, too.

> hope that does it,

Yes, I hope that we're finally done. At least for me the picture of what is hybrid and why we need this category has become much more clearer during our discussion. Thanks again to all for your support and patience.
Joachim

>> involve distributed actors (like sender, receiver, intermediate nodes).

---

From: "Ackermann, Michael" <[email-masked]>
Date: Wed, 21 Oct 2015 00:13:14 +0000

Good answer Greg.

I too struggle with the Hybrid concept and method and most of all examples.
Our concept of PDM is that the operator could choose to run PDM all the time, in which case there would be no change or effect on the network traffic,  hence Passive.       The operator could alternately choose to turn PDM on an exception basis.  In that case the DO Extension Header would be additional bytes during the exception time and could hence be considered Active.
This would make PDM a Hybrid methodology, depending upon how you choose to use it?

Does that make sense?     If so THANKS!   Because it would be the first Hybrid example I can get my arms around!  ☺

Mike

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Tuesday, October 20, 2015 7:56 PM
To: Ackermann, Michael <[email-masked]>; Greg Mirsky <[email-masked]>; Joachim Fabini <[email-masked]>
Cc: [email-masked]
Subject: RE: [ippm] WGLC on draft-ietf-ippm-active-passive-01

Hi Mike,

                Regards,
                                Greg

Thanks Greg!

Thanks again!

Mike

Hi Joachim, et. al,

Regards,
Greg

regards
Joachim