IETF Logo Mail Archive

Re: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00)

"qiangli (D)" <qiangli3@huawei.com> Mon, 11 March 2019 01:54 UTC

Return-Path: <qiangli3@huawei.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E126130DE3 for <tsvwg@ietfa.amsl.com>; Sun, 10 Mar 2019 18:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Level:
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 Mn3Co_-PfuGU for <tsvwg@ietfa.amsl.com>; Sun, 10 Mar 2019 18:54:05 -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 C6CD8130E00 for <tsvwg@ietf.org>; Sun, 10 Mar 2019 18:54:03 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id DAFFE32A24566C25C027; Mon, 11 Mar 2019 01:54:01 +0000 (GMT)
Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 11 Mar 2019 01:54:01 +0000
Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Mon, 11 Mar 2019 01:54:01 +0000
Received: from DGGEMI406-HUB.china.huawei.com (10.3.17.144) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Mon, 11 Mar 2019 01:54:00 +0000
Received: from DGGEMI529-MBS.china.huawei.com ([169.254.5.3]) by dggemi406-hub.china.huawei.com ([10.3.17.144]) with mapi id 14.03.0399.000; Mon, 11 Mar 2019 09:53:57 +0800
From: "qiangli (D)" <qiangli3@huawei.com>
To: Joe Touch <touch@strayalpha.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>
CC: Toerless Eckert <tte@cs.fau.de>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00)
Thread-Index: AdTVTUw267hC5GTQTZyGvOBVjR2e1///oZEAgABM8YD//1lE4IABOreA//vD5HA=
Date: Mon, 11 Mar 2019 01:53:57 +0000
Message-ID: <06C389826B926F48A557D5DB5A54C4ED45BF7F98@dggemi529-mbs.china.huawei.com>
References: <06C389826B926F48A557D5DB5A54C4ED45BE93CB@dggemi529-mbs.china.huawei.com> <0EA3C86F-B061-451D-A521-292728788B16@strayalpha.com> <5C82257F.5030505@erg.abdn.ac.uk> <06C389826B926F48A557D5DB5A54C4ED45BE97A1@dggemi529-mbs.china.huawei.com> <7d691ac5-3655-59ac-60cc-221b6a39717e@strayalpha.com>
In-Reply-To: <7d691ac5-3655-59ac-60cc-221b6a39717e@strayalpha.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.163.138]
Content-Type: multipart/alternative; boundary="_000_06C389826B926F48A557D5DB5A54C4ED45BF7F98dggemi529mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/2LpGLtvZNGtIz8PI0qkSc52VG1o>
Subject: Re: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Mar 2019 01:54:08 -0000

Thanks Joe,  may I understand your comments as your support for this approach --- “pre-compute the sending cycles along the way, then carry them with multiple SC options." ?  If that so, I’m glad to make modification accordingly.


>> The values you want to request are from the "unassigned" range.
I see. Thank you!



Best regards,

Cristina QIANG

From: Joe Touch [mailto:touch@strayalpha.com]
Sent: Saturday, March 09, 2019 1:09 AM
To: qiangli (D) <qiangli3@huawei.com>; gorry@erg.abdn.ac.uk
Cc: Toerless Eckert <tte@cs.fau.de>; tsvwg@ietf.org
Subject: Re: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00)


Notes below...
On 3/8/2019 2:44 AM, qiangli (D) wrote:

"One way to relieve in-transit rewriting is to pre-compute the sending

    cycles along the way, then carry them with multiple SC options."



The 2 bits' value will be changed/rewritten hop-by-hop, that is what we call " in-transit rewriting " ---- SWAP method

We may use STACK method to reduce such " in-transit rewriting ". Will refine this part in 01 version.

UDP options MUST NOT change in-transit. (anything that does change in-transit would not be eligible for a UDP option KIND assignment).

So it would be useful for this rev to describe ONLY the case where it is immutable.



why it wouldn’t be sufficient to just request the next open value?

The reason that why we wrote "127" is "127-253" is a reserved region defined in draft-ietf-tsvwg-udp-options-06,

...

I'll note that "reserved" means you won't get those; they're set aside for base protocol extensions (i.e., updates to the UDP option definition itself, rather than individual options).

The values you want to request are from the "unassigned" range.

Joe

v2.23.0 | Report a Bug | By Email