Re: [Apn] [Network-tokens] [arch-d] Questions for APN: Q#6 and Q#7
Lizhong Jin <lizho.jin@gmail.com> Sat, 03 October 2020 02:36 UTC
Return-Path: <lizho.jin@gmail.com>
X-Original-To: apn@ietfa.amsl.com
Delivered-To: apn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10973A17B0; Fri, 2 Oct 2020 19:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 q-t5tVrirYIC; Fri, 2 Oct 2020 19:36:22 -0700 (PDT)
Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFCCE3A17AE; Fri, 2 Oct 2020 19:36:21 -0700 (PDT)
Received: by mail-ot1-x32c.google.com with SMTP id m13so3336188otl.9; Fri, 02 Oct 2020 19:36:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X1dc/yrXWqH0o9lW6095wScR9uYooCbKNQHNKVImIQI=; b=ZQZ1uVV90RizZkcvGrvWJHqcsoi5pPjr11Xd5VVYkANhY17Rr77LA9cZ4R606wPAPW QPNLcFx1Vdbygkiif722JAPDj/xEg6b8UBrE0eiTzJKV48+EU4wPpwuWa1ftqm1yZhke 15dkF1FeJo9Tl9UFGyypG9rPP/MmXh48w59kXUC7bDbxgLfYHUvT6XnOeHKHC7+5CqxY GWVA6cqO96tuVlEfnzgWVxSJqte4Vcx7gHwYC6/MvSlz+jHFsDt1Rr2KZiBmOeMW9mTF WWX0XcvOTQL0jTk5/cSQH5o/0asxj+fjAsDWcL9I9YL1aterrWNgg+WqOwM14ATGoaCw ZHbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X1dc/yrXWqH0o9lW6095wScR9uYooCbKNQHNKVImIQI=; b=UHwJzaw82Mk0Wd7tR/x71mQ3NG9HUNQ4EWDKugRlBXE/DOovsfz6sWgo8bbnGrl4M0 QoBCpTYAhBq5+CVJWUOnUZu8sZ18aMRQ7VGQEbBqxLeKERcOoraUAyVAA2tbdF5zFobW MtB+OREi48eNfGLZZtgBtD/1lK77jLYP7K/axuc8UCKiPQLSMBulF8e65NUhDHae7HCR bAjcf/LUdJYHs7Q4KhtABIpCPQVeGk0RstuAqo5ufktOLj57wZjGfRsaKpNsP9udgpng pf2lbsULQk6Ib6s3Nogdl2LoRI1tVKHtPfVwPw/nRI97UytZGlWqXg2g0HMIDtYBZkFK PpaA==
X-Gm-Message-State: AOAM533K4tZrPPnQL2gU27z+lG7seghQ+0SMSA0oyr8FTEsRo6duHq8A pE3sVLYHjg/eOTIS07NHT+tEKtjIHg3V3s6/M4c=
X-Google-Smtp-Source: ABdhPJyaUy8zHEy1Pc4SSCc8l2gBQ/DejorJUiB9XkJXb7+s/5JXAdoq3UrQSxtpM8d3s6rwpL6RuIV3bcdxwH7E6UQ=
X-Received: by 2002:a05:6830:12c7:: with SMTP id a7mr4104698otq.334.1601692580918; Fri, 02 Oct 2020 19:36:20 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.493.1601428457.7195.network-tokens@ietf.org>
In-Reply-To: <mailman.493.1601428457.7195.network-tokens@ietf.org>
From: Lizhong Jin <lizho.jin@gmail.com>
Date: Fri, 02 Oct 2020 19:36:09 -0700
Message-ID: <CAH==cJwKhAZC3VUmeSOLfZ1CCreP9nR-UOgYYgt09HmT6auNBw@mail.gmail.com>
To: tony.li@tony.li
Cc: "apn@ietf.org" <apn@ietf.org>, "network-tokens@ietf.org" <network-tokens@ietf.org>, "architecture-discuss@iab.org" <architecture-discuss@iab.org>, pengshuping@huawei.com
Content-Type: multipart/alternative; boundary="0000000000005338ac05b0bb1d31"
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/SM6L27M6qost_o4LeMxgEwTz07I>
Subject: Re: [Apn] [Network-tokens] [arch-d] Questions for APN: Q#6 and Q#7
X-BeenThere: apn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Application-aware Networking <apn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apn>, <mailto:apn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apn/>
List-Post: <mailto:apn@ietf.org>
List-Help: <mailto:apn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apn>, <mailto:apn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Oct 2020 02:36:24 -0000
I believe this is a very initial draft for the authors of *draft-li-6man-app-aware-ipv6-*network-02. Additional 256Bytes for only one option would be a disaster for current various hardware design. Lizhong ---------- Forwarded message ---------- From: tony.li@tony.li To: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com> Cc: "apn@ietf.org" <apn@ietf.org>, "network-tokens@ietf.org" < network-tokens@ietf.org>, "architecture-discuss@iab.org" < architecture-discuss@iab.org> Bcc: Date: Tue, 29 Sep 2020 14:31:38 -0700 Subject: Re: [Network-tokens] [arch-d] Questions for APN: Q#6 and Q#7 > > Hi Shuping, > > https://tools.ietf.org/html/draft-li-6man-app-aware-ipv6-network-02 > > *Basically, the information carried in the IP layer is used for traffic > steering policy selection within a limited APN network domain in order to > guarantee the SLA requirements.* > > > > *I’m a little unclear on what I’m reading, so please pardon some > clarifying questions.* > > *In this document, I’m seeing two options defined for use in IPv6 > extension headers.* > > *The application aware ID option appears to be up to 255 bytes long, > variable length, and consists of three different structures.* > > *How does the forwarding engine determine which structure is in use? Can > this option appear multiple times in the header? * > *Within each structure, the fields are variable length, but there appears > to be no way to determine how long the fields are.* > > *The service-para option appears to be a bit more structured. Again, this > appears to be variable length, up to 255 bytes.* > *Within the option, we have numerous subTLVs. What is the purpose of the > RESERVED fields? If you’re trying to retain alignment,* > *didn’t that go out the window with a two byte option header?* > > *Does the delay sub-TLV indicate the overall path delay? Or the per-hop > delay? If the full path delay, how does a router know* > *whether this has been satisfied? Do systems along the path decrease this > value as the packet is forwarded? How does a router* > *know how much to decrement?* > > *Is 24 bits really necessary for the Delay Variation? Is a jitter of 16s > even meaningful?* > > *The packet loss ratio is a 24 bit (presumably unsigned) value. Is this > an integer? Normally ratios are expressed as a relation between multiple* > *integers. What are the semantics here?* > > *Have you computed the amount of overhead that you will be introducing? It > appears to me that you could easily have 1000 bytes of overhead per > packet. What does * > *this do to service provider bandwidth consumption? What does this do to > the ‘low-latency’ service that you want to provide?* > > *Tony* > > > > > >
- [Apn] Questions for APN: Q#6 and Q#7 Pengshuping (Peng Shuping)
- Re: [Apn] [arch-d] Questions for APN: Q#6 and Q#7 tony.li
- Re: [Apn] [Network-tokens] [arch-d] Questions for… Pengshuping (Peng Shuping)
- Re: [Apn] [Network-tokens] [arch-d] Questions for… tony.li
- Re: [Apn] [Network-tokens] [arch-d] Questions for… Lizhong Jin
- Re: [Apn] [Network-tokens] [arch-d] Questions for… Pengshuping (Peng Shuping)