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

["Darren Dukes (ddukes)" <[e-mail]>]

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]> on behalf of Ron Bonica <rbonica=[e-mail]>
Sent: Wednesday, July 29, 2020 2:35 PM
To: Darren Dukes (ddukes) <ddukes=[e-mail]>; [e-mail] <[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]> On Behalf Of Darren Dukes (ddukes)
Sent: Tuesday, July 28, 2020 12:01 AM
To: [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)