Re: [Tsv-art] Tsvart early review of draft-ietf-lsvr-l3dl-03

Joerg Ott <> Tue, 26 May 2020 05:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A60943A0B14; Mon, 25 May 2020 22:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 dUAak7nWy_K9; Mon, 25 May 2020 22:51:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9EFE13A0B12; Mon, 25 May 2020 22:51:26 -0700 (PDT)
Received: by (Postfix, from userid 107) id 8521B1C08A3; Tue, 26 May 2020 07:51:23 +0200 (CEST)
Received: (Authenticated sender: ott) by (Postfix) with ESMTPSA id 6F33C1C089C; Tue, 26 May 2020 07:51:21 +0200 (CEST) (Extended-Queue-bit
To: Randy Bush <>
References: <> <> <> <> <> <>
From: Joerg Ott <>
Message-ID: <>
Date: Tue, 26 May 2020 07:51:20 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-lsvr-l3dl-03
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: Tue, 26 May 2020 05:51:31 -0000

On 26.05.20 07:35, Randy Bush wrote:
>>>>>> 3. When the protocol applies fragmentation, should there be a note on
>>>>>> preventing bursts?
>>>>> likely part of this is our fault, as we did not mean 'fragmentation' in
>>>>> the classic "oops!  we found a hop with a small mtu."
>>>> I didn't take it to mean classic fragmentation but rather ALF-style
>>>> operation.  Still, this could generate bursts depending on how much
>>>> information there is to 'fragment'.
>>> yes, it is app level framing.  perhaps we should call it that explicitly
>>> or even segmentataion or some term less well known.
>>> do you perhaps have a specific suggestion?
>> Not really.  This all appears artificial if you need two or three
>> packets for app layer fragmentation.  Maybe one could write something
>> substantially improved along the lines of:
>> To prevent packet bursts, a sender SHOULD pace the transmission of
>> application layer fragmented data units as follows: A sender MAY
>> transmit up to K packets containing fragments in a burst and SHOULD
>> pace bursts ... (but how?)
> ok.  i have stared at this three times today and have no bright ideas.
> i do not want to start pacing by measuring rtt or other known deep
> holes.  so i will try to think some more.

One option could be to just have a note of warning.  Any ideas how big
your application layer messages will usually get...?