Re: [tcmtf] Support to create the working group for TCM-TF

[Joe Touch <[e-mail]>]

On 8/2/2013 7:04 PM, Wesley Eddy wrote:
> On 8/2/2013 1:58 PM, Joe Touch wrote:
>> Hi, all,
>>
>> FWIW, I don't understand why this is being requested of the TRANSPORT area.
>>
>> Tunnels such as this ought to be the purview of INTAREA. I admit I
>> remain confused as to why so many tunneling protocols are in ROUTING,
>> but regardless neither is TRANSPORT.
>>
>
>
> Hi Joe; here are a few reasons I can think of for justifying
> transport as the area:
>
> - the intent was not to invent new tunnel protocols, but to use
>    existing ones as part of a stack
> - all of the possible downsides that people brought up during
>    the meeting are impacts to the transport protocol; so there is
>    a tight coupling between transport configuration and what the
>    recommendation for performing TCMTF on a flow should be

But that's true of most tunneling protocols. We rarely measure downsides 
to network protocols in isolation.

> - many of the design considerations are directly related to things
>    transport has dealt with in the past like delayed ACKs, ACK
>    compression, buffer sizing, etc.
> - PILC and PEP documentation were done in the transport area

PILC and PEP were intended as *interactions* between the link and 
transport.

> - RoHC was done in the transport area
> - PMTUD was in transport area (since you noted that this is a
>    an additional concern)

Yes, but SEAL was not. And SEAL is a better, more complete tunnel in 
which to develop this sort of mechanism - at which point it's not a 
tunnel mechanism so much as a transport compression.

> In my opinion, if this is done, it should be in transport.

Until the "this" is defined, it's impossible to understand where TCMTF 
belongs.

Joe