Re: [tcpm] Charter update - feedback

[John Leslie <[e-mail]>]

   I apologize if this is out-of-scope, but it feels at least as in-scope
as what I'm responding to:

Wesley Eddy <[e-mail]> wrote:
> On 4/25/2012 11:47 AM, Joe Touch wrote:
>> On Apr 25, 2012, at 7:40 AM, John Leslie wrote:
>> ...
>>> Neither the current charter nor this proposed one clearly encourages
>>> or discourages work on what I'll call "expanding TCP option space" -- by
>>> which I mean almost anything to reduce the logjam of options trying to
>>> squeeze into 40 bytes.
>>>
>>> IMHO, this deserves very high priority, and can be sufficiently
>>> solved if we just accept it as a priority.
>>>
>>> In any case, it is my strong belief that either
>>> - we should work on it, or
>>> - we should send this work somewhere else.
> 
> I believe this (TCPM) is the place, if such work is to be done.
> Anantha's draft (and the collected email archives since maybe
> 2004ish) pretty clearly show that TCPM *has* been working on
> this for some time, and has simply not found an acceptable
> solution with consensus to proceed:
> 
>>> I specifically ask that we clarify whether such work is in-scope.
>> 
>> The charter shouldn't make that conclusion, IMO. That's for the WG
>> to decide based on a given proposal.
> 
> Agreed; if an approach exists to support it as a "minor extension"
> then it would be in scope, but that needs to be evaluated along
> with the viability of a given proposal.
> 
> I would support (as individual and as AD) doing an Informational
> snapshot of the collected thoughts and proposals to-date and why
> each has fallen down. It could be a milestone though and not
> necessarily part of the charter text.

   That is acceptable to me.

> I think Anantha's document is a reasonable starting point and the
> approach of trying to identify requirements to evaluate against
> echoes Joe's three criteria for a solution which he's reiterated
> several times to the list, and I think are somewhat accepted.

   "Somewhat accepted" may overstate the case...

   Joe wrote:

>> Viable, IMO:
>> - compatible with legacy TCP in the same SYN exchange

   This is easy. I think we do accept this.

>> - compatible with known proxy behavior, including segment rewriting
>>   (where not already prevented by authentication or encryption)

   This is open-ended. I think we need to list proxy behaviors we
wish to be "compatible" with -- and we should clarify what we mean
by "compatible". (Clearly, we can't expect to get option negotiation
through a proxy which strips out every attempt, but we can recognize
that our attempts are being stripped.)

>> - extends the space of SYNs not just subsequent segments

   We should be able to extend the space in the responding SYN, but
not in the originating SYN. What we need instead is to enable
additional options from the originating endpoint to be processed
"as if they were in an initial SYN".

   Given rewording to that effect, I think the requirements would be
reasonable to include in a tcp-option-extension Informational RFC.

--
John Leslie <[e-mail]>