[6lo] Discussion points for draft-ietf-6lo-deadline-time

Charlie Perkins <charles.perkins@earthlink.net> Wed, 21 February 2018 17:55 UTC

DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=jivRKGR5eUdu9+RItkUIk4an2qqQqlR7d/44VOJ3kE+m2VrTc1GGiYnH50GxursLbSHt3HrWDkZUhTTjl5B9oAviyCwWIMkcsTAgGMEo7Cpu+wcw6mwozBlof1s36Y+/Tf5eWW1nNai/a5egn2A8wvpDbrVKb5FILddEJElNeyPydq0QW3Qp2goNzDutU2KMTdwI4sN4cVj6pS6U9XfPlhAkwFzJwBuDBxPn1NfbCmD+8PVB4cNde3hfM9ugn2hIGf/KAuxNAERxkS3a9hvUnuJynQZBmGxhHii6nRuogURr40K48wRXT3bNXk6lop9nopf2vrCqpuaWPn7yqZ3mhA==; h=Received:To:From:Subject:Message-ID:Date:User-Agent:MIME-Version:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP;
To: "6lo@ietf.org" <6lo@ietf.org>
From: Charlie Perkins <charles.perkins@earthlink.net>
Message-ID: <9d4950cf-fd1b-be73-f650-d3d5e9bafa24@earthlink.net>
Date: Wed, 21 Feb 2018 09:55:49 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------AA6E7599762095376E4B13AC"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/fZFtDRS7WAlKuTtUIeVX4mSzzlc>
Subject: [6lo] Discussion points for draft-ietf-6lo-deadline-time
Precedence: list

Hello folks,

In preparation for another revision of our document, we have revisited 
the discussion at IETF 99.  A few of the comments needed more 
discussion, which after discussion can be resolved in the upcoming revision.

> * Kerry Lynn: back to Pascal's question. Not all hops have same "cost" 
> (transit time). Where is time spent? propagation, queuing, ...? 

There are indeed multiple ways that a packet can be delayed, including 
propagation delay and queuing delays.  Sometimes there are processing 
delays as well.  For the purpose of determining whether or not the 
deadline has already passed, these various delays are not 
distinguished.  Maybe a sentence should be added to the draft that 
mentions some of the kinds of delay as just identified.

> * Samita: About time synch mechanism/protocol, any recommendation?

https://tools.ietf.org/html/draft-ietf-detnet-problem-statement-02

contains the following:

“Time synchronization techniques need not be addressed by an IETF
    Working Group; there are a number of standards available for this
    purpose, including IEEE 1588, IEEE 802.1AS, and more.”

I think we can use the same wording, and add the same reference to our 
draft.


> * Gabriel: if D bit set, text says SHOULD drop. Anything bad can 
> happen if implementation does not obey SHOULD? Then maybe turn it into 
> MUST
> * Thomas: Recommend to put MUST.
> * Pascal: This header is optional to process.
> * Suresh: can say MUST, but sender cannot expect it to be observed if 
> intermediate router does not implement this.

All in all, I think that the consensus is to change to "MUST drop".  But:

> * Pascal: application cannot rely that packet will *not* be delivered 
> after deadline. Only use it as "discard preferably to other packets" 
> after deadline.

I also agree with the first sentence.  But, after the deadline I think 
the packet needs to be dropped if only for the purposes of saving 
interference over the air and processing time at the receiver.

Regards,
Charlie P.

[6lo] Discussion points for draft-ietf-6lo-deadli… Charlie Perkins