Re: [Tsv-art] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05

Gorry Fairhurst <> Sat, 20 February 2021 13:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63AD53A13D2; Sat, 20 Feb 2021 05:52:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ie3gll8dSxMT; Sat, 20 Feb 2021 05:52:20 -0800 (PST)
Received: from ( [IPv6:2001:630:42:150::2]) by (Postfix) with ESMTP id 7E3513A13D1; Sat, 20 Feb 2021 05:52:19 -0800 (PST)
Received: from GF-MacBook-Pro.lan ( []) by (Postfix) with ESMTPSA id 50D741B00179; Sat, 20 Feb 2021 13:52:12 +0000 (GMT)
To: Nick Hilliard <>
References: <> <>
From: Gorry Fairhurst <>
Message-ID: <>
Date: Sat, 20 Feb 2021 13:52:11 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------C937E5CB475376C9296E324F"
Content-Language: en-GB
Archived-At: <>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 20 Feb 2021 13:52:23 -0000

On 20/02/2021 12:59, Nick Hilliard wrote:
> Hi Gorry,
> Gorry Fairhurst via Datatracker wrote on 18/02/2021 16:54:
>> * I suggest a more powerful chip design might not have reduced performance, but 
>> would cost more: /but the overall performance of the system will be reduced. / 
>> - so maybe either performance is reduced or the system cost increased?
> The practical issue here is that on all hardware, if you increase the 
> complexity of a pipeline, the performance will be reduced.  This is a 
> statement of what happens in the real world on installed systems.
> The purpose of this ID was to provide an practical overview of the 
> real-world problems that operators are likely to experience, and why 
> they happen, rather than getting into the thornier issue of analysing 
> the what-ifs and wherefores of design choices.  So we deliberately 
> steered clear of value judgements, including the trade-offs between 
> cost, complexity and performance - there's too much scope in there to 
> get lost in the long grass.
> Nick

Yes, I thought that was the intention, although the current text seems 
to me to be describing a tradeoff, and the word "cost" is ambiguous in 
terms of processing resource and manufacture cost, so I agree we could 
do better. The current text says:

    Technical constraints mean that there is a trade-off
    between the amount of data sent to the lookup engine and the overall
    performance of the lookup engine.  If more data is sent, the lookup
    engine can inspect further into the packet, but the overall
    performance of the system will be reduced.  If less data is sent, the
    overall performance of the router will be increased but the packet
    lookup engine may not be able to inspect far enough into a packet to
    determine how it should be handled.

- Maybe "overall performance" isn't the right word here either.
You will know what is best - perhaps this is talking about "packet forwrading rate"?

Best wishes,