Subject: Re: [Tsv-art] Common TSV issues

From: Bob Briscoe <[email-masked]>
Date: Thu, 5 May 2016 17:22:41 +0100

Folks,

+1 re Joe's comment about reordering the list a bit after the deadline.

Some bullet points that might prompt others to have ideas, written in 
haste - I'll try to generalise them and add more/better RFC refs when I 
add them to the wiki later - once I've finished what I'm meant to be doing:
* Forward compatibility
   - for CU or Reserved fields/codepoints, ensure behaviour is defined 
if a field value is not as specified.
* Path traversal of protocol updates
   - {detection of | resilience against| fallback from} middlebox 
interference, asymmetric interference, etc. RFC6824#section-6, other RFC(s)?
   - offload hardware
* Units
   - byte vs pkt congestion rfc7141
   - ?
* Diffserv
   - codepoint scarcity
   - path traversal assumptions
* propagation of transport-related fields on tunnel encap/decap 
(RFC2983, RFC6040)
* Shared use of experimental option values [RFC6994]
* Scarce (TCP) option space
* Collisions / wrap of fields [RFC4963, RFC6864]
* Design for low latency
   - optimistic negotiation, etc

Bob

On 29/04/16 19:13, Black, David wrote:
>
> I’ve added my relevant suggestions from this thread.
>
> Thanks, --David
>
> *From:*Joe Touch [mailto:[email-masked]]
> *Sent:* Monday, April 25, 2016 6:07 PM
> *To:* Spencer Dawkins at IETF; Black, David
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [Tsv-art] Common TSV issues
>
> Also, it might be good to consider reorganzing the list into some sort 
> of taxonomy. I had a draft of this sort of thing I had been preparing 
> for TSV-AREA at one point. Let me know if it would be useful to dig out.
>
> Joe
>
> On 4/25/2016 12:35 PM, Joe Touch wrote:
>
>     FWIW - I added a handful of things this AM...
>
>     Joe
>
>     On 4/25/2016 12:03 PM, Spencer Dawkins at IETF wrote:
>
>         Hi, David,
>
>         On Mon, Apr 25, 2016 at 1:19 PM, Black, David
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi Spencer,
>
>         Here are a few suggestions:
>
>         -- Use of UDP
>
>         I’d reference the rfc5405bis draft for which publication has
>         been requested in addition to RFC 5405, as it contains a lot
>         of added content (this should be “instead of RFC 5405” after
>         IESG approval of the bis draft).  There are a lot of things in
>         this draft that could be called out e.g., reinvention of
>         congestion control is strongly discouraged.
>
>         Thanks for the other suggestions, too, but 5405bis was so
>         obvious that I feel like a moron for not updating the
>         checklist to include it :-)
>
>         Others?
>
>         Spencer
>
>             We now recognize “Controlled Environments” as restricted
>             deployment/applicability scenarios where general Internet
>             requirements (e.g., for congestion control) may be relaxed
>             under suitable (e.g., operator) control - see section 3.6
>             of the rfc5405bis draft for discussion and RFC 7510
>             (MPLS/UDP) for a worked example.
>
>             Use of zero UDP checksums with IPv6 is subtle and requires
>             design attention - see RFC 6935 and 6936.  Note that these
>             two RFCs contain design requirements, so it’s insufficient
>             to just normatively reference those two RFCs and impose
>             their requirements - an explanation of how the protocol
>             design (for zero UDP checksums with IPv6 meets those
>             requirements is needed).  RFC 7510 is also a worked
>             example here, and its content on this topic is not short.
>
>             -- PDU Sizes
>
>             I’d add a discussion of PMTUD and PLPMTUD, including
>             noting that use of the latter needs to include an
>             explanation of how. Use of the former needs to be
>             cognizant of the general unreliability of ICMP Packet Too
>             Big notifications, especially when sent upstream from
>             within a tunnel (may not propagate across ingress).
>
>             -- Multicast
>
>             Many of the concerns may be exacerbated by multicast -
>             perhaps someone who spends more time on multicast than I
>             do could come up with a short list of things to watch out for.
>
>             Thanks, --David
>
>             *From:*Tsv-art [mailto:[email-masked]
>             <mailto:[email-masked]>] *On Behalf Of *Spencer
>             Dawkins at IETF
>             *Sent:* Monday, April 25, 2016 10:29 AM
>             *To:* [email-masked] <mailto:[email-masked]>
>             *Subject:* [Tsv-art] Common TSV issues
>
>             Dear TSV-ART,
>
>             So, Mirja and I would like to let the community know what
>             common TSV issues the TSV-ART will be looking for, and
>             we'd like to get your feedback on the current issues list,
>             which is at
>             http://trac.tools.ietf.org/area/tsv/trac/wiki/tsvdir-common-issues,
>             before we send that out.
>
>             If you could take a look at the current TSV issues, list,
>             and let us know if you think changes are needed by May 9,
>             that would be great!
>
>             Thanks,
>
>             Spencer and Mirja
>
>
>
>
>         _______________________________________________
>
>         Tsv-art mailing list
>
>         [email-masked] <mailto:[email-masked]>
>
>         https://www.ietf.org/mailman/listinfo/tsv-art
>
>
>
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: Joe Touch <[email-masked]>
Date: Thu, 5 May 2016 14:54:43 -0700

On 5/5/2016 9:22 AM, Bob Briscoe wrote:
> haste - I'll try to generalise them and add more/better RFC refs when
> I add them to the wiki later - once I've finished what I'm meant to be
> doing:
> * Forward compatibility

Good point - these are relevant to all protocol designs:

- all reserved fields need to have current behavior defined
    sender - set as a fixed value or set arbitrarily
    receiver - validate as a fixed value until otherwise defined or ignore

i.e., truly reserved fields are "set arbitrarily, ignore on receipt"
flags intended for back-compatible info are more frequently "set as 0,
ignore on receipt"
flags intended for non-back-compatible are "set as 0, validate as 0 on
receipt"
there are other variations

> interference, asymmetric interference, etc. RFC6824#section-6, other

Interactions with offload processing

> * Scarce (TCP) option space

BCP165 (both docs)

>> Also, it might be good to consider reorganzing the list into some
>> sort of taxonomy. I had a draft of this sort of thing I had been
>> preparing for TSV-AREA at one point. Let me know if it would be
>> useful to dig out.
>>
>> Joe
>>
>>         IESG approval of the bis draft).  There are a lot of things
>>         in this draft that could be called out e.g., reinvention of
>>             requirements (e.g., for congestion control) may be
>>             relaxed under suitable (e.g., operator) control - see
>>             section 3.6 of the rfc5405bis draft for discussion and
>>             RFC 7510 (MPLS/UDP) for a worked example.
>>
>>              
>>
>>             Use of zero UDP checksums with IPv6 is subtle and
>>             requires design attention - see RFC 6935 and 6936.  Note
>>             that these two RFCs contain design requirements, so it’s
>>             insufficient to just normatively reference those two RFCs
>>             and impose their requirements - an explanation of how the
>>             protocol design (for zero UDP checksums with IPv6 meets
>>             those requirements is needed).  RFC 7510 is also a worked
>>             *From:*Tsv-art [mailto:[email-masked]] *On
>>             Behalf Of *Spencer Dawkins at IETF
>>             *To:* [email-masked]
>>             we'd like to get your feedback on the current issues
>>             list, which is
>>             at http://trac.tools.ietf.org/area/tsv/trac/wiki/tsvdir-common-issues,
>>             before we send that out.
>>
>>              
>>
> This body part will be downloaded on demand.

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 6 May 2016 11:06:03 +0100

Joe, one addition inline...

On 05/05/16 22:54, Joe Touch wrote:
>> I add them to the wiki later - once I've finished what I'm meant to 
>> be doing:
>> * Forward compatibility
...and for all: "ignore (i.e. do not 'correct') when forwarding"

Bob
>>>             deployment/applicability scenarios where general
>>>             Internet requirements (e.g., for congestion control) may
>>>             be relaxed under suitable (e.g., operator) control - see
>>>             insufficient to just normatively reference those two
>>>             RFCs and impose their requirements - an explanation of
>>>             how the protocol design (for zero UDP checksums with
>>>             IPv6 meets those requirements is needed).  RFC 7510 is
>>>             also a worked example here, and its content on this
>>>             topic is not short.
>>>
>>>             -- PDU Sizes
>>>
>>>             cognizant of the general unreliability of ICMP Packet
>>>             Too Big notifications, especially when sent upstream
>>>             from within a tunnel (may not propagate across ingress).
>>>
>>>             -- Multicast
>>>
>>>             So, Mirja and I would like to let the community know
>>>             what common TSV issues the TSV-ART will be looking for,
>>>             and we'd like to get your feedback on the current issues
>>>             list, which is at
>>>             If you could take a look at the current TSV issues,
>>>             list, and let us know if you think changes are needed by
>>>             May 9, that would be great!
>>>
>>>             Thanks,
>>>
>>>             Spencer and Mirja
>>>
>>>
>>>
>>>
>> Bob Briscoehttp://bobbriscoe.net/
>>
>>

---

From: Joe Touch <[email-masked]>
Date: Fri, 6 May 2016 10:36:44 -0700

Agreed  -- I would be very happy if we tracked and pushed back on both
levels:

a) transport info must not me modified except by the endpoints

b) transport info should not be examined except by the endpoints or
their designated agents
(the latter allows for stateful port demux at an enterprise ingress or
port filtering there, but warns against doing that in the core)

Joe

On 5/6/2016 3:06 AM, Bob Briscoe wrote:
>>> Some bullet points that might prompt others to have ideas, written
>>> in haste - I'll try to generalise them and add more/better RFC refs
>>> when I add them to the wiki later - once I've finished what I'm
>>> meant to be doing:
>>> * Forward compatibility
>>>   - for CU or Reserved fields/codepoints, ensure behaviour is
>>> defined if a field value is not as specified.
>>
>> flags intended for back-compatible info are more frequently "set as
>> 0, ignore on receipt"
>> flags intended for non-back-compatible are "set as 0, validate as 0
>> on receipt"
>>>>         <[email-masked]> wrote:
>>>>
>>>>         Hi Spencer,
>>>>
>>>>          
>>>>
>>>>         I’d reference the rfc5405bis draft for which publication
>>>>         has been requested in addition to RFC 5405, as it contains
>>>>         a lot of added content (this should be “instead of RFC
>>>>         5405” after IESG approval of the bis draft).  There are a
>>>>         lot of things in this draft that could be called out e.g.,
>>>>         reinvention of congestion control is strongly discouraged.
>>>>
>>>>          
>>>>
>>>>             We now recognize “Controlled Environments” as
>>>>             restricted deployment/applicability scenarios where
>>>>             general Internet requirements (e.g., for congestion
>>>>             control) may be relaxed under suitable (e.g., operator)
>>>>             control - see section 3.6 of the rfc5405bis draft for
>>>>             discussion and RFC 7510 (MPLS/UDP) for a worked example.
>>>>
>>>>              
>>>>
>>>>             requires design attention - see RFC 6935 and 6936. 
>>>>             Note that these two RFCs contain design requirements,
>>>>             so it’s insufficient to just normatively reference
>>>>             those two RFCs and impose their requirements - an
>>>>             explanation of how the protocol design (for zero UDP
>>>>             checksums with IPv6 meets those requirements is
>>>>             needed).  RFC 7510 is also a worked example here, and
>>>>             its content on this topic is not short.
>>>>
>>>>              
>>>>
>>>>             -- PDU Sizes
>>>>
>>>>              
>>>>
>>>>             perhaps someone who spends more time on multicast than
>>>>             I do could come up with a short list of things to watch
>>>>             out for.
>>>>
>>>>              
>>>>
>>>>             Thanks, --David
>>>>
>>>>              
>>>>
>>>>             and we'd like to get your feedback on the current
>>>>             issues list, which is
>>>>             list, and let us know if you think changes are needed
>>>>             by May 9, that would be great!
>>>>
>>>>              
>>>>
>>>>             Thanks,
>>>>
>>>>              
>>>>
>>>>             Spencer and Mirja
>>>>
>>>>          
>>>>
>>>>
>>>>
>>>>