Subject: [tcpm] q about draft-simpson-tcpct-03

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 16 Jul 2010 01:01:41 -0700

Hello, I hope this is the right place to discuss this. If not, please let me
know the right place for it.

Accodring to draft-simpson-tcpct-03, if the Cookie option or Cookie-less
option has been successfully exchanged, we can use TCP header extension.
Does this mean
   1:  It is expected that various TCP "something" Extended Options will be
developed based on this?
   2:  If we want to use many or long options, use TCP timestamps extended
option and set large offset value in the Extend field?
   3.  Neither. Use of TCP timestamps extended option is the only exception
which can exceed the limit of option space?

Thanks,
--
Yoshifumi Nishida
[email-masked]

---

From: Lars Eggert <[email-masked]>
Date: Fri, 16 Jul 2010 11:13:06 +0300

Hi,

On 2010-7-16, at 11:01, Yoshifumi Nishida wrote:
> Hello, I hope this is the right place to discuss this. If not, please let me know the right place for it.
> 
> Accodring to draft-simpson-tcpct-03, if the Cookie option or Cookie-less option has been successfully exchanged, we can use TCP header extension.
> Does this mean
>   1:  It is expected that various TCP "something" Extended Options will be developed based on this?
>   2:  If we want to use many or long options, use TCP timestamps extended option and set large offset value in the Extend field?
>   3.  Neither. Use of TCP timestamps extended option is the only exception which can exceed the limit of option space?

note that tcpct is an RFC on the Independent Stream, i.e., not an IETF document. So there isn't any IETF consensus behind whether the header extension mechanism is something we can generalize on. It's certainly worth discussing, if someone has experience with whether it would work in general, based on experimentation with tcpct.

Lars

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 20 Jul 2010 01:40:08 -0700

Hi Lars,

2010/7/16 Lars Eggert <[email-masked]>

> >   3.  Neither. Use of TCP timestamps extended option is the only
> exception which can exceed the limit of option space?
>
> note that tcpct is an RFC on the Independent Stream, i.e., not an IETF
> document. So there isn't any IETF consensus behind whether the header
> extension mechanism is something we can generalize on. It's certainly worth
> discussing, if someone has experience with whether it would work in general,
> based on experimentation with tcpct.
>
> Lars

Thanks for the info. It would be interesting if we can generalize this.
BTW, I think several approach which can extend TCP option space has been
proposed in the past.
Why this one is being adopted as RFC? I'm just curious about the rationale..
Can this be middle-box safe approach?

Thanks,
--
Yoshifumi Nishida
[email-masked]

---

From: Lars Eggert <[email-masked]>
Date: Tue, 20 Jul 2010 11:57:11 +0300

Hi,

On 2010-7-20, at 11:40, Yoshifumi Nishida wrote:
> BTW, I think several approach which can extend TCP option space has been proposed in the past. 

it'll be published as an RFC on the Independent Stream, because the authors submitted it as an Independent Submission directly to the RFC Editor. It is not a product (much less a standard) of the IETF. See RFC3932.

That means that the IESG reviewed this purely to make sure there is no conflict with ongoing IETF work. We felt it was safe enough to experiment with this extension using a one of the TCP option numbers set aside for generic experimentation. Note that the rules   that talk about how these option numbers can be used are very clear that no product deployment etc. may happen with them.

> Can this be middle-box safe approach?

Unclear at the moment, in my personal view. Folks will need to experiment with it and generate data.

Lars

---

From: William Allen Simpson <[email-masked]>
Date: Tue, 20 Jul 2010 16:14:11 -0400

> Unclear at the moment, in my personal view. Folks will need to experiment with it and generate data.
I suppose I should speak up here.  Initial testing found this to be the only
middle-box safe approach.  But needs much more interoperability testing.

Yoshifumi, what platform are you implementing?

(Implementors Only.  Thanks In Advance.)

---

From: "Yoshifumi Nishida" <[email-masked]>
Date: Tue, 20 Jul 2010 03:40:08 -0500

WARNING: contains banned part

Subject: Re: [tcpm] q about draft-simpson-tcpct-03
From: "Yoshifumi Nishida" <[email-masked]>
To: "Lars Eggert" <[email-masked]>
Cc: <[email-masked]>
Date: Tue, 20 Jul 2010 03:40:08 -0500

Hi Lars,

	Hi,

	
	Lars

Thanks,
--
Yoshifumi Nishida
[email-masked]

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 21 Jul 2010 11:26:01 -0700

Hello William, Thanks for your response.

2010/7/20 William Allen Simpson <[email-masked]>

> Yoshifumi, what platform are you implementing?

I'm I afraid that I'm not implementing yet.
But, I'm interesting in middle-box safe approach for using new TCP options,
especially something like header extension to use longer options.
We're doing some research on middle box's behavior now.
I feel sorry if this is not what you expected, but I'm willing to
collaborate if you need.

Thanks,
--
Yoshifumi Nishida
[email-masked]

---

From: William Allen Simpson <[email-masked]>
Date: Thu, 22 Jul 2010 07:59:34 -0400

> I'm I afraid that I'm not implementing yet.

Sorry to hear that....  When you are ready to write code, or work on coding
interoperability, drop me a line privately and help invigorate our
independent research group.  Thanks.

> But, I'm interesting in middle-box safe approach for using new TCP options, especially something like header extension to use longer options.

I'd thought that was already well established some time ago.

> I feel sorry if this is not what you expected, but I'm willing to collaborate if you need.
>
If you have a platform to implement, collaboration would be welcome.  In
particular, I've seen no TCPCT testing for links passing overseas.  So far,
only continental US.

Otherwise, I've no time for a debate society.  I've not seen any traffic on the
TCP *Implementors* list since 2003.