Re: [Lsr] My comment on https://datatracker.ietf.org/doc/html/draft-wang-lsr-flex-algo-link-loss-00
Speaking as WG member: RFC 7471 contains a definition of link loss: 4.4.5. Link Loss This 24-bit field carries link packet loss as a percentage of the total traffic sent over a configurable interval. The basic unit is 0.03%, where (2^24 - 2) is 50.331642%. This value is the highest packet loss percentage that can be expressed (the assumption being that precision is more important on high speed links than the ability to advertise loss rates greater than this, and that high speed links with over 50% loss are unusable). Therefore, measured values that are larger than the field maximum SHOULD be encoded as the maximum value. This would seem to me not include loss due to QoS policing. However, it would seem the measurement technique would be impacted this. It would be good to get input with Sasha, Greg, and others how to define link loss. Of course, measurement techniques are under the charter of other WGs. RFC 7471 includes a discussion (albeit brief) of advertisement hysteresis. This draft should include a discussion of computational hysteresis. However, I don’t see this as required for WG adoption. Thanks, Acee > On Nov 6, 2023, at 13:31, Greg Mirsky wrote: > > Hi Yifan Wang, > thank you for the clarification on the packet loss measurement. I agree that > TWAMP/TWAMP-Lite could be used to measure packet loss using synthetic > packets. I would note that STAMP (RFC 8762 > <https://datatracker.ietf.org/doc/rfc8762/>) has all the functionality of > TWAMP. Also, the Direct measurement extension of STAMP (RFC 8972 > <https://datatracker.ietf.org/doc/rfc8972/>) can measure data traffic loss > using operator-defined "in-profile" characteristics of the monitored flow. > > Regards, > Greg > > On Mon, Nov 6, 2023 at 1:08 PM wangyifan (AI) > <mailto:40huawei@dmarc.ietf.org>> wrote: >> Hi, >> >> Thanks for the comments. >> >> >> >> In the afternoon presentation I mainly introduce the path computation method >> based on link loss. >> >> >> >> Here are the consideration of how packet loss on a link is measured: >> >> >> >> 1. The packet loss rate is measured based on the TWAMP or TWAMP LIGHT. >> It doesn’t depend on the real traffic. >> >> 2. The TWAMP session can be deployed to measure the packet loss rate >> before the flexible algorithm is configured. Consequently the packet loss >> caused by real traffic tests can be prevented. >> >> 3. The measured packet loss rate can be suppressed to prevent frequent >> traffic switching caused by link loss changes. >> >> >> >> Regards, >> >> Yifan Wang. >> >> >> >> 发件人: Lsr mailto:lsr-boun...@ietf.org>> 代表 Alexander >> Vainshtein >> 发送时间: 2023年11月6日 18:15 >> 收件人: draft-wang-lsr-flex-algo-link-loss.auth...@ietf.org >> <mailto:draft-wang-lsr-flex-algo-link-loss.auth...@ietf.org> >> 抄送: lsr@ietf.org <mailto:lsr@ietf.org>; Nitsan Dolev > <mailto:nitsan.do...@rbbn.com>> >> 主题: [Lsr] My comment on >> https://datatracker.ietf.org/doc/html/draft-wang-lsr-flex-algo-link-loss-00 >> >> >> >> Hi, >> >> Just repeating my comment at the mike: >> >> >> >> The draft does not explain how packet loss on a link is measured. >> >> >> >> If this measurement is based on real traffic, excluding the link from the >> topology for certain flexible algorithms may result in the packet loss going >> down and the link becoming eligible for traffic again. >> >> >> >> For this scheme to work, link loss measurement should be done in a way that >> does not depend on the amount of customer traffic crossing the link. >> >> >> >> I also think that, even with such a scheme, some kind of hysteresis >> mechanism is required to prevent link being frequently excluded and admitted >> back if the packet loss rate fluctuates around the threshold level, >> >> >> >> >> >> My 2c, >> >> Sasha >> >> >> >> >> >> Disclaimer >> >> This e-mail together with any attachments may contain information of Ribbon >> Communications Inc. and its Affiliates that is confidential and/or >> proprietary for the sole use of the intended recipient. Any review, >> disclosure, reliance or distribution by others or forwarding without express >> permission is strictly prohibited. If you are not the intended recipient, >> please notify the sender immediately and then delete all copies, including >> any attachments. >> >> ___ >> Lsr mailing list >> Lsr@ietf.org <mailto:Lsr@ietf.org> >> https://www.ietf.org/mailman/listinfo/lsr > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] My comment on https://datatracker.ietf.org/doc/html/draft-wang-lsr-flex-algo-link-loss-00
Hi Sasha, FYI, packet loss for a link can be measured using the procedure defined in the following draft, including direct measurement for customer traffic. https://www.ietf.org/archive/id/draft-ietf-spring-stamp-srpm-10.html The draft can refer to the above reference if it helps. thanks, Rakesh On Mon, Nov 6, 2023 at 11:15 AM Alexander Vainshtein < alexander.vainsht...@rbbn.com> wrote: > Hi, > > Just repeating my comment at the mike: > > > > *The draft does not explain how packet loss on a link is measured.* > > > > If this measurement is based on real traffic, excluding the link from the > topology for certain flexible algorithms may result in the packet loss > going down and the link becoming eligible for traffic again. > > > > For this scheme to work, link loss measurement should be done in a way > that does not depend on the amount of customer traffic crossing the link. > > > > I also think that, even with such a scheme, some kind of hysteresis > mechanism is required to prevent link being frequently excluded and > admitted back if the packet loss rate fluctuates around the threshold level, > > > > > > My 2c, > > Sasha > > > > > *Disclaimer* > > This e-mail together with any attachments may contain information of > Ribbon Communications Inc. and its Affiliates that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without > express permission is strictly prohibited. If you are not the intended > recipient, please notify the sender immediately and then delete all copies, > including any attachments. > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] My comment on https://datatracker.ietf.org/doc/html/draft-wang-lsr-flex-algo-link-loss-00
Hi Sasha, Fully agree with the indicated Packet loss variance problematic aspects. Hysteresis mechanism might help but also might imply undesired extra complexity. Nitsan Dolev From: Alexander Vainshtein Sent: Monday, November 6, 2023 12:15 PM To: draft-wang-lsr-flex-algo-link-loss.auth...@ietf.org Cc: lsr@ietf.org; Nitsan Dolev Subject: My comment on https://datatracker.ietf.org/doc/html/draft-wang-lsr-flex-algo-link-loss-00 Hi, Just repeating my comment at the mike: The draft does not explain how packet loss on a link is measured. If this measurement is based on real traffic, excluding the link from the topology for certain flexible algorithms may result in the packet loss going down and the link becoming eligible for traffic again. For this scheme to work, link loss measurement should be done in a way that does not depend on the amount of customer traffic crossing the link. I also think that, even with such a scheme, some kind of hysteresis mechanism is required to prevent link being frequently excluded and admitted back if the packet loss rate fluctuates around the threshold level, My 2c, Sasha Disclaimer This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] My comment on https://datatracker.ietf.org/doc/html/draft-wang-lsr-flex-algo-link-loss-00
Hi, Just repeating my comment at the mike: The draft does not explain how packet loss on a link is measured. If this measurement is based on real traffic, excluding the link from the topology for certain flexible algorithms may result in the packet loss going down and the link becoming eligible for traffic again. For this scheme to work, link loss measurement should be done in a way that does not depend on the amount of customer traffic crossing the link. I also think that, even with such a scheme, some kind of hysteresis mechanism is required to prevent link being frequently excluded and admitted back if the packet loss rate fluctuates around the threshold level, My 2c, Sasha Disclaimer This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
