Re: [Dime] Topic 1 of draft-ietf-dime-congestion-flow-attributes-00 - ECE and CWR

[Jouni Korhonen <[e-mail]>]

Brent,

Comments inline.

4/29/2014 5:34 PM, Hirschman, Brent B [CTO] kirjoitti:
> At IETF 89 in London, during the discussion of the
> draft-ietf-dime-congestion-flow-attributes-00.txt, Two areas were
> requested to be investigated further.  We will be addressing them in
> separate email threads to keep the discussion focused on each topic.
> This is Topic 1.
>
> First discussion topic, whether ECE and CWR flags needed to be added to
> this draft.  After further investigation, these flags are already
> included as part of Section 4.1.8.10 or RFC5777.

Correct.

> The TCP-Flag-Type AVP (AVP Code 544) is of type Unsigned32 and
>
>     specifies the TCP control flag types that must be matched.  The first
>
>     16 bits match the TCP header format defined in [RFC3168
> <http://tools.ietf.org/html/rfc3168>], and the
>
>     subsequent 16 bits are unused.  Within the first 16 bits, bits 0 to 3
>
>     are unused and bits 4 to 15 are managed by IANA under the TCP Header
>
>     Flag registry as defined in [RFC3168
> <http://tools.ietf.org/html/rfc3168>].
>
> The support of ECN flags (in this draft) are needed since they were
> omitted in RFC5777:
>
>                  The ECN flags are still required and here is why.  The
> problem is that RFC 2474 (DSCP) update was made prior to 3168.  They

RFC3168 updates RFC2474, thus it is not really an issue that DSCP update 
was done before RFC3168. However, ECN flags are still needed since 
RFC5777 limits ECN use strictly to TCP transport.


> studied and made recommendations for this situation in RFC 3260 Section 4.
>
> The DS Field has a six bit Diffserv Codepoint and two "currently unused"
> bits.
>
> …
>
> It has been pointed out that this leads to inconsistencies and
>
>     ambiguities.  In particular, the "Currently Unused" (CU) bits of the
>
>     DS Field have not been assigned to Diffserv, and subsequent to the
>
>     publication of RFC 2474 <http://tools.ietf.org/html/rfc2474>, they
> were assigned for explicit congestion
>
>     notification, as defined in RFC 3168
> <http://tools.ietf.org/html/rfc3168> [4
> <http://tools.ietf.org/html/rfc3260#ref-4>]
>
> …
>
>     Therefore, for use in future documents, including the next update to
>
> RFC 2474 <http://tools.ietf.org/html/rfc2474>, the following definitions
> should apply:
>
>        -  the Differentiated Services Field (DSField) is the six most
>
>           significant bits of the (former) IPV4 TOS octet or the (former)
>
>           IPV6 Traffic Class octet.
>
>        -  the Differentiated Services Codepoint (DSCP) is a value which
>
>           is encoded in the DS field, and which each DS Node MUST use to
>
>           select the PHB which is to be experienced by each packet it
>
>           forwards.
>
>     The two least significant bits of the IPV4 TOS octet and the IPV6
>
>     Traffic Class octet are not used by Diffserv.
>
>     When RFC 2474 <http://tools.ietf.org/html/rfc2474> is updated,
> consideration should be given to changing
>
>     the designation "currently unused (CU)" to "explicit congestion
>
>     notification (ECN)" and referencing RFC 3168
> <http://tools.ietf.org/html/rfc3168> (or its successor).
>
> Note here they are essentially dropping the “CU” bits in the definition
> itself.  This removes overlap in ECN 3186.
>
> For RFC 5777, the authors wrote the AVP definition for DSCP in such a
> way that it is not impacted so long as the registry is correct from 2474
> and its successors.  Below is the RFC 5777 definition for DSCP.
>
> *4.1.8.1 <http://tools.ietf.org/html/rfc5777#section-4.1.8.1>.
> Diffserv-Code-Point AVP*
>
>     The Diffserv-Code-Point AVP (AVP Code 535) is of type Enumerated and
>
>     specifies the Differentiated Services Field Codepoints to match in
>
>     the IP header.  The values are managed by IANA under the
>
>     Differentiated Services Field Codepoints registry a   The following statement in Section 2.5.1 of the IPv6 addressing
    architecture [RFC4291]:

       For all unicast addresses, except those that start with the binary
       value 000, Interface IDs are required to be 64 bits long and to be
       constructed in Modified EUI-64 format.

    is replaced by:

       For all unicast addresses, except those that start with the binary
       value 000, Interface IDs are required to be 64 bits long.  If
       derived from an IEEE MAC-layer address, they must be constructed
       in Modified EUI-64 format.

    The following statement in Section 2.5.1 of the IPv6 addressing
    architecture [RFC4291] is obsoleted:

       The use of the universal/local bit in the Modified EUI-64 format
       identifier is to allow development of future technology that can
       take advantage of interface identifiers with universal scope.

    As far as is known, no existing implementation will be affected by
    these changes.  The benefit is that future design discussions are
    simplified.gs defined in
>
>     [RFC2474 <http://tools.ietf.org/html/rfc2474>].

Mmm.. right.. One could argue that RFC3168 update to RFC2474 would 
suffice. However, my recollection was that RFC5777 DSCP was really done 
only the 6 DSCP bits in mind (I could remember wrong but the explicit 
RFC2474 reference indicates that). I still think it makes perfect sense 
to have different AVPs for DSCP and ECN for IP header. Otherwise we 
cannot have a rule to match only ECN bits and neglecting other 6 DSCP 
bits, as an example..

- Jouni



>
> The registry is to be updated to exclude the LU/Exp DSCPs from 2474.
> This is specified in RFC 3260.
>
> *8 <http://tools.ietf.org/html/rfc3260#section-8>. IANA Considerations*
>
>     IANA has requested clarification of a point in RFC 2474
> <http://tools.ietf.org/html/rfc2474>, concerning
>
>     registration of experimental/local use DSCPs.  When RFC 2474
> <http://tools.ietf.org/html/rfc2474> is
>
>     revised, the following should be added to Section 6
> <http://tools.ietf.org/html/rfc3260#section-6>:
>
>        IANA is requested to maintain a registry of RECOMMENDED DSCP
>
>        values assigned by standards action.  EXP/LU values are not to be
>
>        registered.
>
> In summary the ECN flags are no longer considered DSCP “CU” bits.  They
> are also not covered any IANA value.  This results in a gap in 5777 and
> requires the update.
>
> */Brent Hirschman/*
>
> Tech Dev Strategist III
>
> Sprint Corporation
>
> 6220 Sprint Parkway
>
> Overland Park, KS 66251//
>
> Office – 913-762-6736
>
> Mobile – 913-593-6221
>
>
> ------------------------------------------------------------------------
>
> This e-mail may contain Sprint proprietary information intended for the
> sole use of the recipient(s). Any use by others is prohibited. If you
> are not the intended recipient, please contact the sender and delete all
> copies of the message.
>
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>