Re: Genart last call review of draft-ietf-manet-dlep-pause-extension-05

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Thanks you for the comments, please see below.

On 3/20/2019 10:33 PM, Dale Worley via Datatracker wrote:
Reviewer: Dale Worley
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document:  draft-ietf-manet-dlep-pause-extension-05
Reviewer:  Dale R. Worley
Review Date:  2019-03-20
IETF LC End Date:  2019-04-03
IESG Telechat date:  [not scheduled]

Summary:

        This draft is basically ready for publication, but has nits
        that should be fixed before publication.  There are a number of
        issues with technical content, but they appear to stem from
        editorial issues, rather than being unsettled technical
        decisions.

* Technical issues:

I notice that the Pause Extension cannot be used by a router to tell a
modem to not send.  I assume that the WG has considered this and has a
good reason for this asymmetry.

This is correct.  It was deemed unneeded complexity for the typical use case where modems have very narrow bandwidth available for transmissions in comparison to other router attached links.


3.1.1.  Queue Parameter Sub Data Item

There need not be a Sub Data Item for a particular queue index.  Such
a queue has no declared size.  OTOH, it has no DSCPs, and so no
traffic can be sent for it, either.

    Queue Parameter Sub Data Items are an unordered list composed of sub
    data items with a common format.  The first sub data item is assigned
    a Queue Index value of 1, and subsequent data items are numbered
    incrementally.  The format of the Queue Parameter Sub Data Item is

    ...

    Queue Index:

       An 8-bit field indicating the queue index of the queue parameter
       represented in the sub data item.

These passages are contradictory.  Either the Sub Data Items are an
ordered list and indexes are assigned to them sequentially, they are
unordered and the indexes are given in the Queue Index subfield, or
the Sub Data Items are required to be in order by their Queue Index
fields.

Good catch - and you are correct.  This is text wasn't modified when we made ordering explicit.

The following will be removed:

   The first sub data item is assigned
   a Queue Index value of 1, and subsequent data items are numbered
   incrementally.


    DS Field Qn:

       The data item contains a sequence of 8 bit DS Fields.  The
       position in the sequence identifies the associated queue index.
       The number of DS Fields present MUST equal the sum of all Num
       DSCPs field values.

This doesn't seem to match the defined format of the Sub Data Items.
The "DS Field Qn" fields contain exactly as many DS Fields as the
value of the Num DSCPs Qn field by definition.  And all of them are
associated with the one Queue Index in the Sub Data Item containing
the DS Field Qn.

Same issue.   Drop:

      The
      position in the sequence identifies the associated queue index.
I note that the Sub Data Items are not padded to a multiple of 4
octets.  I assume this is intended.

Correct, this is consistent with rfc8175.



3.3.  Restart

    The sending of this data item parallels the Pause Data Item, see the
    previous section, and follows the same rules.  This includes that to
    indicate that transmission can resume to all destinations, a modem
    MUST send the Restart Data Item in a Session Update Message.  It also
    includes that to indicate that transmission can resume to a
    particular destination a modem MUST send the Pause Restart Item in a
    Destination Update Message.

Read literally, this means that there is a pause/transmit bit for each
destination/DSCP combination, and that the various messages (pause
vs. restart * Session Update vs. Destination Update * queue index
vs. 255) set some subset of the bits to "pause" or "transmit".  This
is opposed to the model where (to simplify) there is an overall
pause/transmit bit for all traffic and an independent pause/transmit
bit for each destination, and traffic may be sent for a destination
only if both the overall bit and the destination bit are "transmit".

* Editorial issues:

1.  Introduction

    The
    extension also optionally supports DSCP (differentiated services
    codepoint) aware, see [RFC2475], flow control.

The phrasing of this sentence is awkward because of the number of
interpolated phrases.  I suggest something like:

    The extension also optionally supports flow control that is DSCP
    (differentiated services codepoint) aware (see [RFC2475]).

I'll break it into two sentences.


Also, it seems that recent RFCs have tended to capitalize the phrase
"Differentiated Services Code Point".  (Probably check this point with
the Editor.)
I'll defer to the RFC editor.
    Note
    that this mechanism only controls traffic that is to be transmitted
    on the modem's attached data channel and not to DLEP control messages
    themselves.

The parallelism is not correct here, as it would read "this mechanism
... controls ... to DLEP".  Perhaps change to:  "this mechanism only
applies to traffic ...".

Thanks!


2.  Extension Usage and Identification

    To indicate that the Control Plane Based Pause
    Extension is to be used, an implementation MUST include the Control
    Plane Based Pause Extension Type Value in the Extensions Supported
    Data Item.

If I am reading RFC 8175 correctly, this is not exactly true.  Sending
the Value does not compel the peer device to use the Extension.
Instead, "To indicate that the implementation accepts use of the
C.P.B.P.E., an implementation includes ...".

thanks, but will s/accepts/supports.

3.  Extension Data Items

    The Queue Parameters
    Data Item is used by a modem to provide information on the DSCPs it
    uses in forwarding.

Suggest s/information on/information about/.  To me, "information on
the DSCPs" suggests that it will provide a listing of all the DSCPs
that it uses, whereas "information about the DSCPs" suggests that it
will provide attributes of some, but perhaps not all, of the DSCPs.
(Section 3.1 makes clear that the Queue Parameters does not need to
list all DSCPs that are used.)

Done!



3.1.  Queue Parameters

    The Queue Parameters Data Item identifies DSCPs based on groups of
    logical queues, each of which is referred to via a "Queue Index".

"groups of logical queues" isn't correct.  Suggest "The Queue
Parameters Data Item groups DSCPs into logical queues, each of which
is identified by a "Queue Index"."
I like it - thanks!

    An implementation that does not support DSCPs would indicate 1 queue
    with 0 DSCPs, and the number of bytes that may be in its associated
    link transmit queue.

"with 0 DSCPs" is not really correct, since the Queue Parameter
doesn't specify how many DSCPs are included in queue index 0, and
traffic with all values of the DSCP field (which is unexamined by the
device) will be in queue index 0.  I think this phrase should be
omitted.

I think it's cleaner to remove Q0 at this point, it too is a bit vestigial and I think this highlights that having essentially two ways to cover the


          Value  Scale
          ------------
              0   B - Bytes     (Octets)
              1  KB - Kilobytes (B/1024)
              2  MB - Megabytes (KB/1024)
              3  GB - Gigabytes (MB/1024)

I would expect these items to be "1024 B", "1024 KB", etc.  But
perhaps that's because it is ambiguous whether "scale" means the units
in which the measurement is expressed, or the factor by which the
measurement is multiplied by before it is reported.  I would replace
"scale" with "unit", which does not have that ambiguity.  I would also
use the IEC abbreviations:

          Value  Unit
          -----------
              0    B - Bytes     (Octets)
              1  KiB - Kilobytes (1024 B)
              2  MiB - Megabytes (1024 KiB)
              3  GiB - Gigabytes (1024 GiB)

Sure.


    [ISQ-13]   International Electrotechnical Commission, "International
               Standard -- Quantities and units -- Part 13: Information
               science and technology", IEC 80000-13, March 2008.

3.2.  Pause

    The special value of 255 is used to
    indicate that all traffic is to be suppressed.

This implies that a queue index of 255 cannot be used, which is also
implied by the fact that Num Queues = 255 means that only indexes 0 to
254 are in use.  It would be helpful to update 3.1 to make this more
explicit:

    Queue Indexes are numbered sequentially from zero to a maximum of
    254, where queue index zero is a special case covering DSCPs which
    are not otherwise associated with Queue Index.  (Value 255 is used
    to indicate "all queues".)
I'll add text that 255 MUST NOT be used in the Queue Index field.

--

    Queue Index:

       ...  The special value of 255 indicates
       all traffic is to be suppressed to the modem, when the data item
       is carried in a Session Update Message, or a destination, when the
       data item is carried in Destination Update Message.

The parallelism is awkward here.  I think you want to explicitly
parallel "traffic to the modem" and "traffic to a destination":
okay, will make them parallel.
       The special value of 255 indicates all traffic to the modem is
       to be suppressed, when the data item is carried in a Session
       Update Message, or all traffic to a destination, when the data
       item is carried in Destination Update Message.

3.3.  Restart

    Finally, the same rules apply to queue indexes.

Probably better as "Queue indexes are interpreted in the same way as
in the Pause Data Item."

Done.

Look for an update to be published shortly.

Thank you for the comments!

Lou

[END]







[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux