Subject: Re: [pm-dir] Request for RFC 6390 review of https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sun, 1 Oct 2017 15:21:23 +0000

Hi Vin,
Did you send your review?
Al

From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: Wednesday, September 13, 2017 10:59 PM
To: MORTON, ALFRED C (AL)
Cc: Vinayak Hegde; Benoit Claise; [email-masked]
Subject: Re: [pm-dir] Request for RFC 6390 review of https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/

Hi, Al,

On Wed, Sep 13, 2017 at 5:14 PM, MORTON, ALFRED C (AL) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Vin! you have about two weeks till the
deadline in Spencer’s mail below.

Thanks to the both of you!

Spencer

@Spencer: Reviewer Assigned.
Al

From: Vinayak Hegde [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, September 13, 2017 5:21 PM
To: MORTON, ALFRED C (AL)
Cc: Spencer Dawkins at IETF; Benoit Claise; [email-masked]<mailto:[email-masked]>
Subject: Re: [pm-dir] Request for RFC 6390 review of https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Dalt-2Dmark_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=lqCVNTxJzxSv6fDPhJ_7XO9WVkJedn6m08RcGsYjBfE&s=-usdGp4vmzmJO1h45IIrbPYNClyxhrJ3ioEe_gS9CvY&e=>

I am okay with doing it over the weekend.

Regards
Vinayak

On 13 Sep 2017 23:19, "MORTON, ALFRED C (AL)" <[email-masked]<mailto:[email-masked]>> wrote:
Thank you for your request, Spencer.

Are there any volunteers to review this draft?

Al
pm-dir admin

From: pm-dir [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Spencer Dawkins at IETF
Sent: Wednesday, September 13, 2017 1:31 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Benoit Claise
Subject: [pm-dir] Request for RFC 6390 review of https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Dalt-2Dmark_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=C_01Pb4oiAlY20iYvBctcRrOSzBsM6NOlBXzTkP4-_M&s=61OThBXZMgAUpXHlmUHKOa0ahjYyrnak1PvyEitpjw0&e=>

Dear PM-Dir,

As the responsible AD for this draft, I'd like to request an RFC 6390 review for https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Dalt-2Dmark_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=kqJFJ9C8Msh8I6rl992a4ePZ8bFiEr0zXa4uhSm5bjw&s=FSox9TzwP1sgsegolaQeO-zCZlGONCwregid1rBRLFY&e=>.

The draft is in Last Call Requested state, with Last Call ending around 9-27-2017.

Please let me know if you need anything else, and thanks,

Spencer

_______________________________________________
pm-dir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pm-dir<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_pm-2Ddir&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=C_01Pb4oiAlY20iYvBctcRrOSzBsM6NOlBXzTkP4-_M&s=-ssGmpIfbNAjupsk6L06-kQUp0L1Cv36LeLf-l4Ase4&e=>

---

From: Vinayak Hegde <[email-masked]>
Date: Mon, 2 Oct 2017 02:23:35 +0530

Al mentioned in a private message that this message below did not make
it across. So sending it again with the authors in cc for review.

-- Vinayak

---------- Forwarded message ----------
From: Vinayak Hegde <[email-masked]>
Date: Mon, Sep 25, 2017 at 3:02 AM
Subject: Re: [pm-dir] Request for RFC 6390 review of
https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/
To: "MORTON, ALFRED C (AL)" <[email-masked]>
Cc: Spencer Dawkins at IETF <[email-masked]>, Benoit
Claise <[email-masked]>, "[email-masked]" <[email-masked]>

I have done the review of the draft below as per RFC 6390

The RFC mostly conforms to the RFC 6390 recommended format (separately
noted in a section "8.  Compliance with RFC6390 guidelines"). There
are some small changes that might make the document more clear and
readable.

1. Define steady state explicitly - there is an attempt made though
noting that when the alternate color is being marked in the flow but
calling it out would make it clearer.

2. It might be useful to also explicitly state what the timeout should
be for marking the packet as marked. Currently it seems that it is
left as an exercise to the implementer of the draft. One way could be
to not consider the packets when the same colour is marked again on
the flow. The old packets of the same colour "expire" or are lost. For
example the draft recomends 5 min fr switching the colour. A similar
recommendation might be made for marking packets as lost after a
certain timeout (either as a percentage of the measurement period or a
flat time).

3. There are two sections - Normative and Informative. The draft
addresses the normative and informative parts except the verification
section of the informative part. If it is not applicable (may not be
possible to reproduce results for verification), then it should be
explicitly noted in the draft.

Regards
Vinayak

On Sun, Sep 24, 2017 at 2:02 PM, MORTON, ALFRED C (AL) <[email-masked]> wrote:
> Hi Vin,
>
> reminder for this review,
>
> Al
>
>
>
> Subject: Re: [pm-dir] Request for RFC 6390 review of
> https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/
>
>
>
> Hi, Al,
>
>
>
> On Wed, Sep 13, 2017 at 5:14 PM, MORTON, ALFRED C (AL) <[email-masked]>
> wrote:
>
> From: Vinayak Hegde [mailto:[email-masked]]
> Cc: Spencer Dawkins at IETF; Benoit Claise; [email-masked]
> Subject: Re: [pm-dir] Request for RFC 6390 review of
> https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/
>
>
>
> On 13 Sep 2017 23:19, "MORTON, ALFRED C (AL)" <[email-masked]> wrote:
>
> From: pm-dir [mailto:[email-masked]] On Behalf Of Spencer Dawkins
> at IETF
> To: [email-masked]
> Subject: [pm-dir] Request for RFC 6390 review of
> https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/
>
>
>
> Dear PM-Dir,
>
>
>
> As the responsible AD for this draft, I'd like to request an RFC 6390 review
> for https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/.
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pm-dir
>
>

---

From: Fioccola Giuseppe <[email-masked]>
Date: Tue, 3 Oct 2017 09:13:34 +0000

Hi Vinayak,
Thanks for your review of the document. I can address your comments in the next version of the draft.
Please see my answers inline tagged as [GF].

Best Regards,

Giuseppe

-----Messaggio originale-----
Da: Vinayak Hegde [mailto:[email-masked]] 
Inviato: domenica 1 ottobre 2017 22:54
A: [email-masked]; Spencer Dawkins at IETF; Benoit Claise; [email-masked]
Oggetto: Fwd: [pm-dir] Request for RFC 6390 review of https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/

Al mentioned in a private message that this message below did not make it across. So sending it again with the authors in cc for review.

-- Vinayak

---------- Forwarded message ----------
From: Vinayak Hegde <[email-masked]>
Date: Mon, Sep 25, 2017 at 3:02 AM
Subject: Re: [pm-dir] Request for RFC 6390 review of https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/
To: "MORTON, ALFRED C (AL)" <[email-masked]>
Cc: Spencer Dawkins at IETF <[email-masked]>, Benoit Claise <[email-masked]>, "[email-masked]" <[email-masked]>

The RFC mostly conforms to the RFC 6390 recommended format (separately noted in a section "8.  Compliance with RFC6390 guidelines"). There are some small changes that might make the document more clear and readable.

1. Define steady state explicitly - there is an attempt made though noting that when the alternate color is being marked in the flow but calling it out would make it clearer.

[GF]: Ok I will do. I can add something like that: "steady state is an intrinsic characteristic of the marking method counters because the alternation of color makes the counters associated to each color still one at a time for the duration of a marking period."

2. It might be useful to also explicitly state what the timeout should be for marking the packet as marked. Currently it seems that it is left as an exercise to the implementer of the draft. One way could be to not consider the packets when the same colour is marked again on the flow. The old packets of the same colour "expire" or are lost. For example the draft recomends 5 min fr switching the colour. A similar recommendation might be made for marking packets as lost after a certain timeout (either as a percentage of the measurement period or a flat time).

[GF]: Yes, I will clarify this point. Timing Aspects are detailed in Section 3.2, so I can add a reference to Section 3.2 also here and highlight that there is a relationship between the choice of the marking period and the guardband interval to avoid out of order issues, as you correctly mentioned. 5 minutes marking period is an implementation choice of our experiment because it is coherent with the reporting window of our NMS and simplify our homemade implementation. Other optimized implementation can use a marking period of a few seconds.

3. There are two sections - Normative and Informative. The draft addresses the normative and informative parts except the verification section of the informative part. If it is not applicable (may not be possible to reproduce results for verification), then it should be explicitly noted in the draft.

[GF]: You are right about this omission and a guidance on verification testing can be provided. I can mention that both in our Lab and in the operational network the methodology has been tested and experimented for packet loss and delay measurements by using traffic generators together with precision test instruments and network emulators.

Regards
Vinayak

On Sun, Sep 24, 2017 at 2:02 PM, MORTON, ALFRED C (AL) <[email-masked]> wrote:
> From: pm-dir [mailto:[email-masked]] On Behalf Of Spencer 
> Dawkins at IETF
> As the responsible AD for this draft, I'd like to request an RFC 6390 
> review for https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/.
>
>
>

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. 

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: Vinayak Hegde <[email-masked]>
Date: Tue, 3 Oct 2017 14:51:56 +0530

Thanks Fioccola. Looking forward to the next revision :) Happy to help.

Regards
Vinayak

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 3 Oct 2017 13:05:13 +0000

Thanks for completing your pm-dir review, Vin!

And, thanks for receiving our comments
(slightly tardy due to comm failure) 
so gracefully, Guiseppe.

regards,
Al

> -----Original Message-----
> From: pm-dir [mailto:[email-masked]] On Behalf Of Vinayak Hegde
> Sent: Tuesday, October 03, 2017 5:22 AM
> To: Fioccola Giuseppe
> Cc: Benoit Claise; [email-masked]; pm-
> [email-masked]; Spencer Dawkins at IETF; Carlos Pignataro (cpignata)
> ([email-masked])
> > Oggetto: Fwd: [pm-dir] Request for RFC 6390 review of
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Dalt-
> 2Dmark_&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=NnXGCbZHM9KqT5VqVXjo12eZNeP
> cxXJAUXpQjGJkMt4&s=CzQWBczTni8nz9-eUPxy8LXYqya7rAngec-U0ieduDQ&e=
> >
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Dalt-
> 2Dmark_&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=NnXGCbZHM9KqT5VqVXjo12eZNeP
> cxXJAUXpQjGJkMt4&s=CzQWBczTni8nz9-eUPxy8LXYqya7rAngec-U0ieduDQ&e=
> noted in a section "8.  Compliance with RFC6390 guidelines"). There are
> some small changes that might make the document more clear and readable.
> >
> > [GF]: Ok I will do. I can add something like that: "steady state is an
> intrinsic characteristic of the marking method counters because the
> alternation of color makes the counters associated to each color still
> one at a time for the duration of a marking period."
> >
> be for marking the packet as marked. Currently it seems that it is left
> as an exercise to the implementer of the draft. One way could be to not
> consider the packets when the same colour is marked again on the flow.
> The old packets of the same colour "expire" or are lost. For example the
> draft recomends 5 min fr switching the colour. A similar recommendation
> might be made for marking packets as lost after a certain timeout
> (either as a percentage of the measurement period or a flat time).
> >
> > [GF]: Yes, I will clarify this point. Timing Aspects are detailed in
> Section 3.2, so I can add a reference to Section 3.2 also here and
> highlight that there is a relationship between the choice of the marking
> period and the guardband interval to avoid out of order issues, as you
> correctly mentioned. 5 minutes marking period is an implementation
> choice of our experiment because it is coherent with the reporting
> window of our NMS and simplify our homemade implementation. Other
> optimized implementation can use a marking period of a few seconds.
> >
> > [GF]: You are right about this omission and a guidance on verification
> testing can be provided. I can mention that both in our Lab and in the
> operational network the methodology has been tested and experimented for
> packet loss and delay measurements by using traffic generators together
> with precision test instruments and network emulators.
> >
> > Regards
> > Vinayak
> >
> >
> >> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Dalt-
> 2Dmark_&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=NnXGCbZHM9KqT5VqVXjo12eZNeP
> cxXJAUXpQjGJkMt4&s=CzQWBczTni8nz9-eUPxy8LXYqya7rAngec-U0ieduDQ&e=
> >>
> >>
> >>
> >> Hi, Al,
> >>
> >>
> >>
> >> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Dalt-
> 2Dmark_&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=NnXGCbZHM9KqT5VqVXjo12eZNeP
> cxXJAUXpQjGJkMt4&s=CzQWBczTni8nz9-eUPxy8LXYqya7rAngec-U0ieduDQ&e=
> >>
> >>
> >>
> >> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Dalt-
> 2Dmark_&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=NnXGCbZHM9KqT5VqVXjo12eZNeP
> cxXJAUXpQjGJkMt4&s=CzQWBczTni8nz9-eUPxy8LXYqya7rAngec-U0ieduDQ&e=
> >>
> >>
> >>
> >> Dear PM-Dir,
> >>
> >>
> >>
> >> review for https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Dalt-
> 2Dmark_&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=NnXGCbZHM9KqT5VqVXjo12eZNeP
> cxXJAUXpQjGJkMt4&s=CzQWBczTni8nz9-eUPxy8LXYqya7rAngec-U0ieduDQ&e= .
> >>
> >>
> >>
> >> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_pm-2Ddir&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=NnXGCbZHM9KqT5VqVXjo12eZNeP
> cxXJAUXpQjGJkMt4&s=280bz7tua9j8MODtCOgrPkwiNMgCxBzR5rZkPdXPQmk&e=
> >>
> >>
> >
> > 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.
> >
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_pm-2Ddir&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=NnXGCbZHM9KqT5VqVXjo12eZNeP
> cxXJAUXpQjGJkMt4&s=280bz7tua9j8MODtCOgrPkwiNMgCxBzR5rZkPdXPQmk&e=

---

From: Fioccola Giuseppe <[email-masked]>
Date: Tue, 3 Oct 2017 13:33:04 +0000

Thank you! Just submitted the new version.
Best Regards,

Giuseppe

-----Messaggio originale-----
Da: MORTON, ALFRED C (AL) [mailto:[email-masked]] 
Inviato: martedì 3 ottobre 2017 15:05
A: Vinayak Hegde; Fioccola Giuseppe
Cc: Benoit Claise; [email-masked]; [email-masked]; Spencer Dawkins at IETF; Carlos Pignataro (cpignata) ([email-masked])
Oggetto: RE: [pm-dir] Request for RFC 6390 review of https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/

regards,
Al

> > Thanks for your review of the document. I can address your comments 
> > in
> the next version of the draft.
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=NnXGCbZHM9KqT5VqVXjo12eZN
> eP cxXJAUXpQjGJkMt4&s=CzQWBczTni8nz9-eUPxy8LXYqya7rAngec-U0ieduDQ&e=
> >
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=NnXGCbZHM9KqT5VqVXjo12eZN
> eP cxXJAUXpQjGJkMt4&s=CzQWBczTni8nz9-eUPxy8LXYqya7rAngec-U0ieduDQ&e=
> are some small changes that might make the document more clear and readable.
> >
> to not consider the packets when the same colour is marked again on the flow.
> The old packets of the same colour "expire" or are lost. For example 
> the draft recomends 5 min fr switching the colour. A similar 
> certain timeout (either as a percentage of the measurement period or a flat time).
> >
> highlight that there is a relationship between the choice of the 
> marking period and the guardband interval to avoid out of order 
> issues, as you correctly mentioned. 5 minutes marking period is an 
> implementation choice of our experiment because it is coherent with 
> the reporting window of our NMS and simplify our homemade 
> implementation. Other optimized implementation can use a marking period of a few seconds.
> >
> operational network the methodology has been tested and experimented 
> for packet loss and delay measurements by using traffic generators 
> together with precision test instruments and network emulators.
> >
> > Regards
> > Vinayak
> >
> >
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=NnXGCbZHM9KqT5VqVXjo12eZN
> eP cxXJAUXpQjGJkMt4&s=CzQWBczTni8nz9-eUPxy8LXYqya7rAngec-U0ieduDQ&e=
> >>
> >>
> >>
> >> Hi, Al,
> >>
> >>
> >>
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=NnXGCbZHM9KqT5VqVXjo12eZN
> eP cxXJAUXpQjGJkMt4&s=CzQWBczTni8nz9-eUPxy8LXYqya7rAngec-U0ieduDQ&e=
> >>
> >>
> >>
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=NnXGCbZHM9KqT5VqVXjo12eZN
> eP cxXJAUXpQjGJkMt4&s=CzQWBczTni8nz9-eUPxy8LXYqya7rAngec-U0ieduDQ&e=
> >>
> >>
> >>
> >> Dear PM-Dir,
> >>
> >>
> >>
> >> As the responsible AD for this draft, I'd like to request an RFC 
> >> 6390 review for https://urldefense.proofpoint.com/v2/url?u=https-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=NnXGCbZHM9KqT5VqVXjo12eZN
> eP cxXJAUXpQjGJkMt4&s=CzQWBczTni8nz9-eUPxy8LXYqya7rAngec-U0ieduDQ&e= .
> >>
> >>
> >>
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=NnXGCbZHM9KqT5VqVXjo12eZN
> eP cxXJAUXpQjGJkMt4&s=280bz7tua9j8MODtCOgrPkwiNMgCxBzR5rZkPdXPQmk&e=
> >>
> >>
> >
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=NnXGCbZHM9KqT5VqVXjo12eZN
> eP cxXJAUXpQjGJkMt4&s=280bz7tua9j8MODtCOgrPkwiNMgCxBzR5rZkPdXPQmk&e=