[tcpm] discussion of TCP option space

[Joe Touch <touch at ISI.EDU>]

changing the thread as Lars suggested...

Anantha Ramaiah (ananth) wrote:
> Lars had sent an email to retain focus on the port randomization and
> hence this is going to my last comment... Pl see inline..
>  
>>
>> Anantha Ramaiah (ananth) wrote:
>>> Murari,
>> ...
>>> - or do it in piecemeal, first buy more TCP option space, 
>> standardize 
>>> any one of the proposals for extending the TCP option 
>> space. Then have 
>>> an extended port option like yu suggest below. Then think 
>> about other 
>>> TCP fields requiring extension.
>> The problem is that buying more option space is equivalent to 
>> requiring a whole new TCP header - it has the same problems 
>> with backward compatibility. Previous attempts explored this 
> 
> New TCP header == "Mountain" , IMO this is equivalent to using SCTP in
> some sense.
> 
> TCP option space == "Molehill" , this is a "minimal" change with "some"
> backward compat issues which can be addressed.

See my other post; it's impossible to extend TCP option space for SYNs,
and SYNs are where they matter.

> If I take your above para seriously, then you are in a way implying that
> there is no new TCP options possible :-( or in other words users of TCP
> would be rationed to use only a few options in the initial SYN exchange.

New options are possible, but only if they are OPTIONAL and we expect
their use to be mutually exclusive with likely SYN options (SACK,
timestamps) or other proposed options. Or we should start making
progress to Mark's idea of just breaking things now.

Joe

-- 
----------------------------------------------------------------------
Joe Touch                Sr. Network Engineer, USAF TSAT Space Segment
               Postel Center Director & Research Assoc. Prof., USC/ISI

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
tcpm mailing list
tcpm at ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm