Re: [ippm] Alissa Cooper's Discuss on draft-ietf-ippm-2679-bis-04: (with DISCUSS and COMMENT)

["MORTON, ALFRED C (AL)" <[e-mail]>]

Hi Alissa,
Thanks for your review, replies below.
Al

> -----Original Message-----
> From: ippm [mailto:[e-mail]] On Behalf Of Alissa Cooper
...
> Subject: [ippm] Alissa Cooper's Discuss on draft-ietf-ippm-2679-bis-04:
> (with DISCUSS and COMMENT)
> 
> Alissa Cooper has entered the following ballot position for
> draft-ietf-ippm-2679-bis-04: Discuss
> 
...
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I am confused about the last sentence in this methodology step in
> Section
> 3.6:
> 
> "+ At the Src host, select Src and Dst IP addresses, and form a test
>    packet of Type-P with these addresses.  Any 'padding' portion of the
>    packet needed only to make the test packet a given size should be
>    filled with randomized bits to avoid a situation in which the
>    measured delay is lower than it would otherwise be due to compression
>    techniques along the path.  Note that use of transport layer
>    encryption will counteract the deployment of network-based analysis
>    and may reduce the adoption of network-based payload optimizations
>    like compression."
> 
> I don't understand what is implied about the relationship between
> transport layer encryption and one-way delay measurements. I thought the
> metric defined in this document was generally used for end-to-end
> measurement of delay, so I don't understand what "network-based
> analysis" has to do with this methodology step. 
[ACM] 
The methodology calls for a random payload in an attempt to measure
the delay on an a path without effects of network-based compression 
(if it is present).

> Is the implication that if the
> measurement packet is encrypted at the transport layer that delay will
> change? 
[ACM] 
No, not if the methodology recommendation of a random payload is followed.

On the other hand, if end-to-end encryption of user traffic becomes 
commonplace, then network-based compression will see less deployment
because it has little benefit, and the recommendation for random 
payload will be unnecessary. That's the implication.

> If that is true, isn't the metric itself agnostic to that
> consideration -- that is, couldn't that be precisely what the person
> doing the measurements wants to measure? I could quibble with the
> conclusions of the note itself (e.g., increased transport layer
> encryption may change but not necessarily reduce network-based
> "analysis"
> of various sorts), but mainly I do not understand how it relates to the
> specification of the metric.
> 
> Unfortunately the rationale given in Section 1 ("Added text recognizing
> the impending deployment of transport layer encryption in section 3.6")
> does not clarify this either. What impending deployment is this
> referencing?
[ACM] 
Ironically, I added the last sentence above during review of this draft,
after addressing your comment on what is now RFC 7312,
which says:

3.1.2.  Test Packet Payload Content Optimization

   The aim for efficient network resource use has resulted in deployment
   of server-only or client-server lossless or lossy payload compression
   techniques on some links or paths.  These optimizers attempt to
   compress high-volume traffic in order to reduce network load.  Files
   are analyzed by application-layer parsers, and parts (like comments)
   might be dropped.  Although typically acting on HTTP or JPEG files,
   compression might affect measurement packets, too.  In particular,
   measurement packets are qualified for efficient compression when they
   use standard plain-text payload.  We note that use of transport-layer
   encryption will counteract the deployment of network-based analysis
   and may reduce the adoption of payload optimizations, however.

I'll try to clarify the text in section 3.6, but feel free to make a
suggestion yourself.

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> >From Section 6:
> 
> "The privacy concerns of network measurement are limited by the active
>    measurements described in this memo.  Unlike passive measurements,
>    there can be no release of existing user data."
> 
> I realize this is text from RFC 2679, but I think it would be good to
> update it to reflect what has been learned since the publication of that
> document. The mere fact that a host is involved in conducting
> measurements could well be considered privacy-sensitive in some
> contexts.
> And a collection of measurements about a host, even active measurements,
> could leak information about the host's connectivity/availability/etc.
> if not appropriately safeguarded. I don't think this changes the
> protocol requirements for this document, but I do think the text above
> should note these aspects (perhaps similar to how it's done in
> <https://tools.ietf.org/html/draft-ietf-lmap-framework-14#section-8.3>).
> It's not quite correct to say there can be no release of existing user
> data.
> 
[ACM]
I'll replace the sentence above with the privacy paragraph from 
section 6 of RFC 7312, including the reference to the LMAP Framework.
http://tools.ietf.org/html/rfc7312#section-6