Re: [Tsv-art] Tsvart early review of draft-ietf-lsvr-l3dl-03
Joerg Ott <ott@in.tum.de> Mon, 25 May 2020 19:27 UTC
Return-Path: <ott@in.tum.de>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523E63A0903; Mon, 25 May 2020 12:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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, URIBL_BLOCKED=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 VxRD7s0llOxr; Mon, 25 May 2020 12:27:19 -0700 (PDT)
Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.in.tum.de [131.159.0.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31233A08F0; Mon, 25 May 2020 12:27:18 -0700 (PDT)
Received: by mail.in.tum.de (Postfix, from userid 107) id EF39E1C08A2; Mon, 25 May 2020 21:27:14 +0200 (CEST)
Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id 2FF841C088D; Mon, 25 May 2020 21:27:12 +0200 (CEST) (Extended-Queue-bit tech_ykwmw@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>
From: Joerg Ott <ott@in.tum.de>
Message-ID: <30b32e49-9781-056d-0542-f736572a2139@in.tum.de>
Date: Mon, 25 May 2020 21:27:11 +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: <m2y2pibiyd.wl-randy@psg.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/S3Y1wuOsbujAjf1W8fCNKJvelwQ>
Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-lsvr-l3dl-03
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 May 2020 19:27:23 -0000
No worries, I am happy about any break I get... On 23.05.20 20:32, Randy Bush wrote: > sorry to take a while to get back to this. your review is really > appreciated. > > i think we converged on most things. the following seemed open. > >>>> 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?) >>>> Section 7 on the checksum needs more detail. >>> >>> could you be more specific re in what area? >> >> Let me go back: >> >> The code is fine (and certainly a good idea). I was kind of expecting >> the code to be described in text, but given the code is there, the >> concise description is fine. Except that I got confused by >> "repeat until zero". What should be zero? Looking at the code, surely >> not the result. > > :) > > Sum up 32-bit unsigned ints in a 64-bit long, then take the > high-order section, shift it right filling on the left with zeros, > rotate, add it in, repeat until the high order 32 bits are all zero. Sold :-) >>>> Also wondering if repeated retries (due to failure, not lost packets) >>>> could yield fast repeated transmissions. >>> >>> could you be specific about what you think could be improved in >> >> I was trying to decipher my handwriting on the tablet, and it appears to >> say "wait before retry to prevent fast loops", scribbled on the bottom >> of p.22. I had to go back tot he text and I believe this refers back to >> p.18, first para: >> >> "The Key is specific to the operational environment. A failure to >> authenticate is a failure to start the L3DL session, an ERROR PDU >> MUST BE sent (Error Code 3), and HELLOs MUST be restarted." >> >> If you have a systematic auth failure, this would cause HELLOs to be >> restarted. Without any jittering (now you introduced some above), >> you could, in principle, get a loop: >> >> HELLO -> OPEN -> (Auth) ERROR -> HELLO -> OPEN -> (Auth) ERROR -> ... >> >> So misconfig could be bad unless there is some delay built in. > > so i added > > Although delay and jitter in responding with an OPEN were specified > above, beware of load created by long strings of authentication > failures and retries. > > but i am unsure of what action to recommend. Count to N, raise an alert, pause. Or something like this? >>> pre-published text and xml are at https://git.rg.net/randy/draft-l3dl > > still holds true Thanks -- best, Jörg
- [Tsv-art] Tsvart early review of draft-ietf-lsvr-… Joerg Ott via Datatracker
- Re: [Tsv-art] Tsvart early review of draft-ietf-l… Randy Bush
- Re: [Tsv-art] Tsvart early review of draft-ietf-l… Joerg Ott
- Re: [Tsv-art] Tsvart early review of draft-ietf-l… Van De Velde, Gunter (Nokia - BE/Antwerp)
- Re: [Tsv-art] Tsvart early review of draft-ietf-l… Randy Bush
- Re: [Tsv-art] Tsvart early review of draft-ietf-l… Randy Bush
- Re: [Tsv-art] Tsvart early review of draft-ietf-l… Randy Bush
- Re: [Tsv-art] Tsvart early review of draft-ietf-l… Rob Austein
- Re: [Tsv-art] Tsvart early review of draft-ietf-l… Joerg Ott
- Re: [Tsv-art] Tsvart early review of draft-ietf-l… Randy Bush
- Re: [Tsv-art] Tsvart early review of draft-ietf-l… Joerg Ott
- Re: [Tsv-art] Tsvart early review of draft-ietf-l… Randy Bush
- Re: [Tsv-art] Tsvart early review of draft-ietf-l… Joerg Ott
- Re: [Tsv-art] Tsvart early review of draft-ietf-l… Randy Bush
- Re: [Tsv-art] Tsvart early review of draft-ietf-l… Joerg Ott
- Re: [Tsv-art] Tsvart early review of draft-ietf-l… Randy Bush