Subject: [tcpm] Fwd: New Version Notification for draft-hawari-tcpm-tfo-ipv6-prefixes-00.txt

From: Mohammed HAWARI <[email-masked]>
Date: Fri, 3 Jul 2015 10:58:11 +0200

Dear all,

I am currently a master's student at Ecole Polytechnique, France and and an
intern at Cisco. As part of my research internship, I have written an
Internet Draft that specifies an extension to TCP Fast Open. It enables a
TCP Fast Open Cookie to be used for a whole IPv6 prefix instead of a single
address.

Your comments on this draft are very welcome :) I will be at IETF 93 for
further discussion too.

Best Regards,

Mohammed Hawari

---------- Forwarded message ----------
From: <[email-masked]>
Date: 2015-07-03 9:33 GMT+02:00
Subject: New Version Notification for
draft-hawari-tcpm-tfo-ipv6-prefixes-00.txt
To: Mohammed HAWARI <[email-masked]>

A new version of I-D, draft-hawari-tcpm-tfo-ipv6-prefixes-00.txt
has been successfully submitted by Mohammed HAWARI and posted to the
IETF repository.

Name:           draft-hawari-tcpm-tfo-ipv6-prefixes
Revision:       00
Title:          TCP Fast Open Cookie for IPv6 prefixes
Document date:  2015-07-03
Group:          Individual Submission
Pages:          5
URL:
https://www.ietf.org/internet-drafts/draft-hawari-tcpm-tfo-ipv6-prefixes-00.txt
Status:
https://datatracker.ietf.org/doc/draft-hawari-tcpm-tfo-ipv6-prefixes/
Htmlized:
https://tools.ietf.org/html/draft-hawari-tcpm-tfo-ipv6-prefixes-00

Abstract:
   In order to support applications that require a large number of
   addresses or address space, a host may be assigned an aggregate IPv6
   prefix rather than one or more discrete IPv6 addresses.  This
   document briefly describes cases where this may occur, and specifies
   an extension to TCP Fast Open [RFC7413] to allow a client to use a
   single TCP Fast Open cookie for an IPv6 prefix.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 6 Jul 2015 17:20:22 -0700

> Your comments on this draft are very welcome :) I will be at IETF 93 for
Was the motivation to reduce cookie storage for v6 clients?
getting the cookie is a one-time operation. it's not clear to me this
worth another TCP option.

I don't understand the second motivation...
"  Another application of this extension appears in the context of a
   DNS-load-balanced cluster of servers.  In this case, one server of
   the cluster will provide the client with a TFO cookie which is valid
   for the whole cluster, thus reducing the number of three way
   handshakes.
"

If only some special application needs this, why not just
change the server to generate cookies base on v6-addr/64 (on its own risk)?

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Mohammed HAWARI <[email-masked]>
Date: Tue, 07 Jul 2015 23:50:13 +0200

Le 07/07/2015 02:20, Yuchung Cheng a écrit :
Hi,
> worth another TCP option.
Well, it is partly a problem of storage (potentially 2^prefix_length
cookies stored by the client) but not only. For example if a server has
a /64 from which each of the addresses represents a chunk of data (or
any other applicative concept), these addresses might be accessed very
sparsely. It is even possible that one address of that /64 would never
be accessed twice by the client. You will do this one-time operation
very often and will gain no benefit from using TFO.
> change the server to generate cookies base on v6-addr/64 (on its own risk)?
This cluster of servers could be a cluster of web servers and I might be
wrong, but web traffic is still a source of highly transactional
traffic. This is not really a special application.
If I understand it well,the solution you describe forces the application
(client-side and server-side) to be aware of the prefix-length for which
a cookie is valid. This might not be possible and is definitely not
flexible (/64 sounds quite arbitrary).

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 15 Jul 2015 09:39:36 -0700

> flexible (/64 sounds quite arbitrary).
The cookie is opaque to the client so the client does not need to change.

I am saying if the intent is to treat v6/64 as a host, just have the
server use the prefix to generate the cookie. that's a 2-liner change
on the server side.
syn option space is very tight so it's not worth another option for
small things like this.