Re: [ippm] Magnus Westerlund's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS and COMMENT)

[Magnus Westerlund <[e-mail]>]

Hi Greg,

This clarifies it sufficiently. I have cleared my discuss. 

Thanks

Magnus

On Tue, 2019-09-24 at 13:39 -0700, Greg Mirsky wrote:
> Hi Magnus,
> a new section, Operational Considerations, has been added to address Barry's
> DISCUSS:
> 
> 5.  Operational Considerations
> 
>    STAMP is intended to be used on production networks to enable the
>    operator to assess service level agreements based on packet delay,
>    delay variation, and loss.  When using STAMP over the Internet,
>    especially when STAMP test packets are transmitted with the
>    destination UDP port number from the User Ports range, the possible
>    impact of the STAMP test packets MUST be thoroughly analyzed.  The
>    use of STAMP for each case MUST be agreed by users of nodes hosting
>    the Session-Sender and Session-Reflector before starting the STAMP
>    test session.
> 
>    Also, the use of the well-known port number as the destination UDP
>    port number in STAMP test packets transmitted by a Session-Sender
>    would not impede the ability to measure performance in an Equal Cost
>    Multipath environment and analysis in Section 5.3 [RFC8545] fully
>    applies to STAMP.
> 
> Would it address your concern?
> 
> The new version of the draft has been published. It includes all the updates
> we've discussed.
> 
> Much appreciate your consideration of the new version, comments, and
> questions.
> 
> Kind regards,
> Greg
> 
> On Mon, Sep 16, 2019 at 8:29 AM Magnus Westerlund <
> [e-mail]> wrote:
> > On Wed, 2019-09-11 at 11:33 -0700, Greg Mirsky wrote:
> > > Hi Magnus,
> > > thank you for clarifications and further detailing your comments,
> > > questions. Please find my answers and notes below in-lined under the
> > > GIM2>> tag.
> > > 
> > > Regards,
> > > Greg
> > > 
> > > On Wed, Sep 11, 2019 at 12:53 AM Magnus Westerlund <
> > > [e-mail]> wrote:
> > > > Hi Greg,
> > > > 
> > > > Thanks for the reply. See inline for my comments and response. 
> > > > 
> > > > 
> > > > On Tue, 2019-09-10 at 12:43 -0700, Greg Mirsky wrote:
> > > > > Hi Magnus,
> > > > > thank you for the review and thoughtful, pointed questions.
> > > > Please
> > > > > find my answers in-line under GIM>> tag.
> > > > > 
> > > > > Regards,
> > > > > Greg
> > > > > 
> > > > > On Wed, Sep 4, 2019 at 3:54 PM Magnus Westerlund via Datatracker
> > > > <
> > > > > [e-mail]> wrote:
> > > > > > Magnus Westerlund has entered the following ballot position for
> > > > > > draft-ietf-ippm-stamp-07: Discuss
> > > > > > 
> > > > > > When responding, please keep the subject line intact and reply
> > > > to
> > > > > > all
> > > > > > email addresses included in the To and CC lines. (Feel free to
> > > > cut
> > > > > > this
> > > > > > introductory paragraph, however.)
> > > > > > 
> > > > > > 
> > > > > > Please refer to 
> > > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > > > for more information about IESG DISCUSS and COMMENT positions.
> > > > > > 
> > > > > > 
> > > > > > The document, along with other ballot positions, can be found
> > > > here:
> > > > > > https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > -------------------------------------------------------------
> > > > ----
> > > > > > -----
> > > > > > DISCUSS:
> > > > > > -------------------------------------------------------------
> > > > ----
> > > > > > -----
> > > > > > 
> > > > > > Two very much discussing discusses. However, I would really
> > > > like to
> > > > > > hear the
> > > > > > answer to these concerns before clearing.
> > > > > > 
> > > > > > 1. Section 4.3: Is the HMAC field size of 16 bytes hard coded?
> > > > If
> > > > > > there ever
> > > > > > would exist a need to deploy another integrity solution, even
> > > > if
> > > > > > the actual
> > > > > > algorithm used to construct the tag can be agreed by the
> > > > > > management, there
> > > > > > appear to exist a hard look in to use 16-byte tags. Have this
> > > > issue
> > > > > > been
> > > > > > considered?
> > > > > 
> > > > > GIM>> Indeed, this specification defines the use of only one
> > > > > algorithm and only 16 bytes-long HMAC field. Your question
> > > > prompted
> > > > > the discussion among authors and we believe that in a future
> > > > > specification it would be feasible to extend supporting a number
> > > > of
> > > > > algorithms and different lengths of HMAC field both being defined
> > > > > through extension to STAMP YANG data model.
> > > > 
> > > > So if I understand this (taking a discussion with Mirja about
> > > > keeping
> > > > things as simple as possible) the solution is to basically is when
> > > > need
> > > > arises define a new STAMP version, and then use YANG to coordinate
> > > > which version is used for the measurement. If that is a correct re-
> > > > interpretation of your response then I am fine with it. 
> > > 
> > > GIM2>> The direction from the WG was to keep the base specification
> > > as simple  as possible (and that was the reason to split TLV
> > > extensions into a separate document). 
> > 
> > Yes, understood. 
> > 
> > > > > >         2. Section 6:
> > > > > >         The possible impact of the
> > > > > >    STAMP test packets on the network MUST be thoroughly
> > > > analyzed,
> > > > > > and
> > > > > >    the use of STAMP for each case MUST be agreed by all users
> > > > on
> > > > > > the
> > > > > >    network before starting the STAMP test session.
> > > > > > 
> > > > > >         I assume some potential issues are know, shouldn't they
> > > > > > really be
> > > > > >         listed here in the security consideration to further
> > > > > > motivate why the
> > > > > >         analysis needs to happen.
> > > > > 
> > > > > GIM>> This is in reference to using numbers from the User range
> > > > as
> > > > > the destination port number. Would adding the reference to the
> > > > case
> > > > > of using the port numbers from the User range address your
> > > > concern?
> > > > > Or rather refer to Section 4, as it includes more discussion
> > > > (see 
> > > > > below)? 
> > > > 
> > > > Okay, I don't really care where the discussion happens. But I don't
> > > > find any real discussion and listing of the concerns with using
> > > > user or
> > > > dynamic ports for STAMP Sessions? With the formulation you use, I
> > > > would
> > > > expect at least some list of potential concerns that needs to be
> > > > evaluated in the context of the particular usage of STAMP. 
> > > 
> > > GIM2>> Per Berry's suggestion, I'm adding a new section, Operational
> > > Considerations, to list possible scenarios and possible issues with
> > > using destination ports from the User range and from the Dynamic
> > > range. I hope to finish it in a couple days. Will share on this
> > > discussion thread promptly. 
> > 
> > Great!
> > 
> > Looking forward to review it when written. 
> > 
> > > > > > 
> > > > > > -------------------------------------------------------------
> > > > ----
> > > > > > -----
> > > > > > COMMENT:
> > > > > > -------------------------------------------------------------
> > > > ----
> > > > > > -----
> > > > > > 
> > > > > >         1. Section 4:
> > > > > >         Before using numbers from the User Ports range, the
> > > > > > possible impact
> > > > > >    on the network MUST be carefully studied and agreed by all
> > > > users
> > > > > > of
> > > > > >    the network.
> > > > > > 
> > > > > >         Is the above sentence missing to list an important
> > > > > > assumption? Is the
> > > > > >         assumption that by using the registred destination port
> > > > an
> > > > > > operator
> > > > > >         that sees to much STAMP traffic can simply filter it
> > > > out
> > > > > > and that way
> > > > > >         deal with the traffic, something which is not possible
> > > > when
> > > > > > using an
> > > > > >         locally decided port? If that is the case, this
> > > > assumption
> > > > > > should
> > > > > >         probably be noted.
> > > > > 
> > > > > GIM>> That is a very good point but our primary motivation for
> > > > this
> > > > > cautionary note (or strong warning) was that by allowing STAMP to
> > > > use
> > > > > port numbers from the User range, ports that may be already
> > > > assigned
> > > > > to protocols, creates a DDOS attack vector. As for the filtering
> > > > > STAMP traffic out, I think that even if the destination port is
> > > > one
> > > > > from the Dynamic range, for a relatively long test session it can
> > > > be
> > > > > filtered out.
> > > > 
> > > > So if that is the only? concern then write it out. I would expect
> > > > that
> > > > the higher layer management protocol that creates a measurement
> > > > session
> > > > to actually ensure that the STAMP endpoint actually have the port
> > > > numbers they attempt to use. Isn't that a reasonable requirement to
> > > > put
> > > > on the solution? 
> > > 
> > > GIM2>> Agree with your suggestion. Will put in the new section. If
> > > STAMP is managed by a centralized system, whether it is proprietary
> > > OSS/BSS or an orchestrator that uses YANG data models, the system
> > > will be able to coordinate selection of port numbers on the Session-
> > > Sender and Session-Reflector. But some systems may use EMS or CLI and
> > > that is where human coordination may be required. 
> > 
> > 
> > Good, then likely this is resolved when your text is ready. 
> > 
> > > > My thinking with the filtering out concern was that in cases where
> > > > one
> > > > runs STAMP measurement sessions, if the measurement interfer with
> > > > critical traffic an action for an on-path node that can actually
> > > > identify the STAMP traffic was to filer it out. And that may be
> > > > considered trivial when the well known port is used, but if a user
> > > > or
> > > > dynamic port is used, then that requries a managment system to
> > > > provide
> > > > the on-path node with the necessary information, i.e. 3/5 tuple for
> > > > the
> > > > STAMP flows. 
> > > 
> > > GIM2>> I think that a transit node can identify a flow as the STAMP
> > > flow only if the destination port is the STAMP default UDP
> > > destination port number, 862. In case a STAMP session has the
> > > destination port number as one of port numbers from the User range,
> > > IP/UDP encapsulation of STAMP packets would be indistinguishable from
> > > packets originated by the application that is assigned that port
> > > number. Thus, filtering out on only destination port number may
> > > negatively affect service, legitimate service. Because of that, I
> > > think that filtering will have to use more information. On the other
> > > hand, if the test flow does not exceed agreed rate, then any
> > > filtering test packets out, in my opinion, is counter-productive, as
> > > it hides some issues in the networks rather than letting the OAM
> > > tools to expose them, localize, and characterize.
> > 
> > Ok. This was primarily to understand if this was in scope or not. But
> > it sounds like this is not really in scope for how to manage it. 
> > 
> > > > 
> > > > > >         2. Section 3 and 4, and 4.1.1: What is a STAMP Session?
> > > > Is
> > > > > > that a
> > > > > >         measurment session between one specific and sender and
> > > > a
> > > > > > specific
> > > > > >         reflector for a time duration?  The defenition of the
> > > > > > session do matter
> > > > > >         if one intended to enable a single sender to use
> > > > multiple
> > > > > > reflectors,
> > > > > >         and if that can be a single session or always multiple
> > > > > > indepdendent
> > > > > >         ones. Would appreciate a definition what a session is.
> > > > If
> > > > > > it is
> > > > > >         possible to send STAMP traffic using a multicast or
> > > > > > broadcast address
> > > > > >         should be made explicit.
> > > > > 
> > > > > GIM>> Your interpretation is correct, STAMP session is implicitly
> > > > > defined as p2p. And that is what reflected in the STAMP YANG
> > > > model.
> > > > > Would the following text make it clearer:
> > > > > NEW TEXT:
> > > > >    In this document, a measurement session also referred to as
> > > > >    STAMP session, is the session between one specific Session-
> > > > Sender
> > > > > and
> > > > >    one particular Session-Reflector for a time duration.
> > > > 
> > > > Yes, please include that definition. Question would it be clearer
> > > > to
> > > > replace ".. is the session betweeen .." with ".. is the bi-
> > > > directional
> > > > packet flows between .."? 
> > > 
> > > GIM2>> I agree, defining a session as a session makes is somewhat
> > > repetitive. Thank you. 
> > > Below is the updated text:
> > >    In this document, a measurement session also referred to as
> > >    STAMP session, is the bi-directional packet flow between one
> > > specific
> > >    Session-Sender and one particular Session-Reflector for a time
> > >    duration.
> > 
> > Looks good to me. 
> > 
> > > > 
> > > > > >         3.  Section 4.1.1.:
> > > > > >         Timestamp is eight octets long field.  STAMP node MUST
> > > > > > support
> > > > > >       Network Time Protocol (NTP) version 4 64-bit timestamp
> > > > format
> > > > > >       [RFC5905], the format used in [RFC5357].  STAMP node MAY
> > > > > > support
> > > > > >       IEEE 1588v2 Precision Time Protocol truncated 64-bit
> > > > > > timestamp
> > > > > >       format [IEEE.1588.2008], the format used in [RFC8186].
> > > > > > 
> > > > > >         Is the clock source here something that may be relevant
> > > > or
> > > > > > simply
> > > > > >         information the management functions should capture. I
> > > > > > think there is a
> > > > > >         similar issue to that of RTP faced when it comes to
> > > > > > understand what the
> > > > > >         timestamp actually represent and thus be used
> > > > correctly.
> > > > > > RTP clock
> > > > > >         source specification is RFC 7273
> > > > > >         (https://datatracker.ietf.org/doc/rfc7273/)
> > > > > 
> > > > > GIM>> NTP and PTP encodings have a different interpretation of
> > > > the
> > > > > Fraction field of the Timestamp field. In my experience, PTP
> > > > format
> > > > > is native for the data plane, while NTP is more used at the
> > > > control
> > > > > plane. Original extension to TWAMP has been described in RFC
> > > > 8186.
> > > > 
> > > > I think you missunderstood. When I talk about clock source, I am
> > > > actually referring to identifying the particular clock that the
> > > > node
> > > > use to derive the included timestamp from. 
> > > > 
> > > > And likely this is a moot point in this document where the clock
> > > > source
> > > > information belongs in the management layer, e.g. in the YANG data
> > > > model. 
> > > 
> > > GIM2>> Timestamp Information TLV (draft-ietf-ippm-stamp-option-tlv)
> > > provides information about the clock synchronization protocol and the
> > > method by wich the timestamp has been acquired at a Session-
> > > Reflector. We may extend it to list the name/locatior of the master
> > > clock.
> > 
> > Ok. sounds reasonable. 
> > 
> > > > 
> > > > > >         4. Section 4.1:
> > > > > >            Because STAMP supports symmetrical test packets,
> > > > STAMP
> > > > > > Session-Sender
> > > > > >    packet has a minimum size of 44 octets in unauthenticated
> > > > mode,
> > > > > > see
> > > > > >    Figure 2, and 112 octets in the authenticated mode, see
> > > > Figure
> > > > > > 4.
> > > > > > 
> > > > > >         The above text implies some potential for UDP payload
> > > > size
> > > > > > variability
> > > > > >         for the STAMP packets. However, the actual definition
> > > > > > appear to have
> > > > > >         fixed sizes. Can you please clarify if I have missed
> > > > > > something that
> > > > > >         enables the STAMP packet to have variable size?
> > > > > 
> > > > > GIM>> I think that the text can be improved by characterizing the
> > > > > listed sizes as "base". The variable length of a test packet in
> > > > STAMP
> > > > > is supported by using Extra Padding TLV defined in draft-ietf-
> > > > ippm-
> > > > > stamp-option-tlv. Below is the proposed update:
> > > > > OLD TEXT:
> > > > >    Because STAMP supports symmetrical test packets, STAMP
> > > > Session-
> > > > > Sender
> > > > >    packet has a minimum size of 44 octets in unauthenticated
> > > > mode,
> > > > > see
> > > > >    Figure 2, and 112 octets in the authenticated mode, see Figure
> > > > 4.
> > > > > NEW TEXT:
> > > > >    STAMP supports symmetrical test packets.  The base STAMP
> > > > Session-
> > > > >    Sender packet has a minimum size of 44 octets in
> > > > unauthenticated
> > > > >    mode, see Figure 2, and 112 octets in the authenticated mode,
> > > > see
> > > > >    Figure 4.  The variable length of a test packet in STAMP is
> > > > > supported
> > > > >    by using Extra Padding TLV defined in
> > > > >    [I-D.ietf-ippm-stamp-option-tlv].
> > > > > 
> > > > > With the new reference, should I-D.ietf-ippm-stamp-option-tlv be
> > > > > moved to the Normative References list or may remain in the
> > > > > Informative list?
> > > > 
> > > > From my perspective, the fact that optional TLV may occur following
> > > > the
> > > > base headers appears quite important. Here comes a question of
> > > > intention form the WG. Is it intended that one can have STAMP
> > > > endpoints
> > > > that do not even support receiving packets larger than the base? 
> > > > In other words there will be two main versions already now, one
> > > > that
> > > > supports some TLV and can at least handle the TLV skip forward and
> > > > ignore the content and one that will throw a fit over the TLVs? If
> > > > that
> > > > is not the intention I think the fact that TLV's may occur should
> > > > be
> > > > moved into this specification and have it as a normative reference.
> > > 
> > > GIM2>> Will move the reference to the Normative section. With TLV
> > > being normative, I'd expect that the intelligent implementation of
> > > this draft, of the base STAMP specification, will accept any valid
> > > STAMP packet though not process extensions. But the base STAMP
> > > Session-Reflector will return the base reflected packet.  
> > 
> > I think that is very reasonable approach. Are you close to complete the
> > stamp-option-tlv document, or will the missref cause any issue? 
> > 
> > > > I guess the answer is that you have backwards comaptibility reasons
> > > > for
> > > > not allowing TLVs at all in some sessions, or? 
> > > 
> > > GIM2>> Yes, that and the principle "keep it simple". 
> > 
> > Thanks,
> > 
> > To me it looks like with some text changes all my issues are addressed.
> > 
> > Cheers
> > 
> > Magnus Westerlund 
> > 
> > 
> > ----------------------------------------------------------------------
> > Network Architecture & Protocols, Ericsson Research
> > ----------------------------------------------------------------------
> > Ericsson AB                 | Phone  [phone]
> > Torshamnsgatan 23           | Mobile [phone]
> > SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> > ----------------------------------------------------------------------
> > 
> > 
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------