Re: [Lsvr] [Tsv-art] Tsvart early review of draft-ietf-lsvr-l3dl-03
Joerg Ott <ott@in.tum.de> Tue, 26 May 2020 05:51 UTC
Return-Path: <ott@in.tum.de>
X-Original-To: lsvr@ietfa.amsl.com
Delivered-To: lsvr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60943A0B14; Mon, 25 May 2020 22:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUAak7nWy_K9; Mon, 25 May 2020 22:51:26 -0700 (PDT)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.in.tum.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EFE13A0B12; Mon, 25 May 2020 22:51:26 -0700 (PDT)
Received: by mail.in.tum.de (Postfix, from userid 107) id 8521B1C08A3; Tue, 26 May 2020 07:51:23 +0200 (CEST)
Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id 6F33C1C089C; Tue, 26 May 2020 07:51:21 +0200 (CEST) (Extended-Queue-bit tech_dnxmw@fff.in.tum.de)
To: Randy Bush <randy@psg.com>
Cc: tsv-art@ietf.org, lsvr@ietf.org, draft-ietf-lsvr-l3dl.all@ietf.org
References: <158870511665.7532.2079643708622987385@ietfa.amsl.com> <m2sggclma3.wl-randy@psg.com> <c1712c72-fcf1-f2d5-e5ab-f8f4eb3f911d@in.tum.de> <m2y2pibiyd.wl-randy@psg.com> <30b32e49-9781-056d-0542-f736572a2139@in.tum.de> <m28shf2r8n.wl-randy@psg.com>
From: Joerg Ott <ott@in.tum.de>
Message-ID: <0087f88c-d4ef-4bbf-c227-0a208d1a378b@in.tum.de>
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: <m28shf2r8n.wl-randy@psg.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/AXQiqz9LlA3YqSeiVEGAbMcEtAg>
Subject: Re: [Lsvr] [Tsv-art] Tsvart early review of draft-ietf-lsvr-l3dl-03
X-BeenThere: lsvr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Vector Routing <lsvr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsvr>, <mailto:lsvr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsvr/>
List-Post: <mailto:lsvr@ietf.org>
List-Help: <mailto:lsvr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsvr>, <mailto:lsvr-request@ietf.org?subject=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...?
- [Lsvr] Tsvart early review of draft-ietf-lsvr-l3d… Joerg Ott via Datatracker
- Re: [Lsvr] Tsvart early review of draft-ietf-lsvr… Randy Bush
- Re: [Lsvr] [Tsv-art] Tsvart early review of draft… Joerg Ott
- Re: [Lsvr] Tsvart early review of draft-ietf-lsvr… Van De Velde, Gunter (Nokia - BE/Antwerp)
- Re: [Lsvr] [Tsv-art] Tsvart early review of draft… Randy Bush
- Re: [Lsvr] Tsvart early review of draft-ietf-lsvr… Randy Bush
- Re: [Lsvr] Tsvart early review of draft-ietf-lsvr… Randy Bush
- Re: [Lsvr] Tsvart early review of draft-ietf-lsvr… Rob Austein
- Re: [Lsvr] Tsvart early review of draft-ietf-lsvr… Joerg Ott
- Re: [Lsvr] Tsvart early review of draft-ietf-lsvr… Randy Bush
- Re: [Lsvr] [Tsv-art] Tsvart early review of draft… Joerg Ott
- Re: [Lsvr] [Tsv-art] Tsvart early review of draft… Randy Bush
- Re: [Lsvr] [Tsv-art] Tsvart early review of draft… Joerg Ott
- Re: [Lsvr] [Tsv-art] Tsvart early review of draft… Randy Bush
- Re: [Lsvr] [Tsv-art] Tsvart early review of draft… Joerg Ott
- Re: [Lsvr] [Tsv-art] Tsvart early review of draft… Randy Bush