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*
>
>
>
>
>
>