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

"Pengshuping (Peng Shuping)" <pengshuping@huawei.com> Tue, 13 October 2020 09:12 UTC

Return-Path: <pengshuping@huawei.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 DBDBE3A0EF1; Tue, 13 Oct 2020 02:12:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 run-3VsW-Xoc; Tue, 13 Oct 2020 02:12:13 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5B53A0ED6; Tue, 13 Oct 2020 02:12:12 -0700 (PDT)
Received: from lhreml707-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 89478D6F167C23F0AC5A; Tue, 13 Oct 2020 10:12:10 +0100 (IST)
Received: from lhreml707-chm.china.huawei.com (10.201.108.56) by lhreml707-chm.china.huawei.com (10.201.108.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 13 Oct 2020 10:12:10 +0100
Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml707-chm.china.huawei.com (10.201.108.56) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Tue, 13 Oct 2020 10:12:09 +0100
Received: from DGGEML512-MBX.china.huawei.com ([169.254.2.53]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0487.000; Tue, 13 Oct 2020 17:12:06 +0800
From: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
To: Lizhong Jin <lizho.jin@gmail.com>, "tony.li@tony.li" <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>
Thread-Topic: [Network-tokens] [arch-d] Questions for APN: Q#6 and Q#7
Thread-Index: AQHWmS4Gp3g/kyLM2kG5IozrxnFosKmVOpXg
Date: Tue, 13 Oct 2020 09:12:05 +0000
Message-ID: <4278D47A901B3041A737953BAA078ADE1946FD2B@dggeml512-mbx.china.huawei.com>
References: <mailman.493.1601428457.7195.network-tokens@ietf.org> <CAH==cJwKhAZC3VUmeSOLfZ1CCreP9nR-UOgYYgt09HmT6auNBw@mail.gmail.com>
In-Reply-To: <CAH==cJwKhAZC3VUmeSOLfZ1CCreP9nR-UOgYYgt09HmT6auNBw@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.153.195.37]
Content-Type: multipart/alternative; boundary="_000_4278D47A901B3041A737953BAA078ADE1946FD2Bdggeml512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/yUHxJWKRJAWONmUX4cFVQoZsyZA>
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: Tue, 13 Oct 2020 09:12:15 -0000

Hi Tony, Lizhong,

This goes into the details of implementations. Now it is still at the early design stage in IETF and waits for future work.

We also agree that 256B would be too long. The identifier is used for mapping into policies, so only a reasonable length is enough.

Best regards,
Shuping


From: Network-tokens [mailto:network-tokens-bounces@ietf.org] On Behalf Of Lizhong Jin
Sent: Saturday, October 3, 2020 10:36 AM
To: tony.li@tony.li
Cc: apn@ietf.org; Pengshuping (Peng Shuping) <pengshuping@huawei.com>om>; network-tokens@ietf.org; architecture-discuss@iab.org
Subject: Re: [Network-tokens] [arch-d] Questions for APN: Q#6 and Q#7

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<mailto:tony.li@tony.li>
To: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com<mailto:pengshuping@huawei.com>>
Cc: "apn@ietf.org<mailto:apn@ietf.org>" <apn@ietf.org<mailto:apn@ietf.org>>, "network-tokens@ietf.org<mailto:network-tokens@ietf.org>" <network-tokens@ietf.org<mailto:network-tokens@ietf.org>>, "architecture-discuss@iab.org<mailto:architecture-discuss@iab.org>" <architecture-discuss@iab.org<mailto: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