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

From: "qiangli (D)" <[email-masked]>
Date: Fri, 8 Mar 2019 01:22:01 +0000

Hi All,

We have uploaded a new draft (draft-qiang-tsvwg-udp-options-bounded-latency-00) that explores the use of UDP options for bounded latency forwarding. Review and comment is highly appreciated.

Best regards,

Cristina QIANG

==============================================

A new version of I-D, draft-qiang-tsvwg-udp-options-bounded-latency-00.txt

has been successfully submitted by Li Qiang and posted to the IETF repository.

Name:               draft-qiang-tsvwg-udp-options-bounded-latency

Revision:  00

Title:                  UDP Options for Bounded Latency

Document date:       2019-03-08

Group:               Individual Submission

Pages:               9

URL:            https://www.ietf.org/internet-drafts/draft-qiang-tsvwg-udp-options-bounded-latency-00.txt

Status:         https://datatracker.ietf.org/doc/draft-qiang-tsvwg-udp-options-bounded-latency/

Htmlized:       https://tools.ietf.org/html/draft-qiang-tsvwg-udp-options-bounded-latency-00

Htmlized:       https://datatracker.ietf.org/doc/html/draft-qiang-tsvwg-udp-options-bounded-latency

Abstract:

   This document explores the use of UDP options for packet forwarding

   with bounded latency.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Joe Touch <[email-masked]>
Date: Thu, 7 Mar 2019 19:43:48 -0800

Two points (the first is useful for everyone developing upcoming UDP options):

1. proposals for new UDP options should indicate a KIND value of “TBD” only; they should not ‘squat’ or preselect a value until assigned by IANA (when the UDP options doc is published) or - until the UDP doc is published - at least the doc is accepted as a WG doc.

2. a request for such assignment should be included in the IANA considerations portion of that document

These are common conventions for assigned numbers in general.

As a result, I encourage the authors to quickly issue an update to this doc that follows the above convention.

Additionally, if accepted, can you explain why it wouldn’t be sufficient to just request the next open value?

Joe

> On Mar 7, 2019, at 5:22 PM, qiangli (D) <[email-masked]> wrote:
> 
> Hi All,
>  
> URL:            https://www.ietf.org/internet-drafts/draft-qiang-tsvwg-udp-options-bounded-latency-00.txt <https://www.ietf.org/internet-drafts/draft-qiang-tsvwg-udp-options-bounded-latency-00.txt>
> Status:         https://datatracker.ietf.org/doc/draft-qiang-tsvwg-udp-options-bounded-latency/ <https://datatracker.ietf.org/doc/draft-qiang-tsvwg-udp-options-bounded-latency/>
> Htmlized:       https://tools.ietf.org/html/draft-qiang-tsvwg-udp-options-bounded-latency-00 <https://tools.ietf.org/html/draft-qiang-tsvwg-udp-options-bounded-latency-00>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-qiang-tsvwg-udp-options-bounded-latency <https://datatracker.ietf.org/doc/html/draft-qiang-tsvwg-udp-options-bounded-latency>
>  
>  
> Abstract:
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>  
> The IETF Secretariat

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 08 Mar 2019 08:19:11 +0000

I'm really encouraging you to do a quick revision: It would be really 
helpful if you did the update suggested by Joe, to align so it's 
conformant with the way in which the assignments are supposed to be made.

A few quick observations on the -00 draft:

(1) Please replace the "KIND" number with the text "TBD", and see Joe's 
comment on the IANA section.

(2) This may is a chance to fix this typo that occurs several places: 
/filed/field/.

(3) Is Length in figure 5 really 1 byte? This is the total length of the 
option, and I see you have at least one byte additional. Is your length 
of the option variable or fixed?

(4) I don't understand this:

   "One way to relieve in-transit rewriting is to pre-compute the sending
    cycles along the way, then carry them with multiple SC options."

I wonder: Do you imagine the path adds options as the packet travels 
through the routers? Or is this a suggestion that the option field can 
have multiple values present within this?  These are quite different 
proposals, and I suggest you place this text in a separate subsection?

Best wishes,

Gorry

On 08/03/2019, 03:43, Joe Touch wrote:
> 1. proposals for new UDP options should indicate a KIND value of “TBD” 
> only; they should not ‘squat’ or preselect a value until assigned by 
> IANA (when the UDP options doc is published) or - until the UDP doc is 
> published - at least the doc is accepted as a WG doc.
>
> As a result, I encourage the authors to quickly issue an update to 
> this doc that follows the above convention.
>
> Additionally, if accepted, can you explain why it wouldn’t be 
> sufficient to just request the next open value?
>
> Joe
>
>> On Mar 7, 2019, at 5:22 PM, qiangli (D) <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi All,
>> We have uploaded a new draft 
>> (draft-qiang-tsvwg-udp-options-bounded-latency-00) that explores the 
>> use of UDP options for bounded latency forwarding. Review and comment 
>> is highly appreciated.
>> Best regards,
>> Cristina QIANG
>> A new version of I-D, 
>> draft-qiang-tsvwg-udp-options-bounded-latency-00.txt
>> URL: 
>> https://www.ietf.org/internet-drafts/draft-qiang-tsvwg-udp-options-bounded-latency-00.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-qiang-tsvwg-udp-options-bounded-latency/
>> Htmlized: 
>> https://tools.ietf.org/html/draft-qiang-tsvwg-udp-options-bounded-latency-00
>> Htmlized: 
>> https://datatracker.ietf.org/doc/html/draft-qiang-tsvwg-udp-options-bounded-latency
>> Abstract:
>> Please note that it may take a couple of minutes from the time of 
>> submission until the htmlized version and diff are available 
>> attools.ietf.org <http://tools.ietf.org/>.
>> The IETF Secretariat
>

---

From: "qiangli (D)" <[email-masked]>
Date: Fri, 8 Mar 2019 10:44:06 +0000

Hi Joe and Gorry,

Thanks a lot for your comments. Will make modification accordingly and update before IETF 104 meeting. 

>>(3) Is Length in figure 5 really 1 byte? This is the total length of the option, and I see you have at least one byte additional. Is your length of the option variable or fixed?

Yes, 1 byte is enough. Since each node has 3 queues, need minimal 2 bits (4 different values) to indicate which queue a packet should enter.

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. 

>> 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, will change "127" to "TBD" in 01 version. Thank you again.

Best regards,

Cristina QIANG

-----Original Message-----
From: Gorry Fairhurst [mailto:[email-masked]] 
Sent: Friday, March 08, 2019 4:19 PM
To: Joe Touch <[email-masked]>
Cc: qiangli (D) <[email-masked]>; Toerless Eckert <[email-masked]>; [email-masked]
Subject: Re: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00)

I'm really encouraging you to do a quick revision: It would be really helpful if you did the update suggested by Joe, to align so it's conformant with the way in which the assignments are supposed to be made.

(1) Please replace the "KIND" number with the text "TBD", and see Joe's comment on the IANA section.

(3) Is Length in figure 5 really 1 byte? This is the total length of the option, and I see you have at least one byte additional. Is your length of the option variable or fixed?

I wonder: Do you imagine the path adds options as the packet travels through the routers? Or is this a suggestion that the option field can have multiple values present within this?  These are quite different proposals, and I suggest you place this text in a separate subsection?

Best wishes,

Gorry

---

From: "Gorry (erg)" <[email-masked]>
Date: Fri, 8 Mar 2019 11:30:04 +0000

See below.

> On 8 Mar 2019, at 10:44, qiangli (D) <[email-masked]> wrote:
> 
> Hi Joe and Gorry,
> 
Great the cutoff is Monday.

> Yes, 1 byte is enough. Since each node has 3 queues, need minimal 2 bits (4 different values) to indicate which queue a packet should enter.
I see.

> We may use STACK method to reduce such " in-transit rewriting ". Will refine this part in 01 version. 
Ah I think changing the value isn’t allowed. The option fields are set by the sender and immutable - they may be readable in path, but the way they are defined does not make it easy or desirable to change along the path.

> The reason that why we wrote "127" is "127-253" is a reserved region defined in draft-ietf-tsvwg-udp-options-06, will change "127" to "TBD" in 01 version.
OK

> Thank you again.
Gorry

---

From: Tom Herbert <[email-masked]>
Date: Fri, 8 Mar 2019 08:02:36 -0800

> We have uploaded a new draft (draft-qiang-tsvwg-udp-options-bounded-latency-00) that explores the use of UDP options for bounded latency forwarding. Review and comment is highly appreciated.
Hi Cristina,

One comment.

>From the draft: "However in an IP data plane, there is no enough space
in the IP common header."

This is what extension headers are designed for. The draft is
describing what should be a new Hop-by-Hop option.

Also, I don't think router vendors are going to be very happy if they
have to start parsing packet trailers in the high performance data
path.

Tom

---

From: Joe Touch <[email-masked]>
Date: Fri, 8 Mar 2019 09:08:49 -0800

Notes below...

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

> 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

---

From: "qiangli (D)" <[email-masked]>
Date: Mon, 11 Mar 2019 01:18:05 +0000

Hi Tom,

I fully agree with you, Hop-by-hop option is an effective way to work in IPv6 scenario, we are also going to work on it, and UDP option is another way. As vendor, we do care about processing performance, and we also value UDP option as a potential way for end-user to express their requirement directly to network, some evaluation test is needed.

Best regards,

Cristina QIANG

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Saturday, March 09, 2019 12:03 AM
To: qiangli (D) <[email-masked]>
Cc: tsvwg <[email-masked]>; Toerless Eckert <[email-masked]>
Subject: Re: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00)

Hi Cristina,

One comment.

From the draft: "However in an IP data plane, there is no enough space in the IP common header."

This is what extension headers are designed for. The draft is describing what should be a new Hop-by-Hop option.

Also, I don't think router vendors are going to be very happy if they have to start parsing packet trailers in the high performance data path.

Tom

---

From: "qiangli (D)" <[email-masked]>
Date: Mon, 11 Mar 2019 01:46:33 +0000

Hi Gorry,

>> Ah I think changing the value isn’t allowed. The option fields are set by the sender and immutable - they may be readable in path, but the way they are defined does not make it easy or desirable t…

We have the same concern on "In-transit rewriting", that's why we specifically wrote the following text in our document:
"If there is only one SC option carried in a packet, the Cycle_Identifier field may need to be rewritten before re-sending out. One way to relieve in-transit rewriting is to pre-compute the sending cycles along the way, then carry them with multiple SC options."

And I was wondering if the proposed solution "pre-compute the sending cycles along the way, then carry them with multiple SC options." is acceptable. Thanks!

Best regards,

Cristina QIANG

-----Original Message-----
From: Gorry (erg) [mailto:[email-masked]] 
Sent: Friday, March 08, 2019 7:30 PM
To: qiangli (D) <[email-masked]>
Cc: Joe Touch <[email-masked]>; Toerless Eckert <[email-masked]>; [email-masked]
Subject: Re: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00)

See below.

I see.

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

OK

Gorry

> Subject: Re: [tsvwg] A New Draft Uploaded 
> (draft-qiang-tsvwg-udp-options-bounded-latency-00)
> 
>> IANA (when the UDP options doc is published) or - until the UDP doc 
>> is published - at least the doc is accepted as a WG doc.
>> 
>>> use of UDP options for bounded latency forwarding. Review and 
>>> comment is highly appreciated.
>>> Best regards,
>>> Cristina QIANG
>>> https://www.ietf.org/internet-drafts/draft-qiang-tsvwg-udp-options-b
>>> o
>>> unded-latency-00.txt
>>> Status: 
>>> https://datatracker.ietf.org/doc/draft-qiang-tsvwg-udp-options-bound
>>> e
>>> d-latency/
>>> Htmlized: 
>>> https://tools.ietf.org/html/draft-qiang-tsvwg-udp-options-bounded-la
>>> t
>>> ency-00
>>> Htmlized: 
>>> https://datatracker.ietf.org/doc/html/draft-qiang-tsvwg-udp-options-
>>> b
>>> ounded-latency
>>> Abstract:

---

From: "qiangli (D)" <[email-masked]>
Date: Mon, 11 Mar 2019 01:53:57 +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:[email-masked]]
Sent: Saturday, March 09, 2019 1:09 AM
To: qiangli (D) <[email-masked]>; [email-masked]
Cc: Toerless Eckert <[email-masked]>; [email-masked]
Subject: Re: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00)

Notes below...

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.

...

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).

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 10 Mar 2019 20:28:15 -0700

On 3/10/2019 6:18 PM, qiangli (D) wrote:
> we also value UDP option as a potential way for end-user to express their requirement directly to network,

This seems misguided to me. Transport headers and options are intended
for endpoints; if you need to express information to the network, it
should be in the network headers.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 10 Mar 2019 20:30:02 -0700

On 3/10/2019 6:53 PM, qiangli (D) wrote:
>  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." ? 

I don't quite understand what you're trying to accomplish.

As per my other note, I don't think transport headers should be used as
a way to communicate with network devices EXCEPT at the endpoints.

So even if the values in the options do not change (is that your intent
above?), I still would not suggest this as a useful UDP option.

Joe