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

["Gorry (erg)" <[e-mail]>]

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-bo
>>> unded-latency-00.txt
>>> Status: 
>>> https://datatracker.ietf.org/doc/draft-qiang-tsvwg-udp-options-bounde
>>> d-latency/
>>> Htmlized: 
>>> https://tools.ietf.org/html/draft-qiang-tsvwg-udp-options-bounded-lat
>>> 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
>> 
>