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

Lizhong Jin <> Sat, 03 October 2020 02:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E8573A17AE for <>; Fri, 2 Oct 2020 19:36:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eVwQfbvacWtP for <>; Fri, 2 Oct 2020 19:36:22 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A2A7A3A17AF for <>; Fri, 2 Oct 2020 19:36:22 -0700 (PDT)
Received: by with SMTP id c2so3349042otp.7 for <>; Fri, 02 Oct 2020 19:36:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X1dc/yrXWqH0o9lW6095wScR9uYooCbKNQHNKVImIQI=; b=QtyFy+0lMf5EZlpjJAK36kYc+PQ1p2LksRp7suCDDlauCjmdW7JGftSUzwnC9m0IfE l+z67LU9Odwd1m/2DxqlgYTbHhFaBlHyvPZXpWE7qEHEVWhgGGQJAKzx5+WDXKgIil1n oZ+xHAQjwlwyVbM7kyBJ9HryUtkQDU3UhVQMY+jC9bhXh8ceYwg8wcShr0dEE5Du57+D v7kSE/4sBZU9ht3a0nR5SSFx4MS226Qg6FY1OOf2SdGuvHGLiJXudH6BdNCoNa7F5VHa RbNyEK0JR+rmAS4PgGbabruqVtWavl3rkPDmXhUioip2tjis/RbDHmjyObMkobk1s8Vv WDVg==
X-Gm-Message-State: AOAM532pJJ4ThzIW54BaUsnqFW6EwFKlp8lxGVki3cXdrr4roBm5t7MC 4bufNtZSdO+VH1F5TP7yaTYEBA3rIZcU1xlQu9M=
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: <>
In-Reply-To: <>
From: Lizhong Jin <>
Date: Fri, 2 Oct 2020 19:36:09 -0700
Message-ID: <>
Cc: "" <>, "" <>, "" <>,
Content-Type: multipart/alternative; boundary="0000000000005338ac05b0bb1d31"
Archived-At: <>
Subject: Re: [arch-d] [Network-tokens] Questions for APN: Q#6 and Q#7
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


---------- Forwarded message ----------
To: "Pengshuping (Peng Shuping)" <>
Cc: "" <>rg>, "" <>gt;, "" <>
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,
> *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*