Subject: [radext] #191 (bigger-packets): Is evaluation of backwards compatibility part of the experiment's goals?

From: "radext issue tracker" <[email-masked]>
Date: Thu, 20 Aug 2015 06:20:30 -0000

#191: Is evaluation of backwards compatibility part of the experiment's goals?

 In the Abstract, I read:
 "[...] this specification introduces no new experimental evaluation
 criteria beyond those in the base TCP specification"

 I wonder if this is really a clear-cut situation. Interoperability
 (backward/forward compatibility) is given a lot of thought and makes a
 number of assumptions.

 One such assumption is that bigger-packets is for new use cases (only?).
 It is however easy to construct cases where bigger-packets is also of
 use for existing RADIUS uses, like this one:
 IEEE 802.1X authentication on a wired network with jumbo frames enabled.
 Layer 2 EAPoL payloads could grow to 9K, which would typically be
 signalled by a Framed-MTU attribute; and which could trigger 9K of
 EAP-Message payload.
 I understand that the general statement of "SHOULD NOT generate a larger
 response than 4096 by default" catches this case (for implementation
 actually honoring the SHOULD NOT, which is sadly not a given). But it
 makes me wonder if the topic is indeed so easy.

 Another example which makes assumptions is that closure of a TCP session
 when sending a big packet is taken as an indicator for non-support of
 this specification. There are many other reasons why the TCP session
 might go down (firewall state timeouts...). The client would
 unjustifiedly reduce its transmission size for ... how long? Eternity?
 That would mean a permanent loss of the big-packets feature. As a
 suggestion: the Rationale section already has a better mechanism - after
 TCP closure, start the next TCP session with the Status-Server max-size
 discovery. It might be an idea to mandate this after every TCP closure
 which occurs for reasons where a doubt exists - not only for high-volume
 servers.

 So, how does the group feel about recognising that backward
 compatibility problems are something that should be evaluated in this
 experiment? I could imagine a text like

 OLD:
 "However, this specification introduces no new
    experimental evaluation criteria beyond those in the base TCP
    specification; this specification can be evaluated along with that
    one for advancement on the standards track."

 NEW:
 "This specification introduces backward compatibility issues with
 implementations of RFC6613 which do not support this experiment, and
 with proxies which need to proxy an incoming large packet to a
 size-constrained RFC2865 transport RADIUS server. The real-life
 consequences of this lack of backward compatibility are to be studied in
 and evaluated during the assessment of this experiment before the
 features are sent to Standards Track."

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-radext-
  [email-masked]           |  [email-masked]
     Type:  enhancement              |     Status:  new
 Priority:  major                    |  Milestone:
Component:  bigger-packets           |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://tools.ietf.org/wg/radext/trac/ticket/191>
radext <http://tools.ietf.org/radext/>

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Aug 2015 10:14:29 -0400

>>>>> "Fradext" == radext issue tracker <[email-masked]> writes:

    Fradext>  So, how does the group feel about recognising that
    Fradext> backward compatibility problems are something that should
    Fradext> be evaluated in this experiment? I could imagine a text
    Fradext> like

I'd rather just fold this in when we bring TCP to standards track
arguing that one of the experimental results of the TCP experiment is
that we needed bigger packets.