Opened 10 years ago

Closed 10 years ago

#241 closed protocol enhancement (fixed)

Proxy Safe & Cache Key indication for options

Reported by: zach@… Owned by: zach@…
Priority: minor Milestone: post-WGLC-1
Component: coap Version: coap-09
Severity: - Keywords:
Cc:

Description

As a conclusion to the Ticket #230 discussion in the June 4th interim call, we decided to solve the identification of options that a proxy can safely forward even if not understood.

Proposal made that we have a rule that “safe to forward without understanding options” have a number of something like option number mod 7 = 5. (of course more thought on 7 and 5 but you get the idea)

Attachments (1)

coap-12-options.xlsx (46.6 KB) - added by zach@… 10 years ago.
Added by email2trac

Download all attachments as: .zip

Change History (11)

comment:1 Changed 10 years ago by zach@…

Text for a new Proxy-Elective class added to r685. Defined Proxy-Elective in the terminology, the Options section and the Proxy section. Left the formula for determining Proxy-Elective options TBD for now. As they are elective it would make sense for them to be even.

Question: Can we identify any existing Proxy-Elective options already defined in the CoAP draft?

comment:2 Changed 10 years ago by zach@…

  • Summary changed from Proxy safe to forward options to Proxy Safe & Cache Key indication for options

comment:3 Changed 10 years ago by zach@…

Klaus pointed out that in addition to the proxy safe to forward, an indication of inclusion in the cache key would be needed. In addition, it was pointed out the this "Proxy Safe" indication is needed for both elective and critical options. This means we would have to deal with three pieces of information:

  • Critial / Elective
  • Proxy Safe
  • Cache Key

We propose that these can be handled using the last 3 LSB bits of the option number (not the delta), where Critical/Elective? is masked on the first LSB (as it is now), Proxy Safe on the second LSB (every other two options), and Cache Key on the third LSB (every other four options).

On initial indication of which current options might be Proxy Safe or Cache Key was compiled by Klaus (needs to be double-checked):

+-------+--------+-----+----+--------+-------------+
|Request|Response|Cache|Safe|Critical|Name         |
+-------+--------+-----+----+--------+-------------+
|   -   |   X    |  -  | X  |    X   |Content-Type |
|   -   |   X    |  -  | -  |    -   |Max-Age      |
|   X   |   -    |  X  | -  |    X   |Proxy-Uri    |
|   X   |   X    |  X  | X  |    -   |ETag         |
|   X   |   -    |  X  | X  |    X   |Uri-*        |
|   -   |   X    |  -  | X  |    -   |Location-*   |
|   X   |   X    |  -  | -  |    -   |Observe      |
|   X   |   X    |  -  | -  |    X   |Token        |
|   X   |   -    |  X  | X  |    -   |Accept       |
|   X   |   -    |  X  | X  |    X   |If-Match     |
|   X   |   X    |  -  | X  |    -   |Vendor       |
|   X   |   X    |  -  | -  |    X   |Block2       |
|   X   |   X    |  -  | X  |    -   |Size         |
|   X   |   X    |  -  | -  |    X   |Block1       |
|   X   |   -    |  X  | X  |    X   |If-None-Match|
+-------+--------+-----+----+--------+-------------+ 

If we implement this ticket, it has two consequences:

  1. Most options numbers will be re-assigned to match the masks
  2. Ticket #230 (http://trac.tools.ietf.org/wg/core/trac/ticket/230) should be re-thought as with all Uri-* and Location-* options the new masks require option #s into the 50s. If the Uri and Location URIs would require a single option, we are only into the 20s as now. See a proposed solution in Ticket #230.


comment:4 Changed 10 years ago by zach@…

Comment from Carsten:

I think we need to discuss the meaningful combinations here.
For instance, for a critical, non-safe-to-be-forwarded-without-knowing-it option, it is simply not necessary to indicate in the option number whether it is a cache key or not (everybody handling this option knows that), so we are free to use the bit at will.
The cache key property is only relevant for requests, anyway?
I don't understand what "Cache" means for repeatable options (e.g., Accept).
We don't have a Cache-key/non-safe/elective combination. Just luck?
I'm not sure I understand the difference between the bits of Uri* and *Uri.
It may be necessary to rip apart options where the request usage has different semantics from the response usage.
We may need vendor options for all meaningful combinations of bits.
I would prefer to have a set bit for "unsafe" instead of "safe" (if we have a bit for "critical" instead of "elective").

If we go this route, we probably should look at all options proposed so far (see the registry table in the SVN) and guess what combinations are how likely. That will enable us to come up with a good encoding.

comment:5 Changed 10 years ago by hartke@…

  • Milestone set to post-WGLC-1
  • Version set to coap-09

comment:6 Changed 10 years ago by esko.dijk@…

Maybe already indicated by Carsten above; but here goes:
In my view there's no Safe/Unsafe? bit needed in the encoding for critical options. An intermediary already has to understand all criticial options before processing a request, so it can have hardcoded knowledge which ones are Safe/Unsafe?. No need to use encoding bits in that case.

comment:7 Changed 10 years ago by zach@…

Consensus of IETF Vancouver WG meeting was:

  • Use the new option number encoding with Critial/Elective?, Safe to Forward and Cache-key and re-number the options appropriately as presented by Carsten.

comment:8 Changed 10 years ago by esko.dijk@…

Just noting that with Carsten's proposal, the section 5.4.1 defined behaviour is then only applicable to "non-proxying" endpoints. Proxies (which are also endpoints) have different rules using the Safe/Unsafe? bit as in slide 21 of IETF84 presentation http://www.ietf.org/proceedings/84/slides/slides-84-core-0.pdf

comment:9 Changed 10 years ago by zach@…

Message received by email on Mon, 24 Sep 2012 11:06:12 +0000, inserted by email2trac:

Hi,

I have been working on integrating the Option re-numbering into coap-12, and
have done an analysis based on the original proposal from Carsten presented
in Vancouver. That proposal was already pretty good, but some adjustments
were made to optimize for the most commonly used option combinations. Based
on that optimization I am proposing the following numbering. This takes into
account Critical, Unsafe and Cache-key encoding. This re-numbering requires
the use of Jump only in a couple response combinations where there is no
payload and when doing Proxy-Uri requests. In those situations overhead is
not an issue as there is no payload in the message, so the extra byte from
including a Jump is reasonable.

Attached is the spreadsheet that was used to calculate the option numbers,
and check that the option combinations were optimal (avoiding Jump where
possible).

Note that also Observe and Block options are affected by the renumbering (and
thus updated drafts will be submitted in conjunction with the coap-12
submission).

Zach

coap-12-options.xlsx


   +-----+---+---+---+----------------+--------+--------+-------------+
   | No. | C | U | R | Name           | Format | Length | Default     |
   +-----+---+---+---+----------------+--------+--------+-------------+
   |   1 | x |   | x | If-Match       | opaque | 0-8    | (none)      |
   |   2 |   | x |   | Max-Age        | uint   | 0-4    | 60          |
   |   3 | x | x |   | Uri-Host       | string | 1-255  | (see below) |
   |   4 | x |   |   | Content-Type   | uint   | 0-2    | (none)      |
   |   5 | x |   |   | If-None-Match  | empty  | 0      | (none)      |
   |   7 | x | x |   | Uri-Port       | uint   | 0-2    | (see below) |
   |   8 |   |   | x | ETag           | opaque | 1-8    | (none)      |
   |  11 | x | x | x | Uri-Path       | string | 0-255  | (none)      |
   |  12 |   |   | x | Accept         | uint   | 0-2    | (none)      |
   |  15 | x | x | x | Uri-Query      | string | 1-255  | (none)      |
   |  16 |   |   | x | Location-Path  | string | 0-255  | (none)      |
   |  19 | x | x |   | Token          | opaque | 1-8    | (empty)     |
   |  20 |   |   | x | Location-Query | string | 0-255  | (none)      |
   |  35 | x | x |   | Proxy-Uri      | string | 1-1034 | (none)      |
   +-----+---+---+---+----------------+--------+--------+-------------+

                    C=Critical, U=Unsafe, R=Repeatable

                             Table 1: Options

On Sep 10, 2012, at 11:35 AM, core issue tracker wrote:

Changed 10 years ago by zach@…

Added by email2trac

comment:10 Changed 10 years ago by zach@…

  • Resolution set to fixed
  • Status changed from new to closed

Done in coap-12.

Note: See TracTickets for help on using tickets.