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

["qiangli (D)" <[e-mail]>]

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 to change along the path.

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:[e-mail]] 
Sent: Friday, March 08, 2019 7:30 PM
To: qiangli (D) <[e-mail]>
Cc: Joe Touch <[e-mail]>; Toerless Eckert <[e-mail]>; [e-mail]
Subject: Re: [tsvwg] A New Draft Uploaded (draft-qiang-tsvwg-udp-options-bounded-latency-00)

See below.

> On 8 Mar 2019, at 10:44, qiangli (D) <[e-mail]> wrote:
> 
> Hi Joe and Gorry,
> 
> Thanks a lot for your comments. Will make modification accordingly and update before IETF 104 meeting. 
> 
Great the cutoff is Monday.

>>> (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.
> 
I see.

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

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

> Thank you again.
> 
> 
> Best regards,
> 
> Cristina QIANG
> 
Gorry

> 
> -----Original Message-----
> From: Gorry Fairhurst [mailto:[e-mail]]
> Sent: Friday, March 08, 2019 4:19 PM
> To: Joe Touch <[e-mail]>
> Cc: qiangli (D) <[e-mail]>; Toerless Eckert 
> <[e-mail]>; [e-mail]
> 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.
> 
> 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:
>> 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) <[e-mail] 
>>> <mailto:[e-mail]>> 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
>>> 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-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:
>>>   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 
>>> attools.ietf.org <http://tools.ietf.org/>.
>>> The IETF Secretariat
>> 
>