Re: [arch-d] [Network-tokens] Questions for APN: Q#6 and Q#7

tony.li@tony.li Tue, 29 September 2020 21:31 UTC

Return-Path: <tony1athome@gmail.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1403A0EBE for <architecture-discuss@ietfa.amsl.com>; Tue, 29 Sep 2020 14:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.747
X-Spam-Level:
X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ZNJIu7_YMtYR for <architecture-discuss@ietfa.amsl.com>; Tue, 29 Sep 2020 14:31:43 -0700 (PDT)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 D01B13A0EBA for <architecture-discuss@iab.org>; Tue, 29 Sep 2020 14:31:43 -0700 (PDT)
Received: by mail-pf1-x42f.google.com with SMTP id k8so6032760pfk.2 for <architecture-discuss@iab.org>; Tue, 29 Sep 2020 14:31:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=oO0cj+ISEE/ENRdto0+8pNJ/OygXmRVUl8GQvDFrLbE=; b=ihmdv5ThLZJcB/p8KUu+EzqaCZAAqrq9VGVXpfsRGeeKCIQipZ6kFb3aQqU+eccoXr AVukqY47xi6/UzX/TWN6wX1LllUJs+QVredasqqV07pgAe7uSM35ah1FDL8dkkAnh9ta BnQJPa2NgfXq/xuh1PYRDo37Ytg+PIDZML7REtTUFbrGXiS+sZN/E+BdBONjZrCYg09M uU9n/Wii+WeyxJRXPpVJ6I673I7GzJJi58TvWq2UmyURCx9ZA9EXHnRfZO1BvKlIuOlv 9jCWmRjgoT99njsnru+QYZ5odOIuVm/Jy+cJA22T5DuKQR9J7DHGU65mnPxLx09JwAsY LN7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=oO0cj+ISEE/ENRdto0+8pNJ/OygXmRVUl8GQvDFrLbE=; b=DwJVKDg/+W2Ne/riOu4cFhJFOxzhzW0z5zGKZG3dqDkj3lEFzHRad1epHRJb7EwT5t /2/EKRfeXBhtcAy8mO5EKmufZdWOQaHHK9y4AoETPL/fYGRlxEj/jZzNU2AFrQoCKQnN Mbw5LouFsjnaAlwx5Fo2OM/Uut2okH6FWS+W9oavPukqsa5Xk1ptkO+N3RiYLdswTh5P jT1DZDBfKEN/jUgtY2wojSi1nL8kF32bwOTcTi7ma15XeLQaD9N5hODEt9eAcBqTLehb IxxFQ6+Q4tMzYZcj+AHXIDT2rHJxgcHsz75nnQTObhkRCkD/ZNsRlNMgkGO4XP0botf8 0rIA==
X-Gm-Message-State: AOAM5301ZEjOOeaQFcAvDjwe/ocmGGQrG2oXxR+yl9waN23zkc8pOy3g YwcSeIHJQhJ29L11qFWR3gI=
X-Google-Smtp-Source: ABdhPJzUBX+AMoODYjRgHavdwVvR2qb6maHO/fX9KeR7TLuxAaxXMlxlYU+aamiPXt+KkM+Tg0EFxQ==
X-Received: by 2002:a17:902:b203:b029:d2:1ebe:d80c with SMTP id t3-20020a170902b203b02900d21ebed80cmr6497112plr.18.1601415103222; Tue, 29 Sep 2020 14:31:43 -0700 (PDT)
Received: from [192.168.4.24] (c-67-169-103-239.hsd1.ca.comcast.net. [67.169.103.239]) by smtp.gmail.com with ESMTPSA id f6sm6609786pfq.82.2020.09.29.14.31.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Sep 2020 14:31:42 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: tony.li@tony.li
Message-Id: <7CBE7FAD-4544-4DA0-93D5-99BFB09E9AF8@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_24116701-48D8-4864-9955-D25C79E18931"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Tue, 29 Sep 2020 14:31:38 -0700
In-Reply-To: <4278D47A901B3041A737953BAA078ADE19435F17@dggeml512-mbx.china.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>
To: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
References: <4278D47A901B3041A737953BAA078ADE19424A8B@dggeml512-mbx.china.huawei.com> <C2F56D47-ABAE-41C2-9AC9-F74EB7D6A8AE@tony.li> <4278D47A901B3041A737953BAA078ADE19435F17@dggeml512-mbx.china.huawei.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/z3pM7ln2P99mz2Kzu1nxEIjgvqI>
Subject: Re: [arch-d] [Network-tokens] Questions for APN: Q#6 and Q#7
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2020 21:31:47 -0000

Hi Shuping,

> https://tools.ietf.org/html/draft-li-6man-app-aware-ipv6-network-02 <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