Subject: Re: [Srcomp] Section 2.2.2.1 conclusion

From: Ron Bonica <[email-masked]>
Date: Tue, 1 Jun 2021 13:42:24 +0000

Folks,

My father-in-law once said that the worst lies rise from poorly formulated questions.

We could count the number of headers parsed, ignoring the number for fields in each header. We might also ignore the fact that the number of headers parsed effects forwarding efficiency differently on each platform. We might even ignore the fact that the number of fields parsed effects forwarding efficiency differently on each platform. We might ignore the fact that acceptable forwarding efficiency has been demonstrated for most (all?) compression solutions.

What does that leave us? A true statement, that in the absence of other true statements, leads us to a false conclusion.

                                                                                         Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes=[email-masked]>
Sent: Thursday, May 27, 2021 9:45 PM
To: [email-masked]; Ron Bonica <[email-masked]>
Cc: [email-masked]
Subject: Re: [Srcomp] Section 2.2.2.1 conclusion

[External Email. Be cautious of content]

Sorry for my late response.

This is not a valid conclusion  for this section. The metric is to record the number of headers parsed. The conclusion seems obvious. Indicate the proposals that minimize headers parsed.

   o  D.PRS(segment list): number of headers parsed during processing of

      the segment list, starting from and including the IPv6 header.

________________________________
From: Srcomp <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, May 27, 2021 9:27:48 PM
To: rbonica=[email-masked]<mailto:rbonica=[email-masked]> <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Srcomp] Section 2.2.2.1 conclusion

It looks good for me.

Regards,
PSF

------------------原始邮件------------------
发件人：RonBonica
收件人：[email-masked]<mailto:[email-masked]>;
日 期 ：2021年05月27日 22:08
主 题 ：[Srcomp] Section 2.2.2.1 conclusion
--
Srcomp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/srcomp<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/srcomp__;!!NEt6yMaO-gk!Q1laIX5bOjFZVwSV4gn1aLMDgPOrThQT_elHcpYokt1Y5v1gnC6mE7rUwH3fbPMy$>

Folks,
Darren and I are debating the following conclusion to Section 2.2.2.1. What do you folks think about it?
Ron
Text
------
Table x represents the number of headers parsed for each proposal. Each proposal parses a different number of headers at each segment endpoint. While one proposal may parse a greater number of headers than another, the total work required  may be less because the header contains fewer fields. Furthermore, the impact of headers and fields parsed varies by implementation.
Also, parsing a header generally requires fewer resources than processing it

Juniper Business Use Only

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 2 Jun 2021 08:55:23 +0000

One thing we can assume is that the more header/fields you have to parse the complexity of the implementation increases.

From: Srcomp <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Date: Tuesday, 1 June 2021 at 15:42
To: "Darren Dukes (ddukes)" <ddukes=[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Srcomp] Section 2.2.2.1 conclusion

Folks,

                                                                                         Ron

It looks good for me.

Regards,
PSF

------------------原始邮件------------------
发件人：RonBonica

Folks,