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

["Hirschman, Brent B [CTO]" <[e-mail]>]

I am sure everyone is starting to prepare for Toronto.  I would please request any comments on our draft soon so that I can prepare any special coverage of these topics in our discussion at the Toronto meeting.

Thanks,


Brent Hirschman
Tech Dev Strategist III
Sprint Corporation
6220 Sprint Parkway
Overland Park, KS 66251
Office - 913-762-6736
Mobile - 913-593-6221

From: Hirschman, Brent B [CTO]
Sent: Monday, May 19, 2014 9:55 AM
To: [e-mail]
Cc: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO]
Subject: RE: [Dime] Topic 1 of draft-ietf-dime-congestion-flow-attributes-00 - ECE and CWR

Our request for comments on this draft issue has not had any responses yet.  Please take a look at this straightforward, 6 page draft and provide comments.
I know the overload work is of high importance to the working group.  We feel this draft is complete and need everyone's quick review to capture any areas that need refinement.  Your assistance is appreciated.

Brent Hirschman
Tech Dev Strategist III
Sprint Corporation
6220 Sprint Parkway
Overland Park, KS 66251
Office - 913-762-6736
Mobile - 913-593-6221

From: DiME [mailto:[e-mail]] On Behalf Of Hirschman, Brent B [CTO]
Sent: Tuesday, April 29, 2014 9:34 AM
To: [e-mail]<mailto:[e-mail]>
Cc: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO]
Subject: [Dime] Topic 1 of draft-ietf-dime-congestion-flow-attributes-00 - ECE and CWR

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.
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 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 as defined in
   [RFC2474<http://tools.ietf.org/html/rfc2474>].

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.

________________________________

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.