Re: [Srcomp] REQ-7-27-COMPRESS-01

[Ron Bonica <[e-mail]>]

Cheng,

So, maybe the metric is a table like the following:


  *   SR path contains 1 SID - R must not exceed X bits
  *   SR path contains 2 SIDs - R must not exceed Y bits
  *   SR path contains 3 SIDx - R must not exceed X bits
  *   Etc...

                                                       Ron




Juniper Business Use Only
From: Chengli (Cheng Li) <[e-mail]>
Sent: Monday, August 3, 2020 10:14 PM
To: Ron Bonica <[e-mail]>; Ron Bonica <rbonica=[e-mail]>; Darren Dukes (ddukes) <ddukes=[e-mail]>; Darren Dukes (ddukes) <[e-mail]>; [e-mail]
Subject: RE: REQ-7-27-COMPRESS-01

[External Email. Be cautious of content]

Hi Ron,

I do NOT mean R MUST NOT exceed a number. Because it depends on the number of SIDs. More SIDs, bigger R. Like 5 SIDs, assuming that R is 80 bytes, while 10 SIDs, R is 112 Byes.

So we need to find out the number of SIDs when the R exceeds the critical number X of bits.
For example, the R of solution A will exceed the X when 10 SIDs are encapsulated. The R of solution B will exceed the X when 15 SIDs are encapsulated.

Can we call this SID number as Maximum SID Depth(MSD) to be inspect in a time?

Cheng



From: Ron Bonica [mailto:[e-mail]]
Sent: Tuesday, August 4, 2020 2:56 AM
To: Chengli (Cheng Li) <[e-mail]<mailto:[e-mail]>>; Ron Bonica <rbonica=[e-mail]<mailto:rbonica=[e-mail]>>; Darren Dukes (ddukes) <ddukes=[e-mail]<mailto:ddukes=[e-mail]>>; Darren Dukes (ddukes) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: REQ-7-27-COMPRESS-01

Cheng,

If I am reading your email correctly, you are proposing a separate, but extremely important requirement. That is.  R must not exceed some critical number of bits.

Am I interpreting your message correctly?

                                                                                  Ron



Juniper Business Use Only
From: Srcomp <[e-mail]<mailto:[e-mail]>> On Behalf Of Chengli (Cheng Li)
Sent: Monday, August 3, 2020 9:06 AM
To: Ron Bonica <rbonica=[e-mail]<mailto:rbonica=[e-mail]>>; Darren Dukes (ddukes) <ddukes=[e-mail]<mailto:ddukes=[e-mail]>>; Darren Dukes (ddukes) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Srcomp] REQ-7-27-COMPRESS-01

[External Email. Be cautious of content]

Hi team,

We may need to maintain the R and P rather than providing the R/P only.

Because we need to compare R with the on-chip memory copy packet windows.  This is a really important factor for analyzing the solutions. If the R is large than the size of packet windows, then node should recircle to read the SID, which will make almost 50% forwarding efficiency drop.  Comparing to this, I don't really care the minor differences in overhead among solutions actually.

Thanks,
Cheng




From: Srcomp [mailto:[e-mail]] On Behalf Of Ron Bonica
Sent: Friday, July 31, 2020 1:26 AM
To: Darren Dukes (ddukes) <ddukes=[e-mail]<mailto:ddukes=[e-mail]>>; Darren Dukes (ddukes) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Srcomp] REQ-7-27-COMPRESS-01

Darren,

We are getting closer, but there is still room for refinement.

This requirement is all about metrics. So, have to:


  *   Measure the right thing
  *   Measure it correctly

I think we are measuring a compression factor. The compression factor is R divided by P where:


  *   R is the IPv6 overhead required to represent an SR path (measured in bits)
  *   P is the amount of information  in an SR path (also measured in bits)

See below for a discussion of how to calculate P.

If you want, you can include RFC 7855 as one of the proposed solutions. That way, you can see how each proposed solution compares to RFC 7855 without measuring it in terms of 7855.

                                                                                              Ron



Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes=[e-mail]<mailto:ddukes=[e-mail]>>
Sent: Thursday, July 30, 2020 6:27 AM
To: Ron Bonica <[e-mail]<mailto:[e-mail]>>; Darren Dukes (ddukes) <[e-mail]<mailto:ddukes@cisco..com>>; [e-mail]<mailto:[e-mail]>
Subject: Re: REQ-7-27-COMPRESS-01

[External Email. Be cautious of content]

Hi Ron and Sander, I think we are saying the same thing but slightly differently.
I'm going to assume all proposals encapsulate in an outer IPv6 header and "other stuff" to carry segments.  I believe this requirement has been proposed.

Without constraining how a proposal defines its encapsulating IPv6 header, the description can be written as:
When encapsulating a packet traversing an SR domain, the size of a proposal's encapsulating IPv6 header MUST be reduced vs the currently defined SRv6 encapsulating IPv6 header.  The size of the encapsulating header is measured in bytes from the start of the encapsulating IPv6 header to the start of the encapsulated packet header.

What do you think of this?  I believe it's more explicit and there is no assumption that a proposal must be compliant or compatible with SRv6.

Darren
________________________________
From: Srcomp <[e-mail]<mailto:[e-mail]>> on behalf of Ron Bonica <rbonica=40juniper.net@dmarc..ietf.org<mailto:rbonica=40juniper.net@dmarc..ietf.org>>
Sent: Wednesday, July 29, 2020 2:35 PM
To: Darren Dukes (ddukes) <ddukes=[e-mail]<mailto:ddukes=[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Srcomp] REQ-7-27-COMPRESS-01


Darren,



I think that the goal is laudable. However, I think that there is a more solution-neutral way to measure compression efficiency.. Consider that:



  *   An SR path is a series of segments.
  *   Each segment is an instruction.
  *   The information of an instruction can be measured in bits. For example:

     *   The information value of a service instruction is greater than 20 bits (REQ-7-27-SVC-SCALE-00)
     *   The information value of a node instruction is equal to the number of bits in a locator (between 48 and 128?)
     *   The information value of an adjacency instruction is equal to the number of bits in a locator (between 48 and 128?) plus 16 bits (REQ-7-27-LINK-SCALE-00)



So, the information value of an SR path (P) is equal to the sum of the information values of its segments.



A compression mechanism produces a particular compression header for a particular SR path. So, we can create a table with the following columns:



  *   Compression mechanism
  *   SR path (described as a sequence segment types)
  *   Compression header length
  *   Encoding efficiency



In this table, Encoding efficiency is equal to compression header length divided by P.



                                                                                                         Ron

















Juniper Business Use Only

From: Srcomp <[e-mail]<mailto:[e-mail]>> On Behalf Of Darren Dukes (ddukes)
Sent: Tuesday, July 28, 2020 12:01 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [Srcomp] REQ-7-27-COMPRESS-01



[External Email. Be cautious of content]



COMPRESS, Encapsulation Compression



Description:

A solution to compress SR for the IPv6 data plane MUST support efficient SRv6 encapsulating header compression.



Rationale:

The compression of SRv6 is the primary goal of the SR compression design team.



Metric:

Compression is the ratio of the IPv6 encapsulation size of SRv6 as defined in RFC8402, RFC8754, draft-ietf-spring-srv6-network-programming vs the IPv6 encapsulation size of a given proposal.

The encapsulation savings of a compression proposal vs the SRv6 base is a useful measurement to compare proposals.

The encapsulation metric (E) records the number of bytes required for a proposal to encapsulate a packet given a specific segment list.

  I.e. E(proposal, segment list)

The encapsulation savings  (ES) records the encapsulation savings for a proposal to encapsulate a packet given a specific segment list.

  I.e. ES(proposal, segment list) = 1 - E(proposal, segment list)/E(SRv6 base, segment list)