Subject: Re: [core] [tcpm] [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt]

From: Carsten Bormann <[email-masked]>
Date: Fri, 10 Jun 2016 12:04:02 +0200

Carles,

thanks for submitting this.

I think that this draft is truly best handled in LWIG.

We don't *have* to profile TCP for CoAP-over-TCP; people are free to use
whatever parts of TCP they think are useful.  (And, of course, there are
applications for CoAP-over-TCP that are in the backend.)

On the other hand, it is useful to
-- manage expectations:
   what can I expect that the *other* side will offer in TCP functionality
-- give advice to implementers:
   what is useful to implement, what not
-- collect implementation experience that is relevant for these two

(One interesting effect I'm seeing is that people know how good TCP can
be, which shapes their expectations, but then they are hurt by using
really bad constrained TCP implementations...  We certainly should be
paying attention to this on the CoRE WG side.)

My biggest comment is probably that for device-to-cloud, the level of
TCP functions implemented will be asymmetric (full TCP on cloud side,
possibly more limited on the device side) -- what is the effect of this
asymmetry?

Maybe there also needs to be more discussion on the role of the
middlebox (after all, we are doing CoAP-over-TCP to devices for the sole
reason to climb over middleboxes).

Grüße, Carsten

Scharf, Michael (Nokia - DE) wrote:
> Heads-up
> 
> Michael
> 
> 
> -----Original Message-----
> From: Lwip [mailto:[email-masked]] On Behalf Of Carles Gomez Montenegro
> Sent: Friday, June 10, 2016 11:36 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Lwip] [Fwd: New Version Notification for draft-gomez-core-tcp-constrained-node-networks-00.txt]
> 
> Dear LWIG WG,
> 
> /** Apologies for possibly multiple similar e-mails... **/
> 
> We have just submitted the draft entitled 'TCP over Constrained-Node Networks', which we believe may be of interest to the members of this group.
> 
> We would like to kindly ask for feedback, specially on the basis of implementation experience.
> 
> Thank you very much!
> 
> Kind regards,
> 
> The authors
> 
> 
> ---------------------------- Original Message ----------------------------
> Subject: New Version Notification for
> draft-gomez-core-tcp-constrained-node-networks-00.txt
> From:    [email-masked]
> Date:    Fri, June 10, 2016 10:38 am
> To:      "Jon Crowcroft" <[email-masked]>
>          "Carles Gomez" <[email-masked]>
> --------------------------------------------------------------------------
> 
> 
> A new version of I-D, draft-gomez-core-tcp-constrained-node-networks-00.txt
> has been successfully submitted by Carles Gomez and posted to the IETF repository.
> 
> Name:		draft-gomez-core-tcp-constrained-node-networks
> Revision:	00
> Title:		TCP over Constrained-Node Networks
> Document date:	2016-06-10
> Group:		Individual Submission
> Pages:		9
> URL:           
> https://www.ietf.org/internet-drafts/draft-gomez-core-tcp-constrained-node-networks-00.txt
> Status:        
> https://datatracker.ietf.org/doc/draft-gomez-core-tcp-constrained-node-networks/
> Htmlized:      
> https://tools.ietf.org/html/draft-gomez-core-tcp-constrained-node-networks-00
> 
> 
> Abstract:
>    This document provides a profile for the Transmission Control
>    Protocol (TCP) over Constrained-Node Networks (CNNs).  The
>    overarching goal is to offer simple measures to allow for lightweight
>    TCP implementation and suitable operation in such environments.
> 
> 
> 
> 
> 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
> 
> 
> 
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 10 Jun 2016 17:10:11 +0200

Hi Carsten,

Thanks a lot for your comments.

While we work to address those, it would be really helpful if folks that
have faced 'bad constrained TCP implementations', and/or have struggled
with middlebox traversal can share their experience.

Cheers,

Carles

>> Subject: [Lwip] [Fwd: New Version Notification for
>> draft-gomez-core-tcp-constrained-node-networks-00.txt]
>>
>> Dear LWIG WG,
>>
>> We have just submitted the draft entitled 'TCP over Constrained-Node
>> Networks', which we believe may be of interest to the members of this
>> group.
>>
>> A new version of I-D,
>> 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: Zhen Cao <[email-masked]>
Date: Sun, 12 Jun 2016 20:41:59 +0800

Hi Carles,

Nice draft. I always want to know the complains of TCP problems over
Constrained link and device.  In the very beginning of Lwig, the
IETF79 bof, David Bormann gave an excellent talk about similar issues
( i try to search the IETF proceedings for the talk but failed coz
they do not hold it for informative bof ).    But we failed to collect
these information from implementer or researchers like you further on.
   Thanks again for this always timely work.

In this respect, I agree with Carsten that your draft being handled in
lwig and a talk is welcome at Berlin meeting.

Some quick comments for your draft.

>3.2.  Window Size

>  A TCP window size of one segment follows the same rationale as the
> default setting for NSTART in [RFC7252], leading to equivalent
> operation when CoAP is used over TCP.

IMHO, it does not matter because if the application has only a short
message to send, the de facto effective cwnd will be ONE.

>3.3.  RTO estimation
>  challenges of CNNs, in contrast with the RFC 6298 RTO.  Therefore, as
> per this document, CoCoA RTO SHOULD be used in TCP over CNNs.
>  Alternatively, implementors MAY choose the RTO estimation algorithm
> defined in RFC 6298.  One of the two RTO algorithms MUST be
> implemented.

Is the RTO estimation algorithm link-specific? For example, I knew you
have some work on CoCoA over GPRS. Is it always better than the
competitor?

Cheers,
Zhen

On Fri, Jun 10, 2016 at 11:10 PM, Carles Gomez Montenegro
<[email-masked]> wrote:
> > GrÃ¼ÃŸe, Carsten

---

From: "weigengyu" <[email-masked]>
Date: Mon, 13 Jun 2016 09:53:54 +0800

Hi Carles,

I will give some comments as we have been doing both CoAP over Websocket and 
CoAP over TCP by extending Califorium.

I agree Carsten that CoAP over TCP will be used in the cloud and may also be 
in less-constrained networks.
It is hard to say  that CoAP over TCP will be used in Constrained Networks.

Rgards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Carles Gomez Montenegro
Sent: Friday, June 10, 2016 11:10 PM
To: Carsten Bormann
Cc: [email-masked] ; [email-masked] Extensions ; [email-masked] ; 
[email-masked] WG
Subject: Re: [core] [tcpm] [Lwip] [Fwd: New Version Notification for 
draft-gomez-core-tcp-constrained-node-networks-00.txt]

Hi Carsten,

Cheers,

Carles

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

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 13 Jun 2016 11:57:09 +0200

Hi Zhen,

Thanks a lot for your support and comments!

Please find below some inline responses.

> lwig and a talk is welcome at Berlin meeting.

Thanks a lot. We'll prepare a presentation for Berlin, and will also
change the name of the draft to show 'lwig' instead of 'core'.

> message to send, the de facto effective cwnd will be ONE.

I understand that what you point out may happen in many cases... However,
a device, in some cases, might want to send e.g. two (or more) packets
back to back to the same destination. In those, the window size of one
would make a difference.

By the way, currently the phrasing in the draft is that a window size of
one 'MUST' be used. This keeps a behavior equivalent to that of CoAP for
confirmable messages in RFC 7252, and dramatically simplifies
implementations. However, I wonder if some more freedom should be offered,
and maybe the 'MUST' could become a 'SHOULD', at the expense of opening
the door to greater complexity... I personally tend to prefer the first
approach, but it would be great to receive more feedback on this!

> have some work on CoCoA over GPRS. Is it always better than the

These are crucial questions. In our work with CoCoA (e.g. [1]), we have used:

- GPRS/UMTS emulation
- GPRS testbed experiments
- IEEE 802.15.4 (with and without L2 reliability) simulation
- IEEE 802.15.4 testbed experiments

In fact, using different link layer setups has been fundamental to
identify issues of the initial CoCoA version, and to properly fine-tune
it. While in some specific experiments (i.e. combination of network
topology, offered load, traffic pattern, etc.) an alternative algorithm
has shown better performance, in the more recent versions of CoCoA:

- CoCoA has never underperformed default CoAP (while alternative
algorithms have in some scenarios).

- CoCoA shows a performance at least similar to, often better than, that
of default CoAP.

We evaluated performance in terms of parameters such as throughput, retry
ratio, settling time after a burst of messages, and fairness.

Nevertheless, of course, we welcome more feedback from other evaluation
scenarios!

Cheers,

Carles

[1] Here is our most mature paper on the topic:
https://www.researchgate.net/publication/297989374_CoAP_Congestion_Control_for_the_Internet_of_Things

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 13 Jun 2016 12:15:27 +0200

Hi Wei,

> CoAP over TCP by extending Califorium.

Thanks a lot!

> It is hard to say  that CoAP over TCP will be used in Constrained

There exist relevant examples such as:
https://www.ietf.org/proceedings/87/slides/slides-87-lwig-6.pdf

It could be that, within the constrained-node network space, TCP is used
rather in class 2 devices. However, we would need to collect more data to
be able to confirm this.

On the other hand, in our opinion, the CoAP over TCP activity may increase
the number of constrained devices using TCP (probably, in the 'constrained
device' to 'cloud' scenario).

Thanks again!

Best regards,

Carles

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Mon, 13 Jun 2016 11:01:21 +0000

Just out-of-curiosity: In 1981, when the current TCP spec was published, end hosts had significant processing and memory limitations. Quite a bit of the TCP protocol mechanisms were designed to deal with senders and receivers that have very small buffers, e.g., of the order of the maximum segment size.RFC 793 is very carefully designed to deal with these constraints. And current TCP implementations are still backward compatible to RFC 793.

When quickly scanning through this document, some observations (the list is not comprehensive): 

- TCP counts window sizes in bytes, which draft-gomez-core-tcp-constrained-node-networks-00 seems to ignore. 

- Out-of-my-head, nothing prevents a TCP sender from limiting the congestion window to a small window (e.g., one MSS). This basically turns TCP into a stop-and-wait protocol. A TCP sender can unilaterally decide to limit its congestion window if it wants to simplify its implementation. I am not sure if RFC 2119 language is needed for that at all.

- A TCP receiver can use the receive window to prevent the sender from sending data, e.g., if it can only deal with one MSS. It may be interesting to look into whether advertising a maximum receive window e.g. of at most one MSS would solve some of the problems discussed in the draft.

- TCP options will only be enabled if supported on both ends and a standard-compliant TCP stack only has to support the MSS option (more precisely, option kinds 0, 1, and 2). An implementation that does not want to use any additional TCP features does not have to implement support any of those options. However, to be compatible with RFC 793 the option kinds 0, 1, and 2 have to be parsed in SYNs and thus basic support for option parsing in SYNs is required anyway. If the basic support for option parsing in SYNs is in place (which is not very complex code), it seems easy to process any other options that may be present in the SYN as well, and just ignore them. Thus, I do not understand what added value a MUST has that "forbids" TCP options that may typically not be negotiated in the environments addressed by this document.

- If the receiver knows that TCP shall run in a stop-and-wait mode (e.g., because it advertises very small receive window), the delayed ACKs in TCP may offer some opportunities for optimization, e.g., a receiver could want to turn them off delayed ACKs when it advertises a very small receive window. I believe the document could look into that space.

- There are quite a number of differences between using TCP only inside a controlled environment, or using TCP with endpoints that are located in the Internet. I would recommend that a document explicitly discusses both variants, as design trade-offs could be different. And I would assume that one of the reasons for picking TCP would be to at least have the option of end-to-end transfers over the global Internet.

- ... (there is more)

In general, the TCPM list is followed by quite a number of different TCP implementers and there is some expertise on the original RFC 793 design decisions. If the intention of this document is e.g. to define up a minimum set of TCP features required for a stop-and-wait operation and with very small buffers, I'd assume that relevant expertise would be on the TCPM list.

So, it might make sense to keep the TCPM list in the loop. Presenting the document in TCPM may also be an option the authors may want to think about.

Michael

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 13 Jun 2016 12:13:36 +0100

> Just out-of-curiosity: In 1981, when the current TCP spec was published, 
> end hosts had significant processing and memory limitations. Quite a bit 
> of the TCP protocol mechanisms were designed to deal with senders and 
> receivers that have very small buffers, e.g., of the order of the maximum 
> segment size.RFC 793 is very carefully designed to deal with these 
> constraints. And current TCP implementations are still backward 
> compatible to RFC 793.

right - a typical system we used in 1981 was a DEC LSI/11 which had
64Kbytes of RAM for the whole OS and network stack - so the actual
buffer space for packets might be a couple of kbytes - the thing is
tho, that over a LFN (remember also, the backbone speeds were 56kbps,
and international links might have satellites with .72 seconds RTTs),
a sender still might speculatively  keep more packets "in flight" than 
the receiver buffer advertised, if the receive processing meant
that the bottleneck was always "in the air" not at the receiver

of course, in a lot of CORE environments, the RTT is small enough that
i think you're right, and advertising an MSS receive window would
result in the stop&wait behaviour - can easily try this even on a
couple of laptops on a wifi net........

maybe...
int clamp= 576;
setsockopt(sock, SOL_SOCKET, TCP_WINDOW_CLAMP, (char *)& clamp, sizeof(clamp));

> - TCP counts window sizes in bytes, which 
> draft-gomez-core-tcp-constrained-node-networks-00 seems to ignore.
> 
> - Out-of-my-head, nothing prevents a TCP sender from limiting the 
> congestion window to a small window (e.g., one MSS). This basically turns 
> TCP into a stop-and-wait protocol. A TCP sender can unilaterally decide 
> to limit its congestion window if it wants to simplify its 
> implementation. I am not sure if RFC 2119 language is needed for that at 
> all.
> 
> - A TCP receiver can use the receive window to prevent the sender from 
> sending data, e.g., if it can only deal with one MSS. It may be 
> interesting to look into whether advertising a maximum receive window 
> e.g. of at most one MSS would solve some of the problems discussed in the 
> draft.
> 
> - TCP options will only be enabled if supported on both ends and a 
> standard-compliant TCP stack only has to support the MSS option (more 
> precisely, option kinds 0, 1, and 2). An implementation that does not 
> want to use any additional TCP features does not have to implement 
> support any of those options. However, to be compatible with RFC 793 the 
> option kinds 0, 1, and 2 have to be parsed in SYNs and thus basic support 
> for option parsing in SYNs is required anyway. If the basic support for 
> option parsing in SYNs is in place (which is not very complex code), it 
> seems easy to process any other options that may be present in the SYN as 
> well, and just ignore them. Thus, I do not understand what added value a 
> MUST has that "forbids" TCP options that may typically not be negotiated 
> in the environments addressed by this document.
> 
> - If the receiver knows that TCP shall run in a stop-and-wait mode (e.g., 
> because it advertises very small receive window), the delayed ACKs in TCP 
> may offer some opportunities for optimization, e.g., a receiver could 
> want to turn them off delayed ACKs when it advertises a very small 
> receive window. I believe the document could look into that space.
> 
> - There are quite a number of differences between using TCP only inside a 
> controlled environment, or using TCP with endpoints that are located in 
> the Internet. I would recommend that a document explicitly discusses both 
> variants, as design trade-offs could be different. And I would assume 
> that one of the reasons for picking TCP would be to at least have the 
> option of end-to-end transfers over the global Internet.
> 
> - ... (there is more)
> 
> In general, the TCPM list is followed by quite a number of different TCP 
> implementers and there is some expertise on the original RFC 793 design 
> decisions. If the intention of this document is e.g. to define up a 
> minimum set of TCP features required for a stop-and-wait operation and 
> with very small buffers, I'd assume that relevant expertise would be on 
> the TCPM list.
> 
> So, it might make sense to keep the TCPM list in the loop. Presenting the 
> document in TCPM may also be an option the authors may want to think 
> about.
> 
> Michael
> 
>

---

From: Zhen Cao <[email-masked]>
Date: Mon, 13 Jun 2016 21:11:12 +0800

> approach, but it would be great to receive more feedback on this!

Which way is better in this case, sending two and sleep, or sending
one followed by another?  Sometimes the former will be better for
constrained nodes.

> These are crucial questions. In our work with CoCoA (e.g. [1]), we have used:

Thanks a lot for the reference and clarification, a nice measurement
paper indeed!

Cheers,
Zhen

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Tue, 14 Jun 2016 14:36:26 +0530

Hi,

Section 3.4 of the draft states the following:

"it is envisaged that further segment exchanges will take place within an 
interval of two hours since the last segment has been sent"

Could you please explain a bit about the basis of such a deterministic 
assumption? If you could share some pointers to any study related to this. 
There is RFC 5382 which kind of mandates that the time out cannot be less 
than 124 minutes. Does it drive the above assumption? However, not sure 
how many implementations adheres to the time mentioned in RFC 5382.

In the recent time I had been looking at the different efforts that has 
gone into improving TCP performance from different aspects under different 
circumstances since the early days. Given the short transactional type of 
exchanges, would it be also worthwhile to count experimental RFCs like 
"TCP Fast Open" and see how CoAP performs on top of it?

Regards
Abhijan Bhattacharyya
Associate Consultant
Scientist, Innovation Lab, Kolkata, India
Tata Consultancy Services
Mailto: [email-masked]
Website: http://www.tcs.com
____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Consulting
____________________________________________

From:   "Carles Gomez Montenegro" <[email-masked]>
To:     "Carsten Bormann" <[email-masked]>
Cc:     "[email-masked]" <[email-masked]>, "[email-masked] Extensions" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked] WG" <[email-masked]>
Date:   06/10/2016 08:40 PM
Subject:        Re: [core] [tcpm] [Lwip] [Fwd: New Version Notification 
for draft-gomez-core-tcp-constrained-node-networks-00.txt]
Sent by:        "core" <[email-masked]>

Hi Carsten,

Cheers,

Carles

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 21 Jun 2016 10:06:50 +0200

Hi Zhen,

Thanks for your feedback!

(And sorry for the late response...)

> one followed by another?  Sometimes the former will be better for

In that specific case, if the constrained device is sleeping by default,
there could be energy consumption overhead due to the wake up before
communication, plus the cool down after communication. In that case, it
would be more energy efficient to wake up, send the two messages
consecutively, receive the ACK(s) and then go back to sleep, as you point
out (otherwise, the energy consumption overhead would be duplicated).

So this is an additional possible benefit of using a window size greater
than one, although it may add complexity to implementations.

Cheers,

Carles

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 21 Jun 2016 12:47:13 +0200

Hi Abhijan,

(Keeping the lists included as destinations, sorry for multiple copies...)

Thank you very much for your feedback. Please find some inline comments

> interval of two hours since the last segment has been sent"

Actually, the complete sentence is:

   'In CNNs, a TCP connection SHOULD be kept open as long as the two TCP
   endpoints have more data to exchange or it is envisaged that further
   segment exchanges will take place within an interval of two hours
   since the last segment has been sent.'

So the 'as long as' still precedes the sentence you have pointed out.
Anyway, prepending an 'if' to the sentence may help clarify the text.

By the way, the two-hour value (influenced by the default keep-alive
timer) was chosen here as a trade-off between avoiding too frequent TCP
connection establishment overhead and avoiding to keep unused state in
constrained devices for too long.

> how many implementations adheres to the time mentioned in RFC 5382.

RFC 5382 (which is very relevant for this draft) requires NATs not to
remove state for a live connection, ensuring that 'applications can send
keep-alive packets at the default rate (every 2 hours)'. So the two-hour
default keep-alive timer is also influencing the 124-minute time out
mentioned in RFC 5382.

> "TCP Fast Open" and see how CoAP performs on top of it?

I agree that this is something to look at.

TCP Fast Open allows data to be carried in the SYN (and SYN-ACK) packet(s)
and consumed by the receiving end during the initial connection handshake.

However, TCP Fast Open involves an initial RTT for requesting a
4-to-16-byte cookie, which is then included in the Fast Open option of the
SYN segment of new connections. Furthermore, the cookie needs to be
updated (I'm not sure how often) for security.

TCP Fast Open can benefit applications that open 'many' new connections,
while the approach proposed in our draft is to keep a TCP connection open
for long time, avoiding connection establishment as much as possible.

If a TCP connection is kept open for long time, the possible benefits
(which, in my opinion, are not so clear considering all of the above) of
TCP Fast Open will become asymptotically negligible.

Cheers,

Carles

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Wed, 22 Jun 2016 18:09:19 +0530

Hi Carles,
Thank you for the explanations.

> default keep-alive timer is also influencing the 124-minute time out

That is understood. The point is that, there is an element of doubt 
regarding whether the implementations in reality abide by the given time 
interval or silently times out without the knowledge of the end-points. 

> TCP Fast Open will become asymptotically negligible.

Keeping TCP session active for long time may be definitely useful for 
certain cases. But again, there is the additional draining of energy due 
the keep alive mechanism. Also, as IoT end-points may like to conserve 
energy by opportunistic sleeping, maintaining TCP connection for too long 
may be difficult and TFO kind of approach, though designed for browsers, 
may be useful. So a study in this line may help. 

Regards
Abhijan Bhattacharyya
Associate Consultant

"Carles Gomez Montenegro" <[email-masked]> wrote on 06/21/2016 
04:17:13 PM:

> To: "Abhijan Bhattacharyya" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, 
> "[email-masked]" <[email-masked]>, "[email-masked] Extensions" 
> <[email-masked]>, [email-masked]
> Date: 06/21/2016 04:17 PM

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 22 Jun 2016 15:05:32 +0200

On 22 June 2016 at 14:39:52, Abhijan Bhattacharyya ([email-masked]) wrote:
That is understood. The point is that, there is an element of doubt regarding whether the implementations in reality abide by the given time interval or silently times out without the knowledge of the end-points.
There is no doubt at all :-/

http://conferences.sigcomm.org/imc/2010/papers/p260.pdf

Figure 7, Section 4.2:

"More than half the devices fail to meet the IETF recommended timeout of 124 min” 

This study is a few years old, but I would be surprised if the situation has become much better.

(Are there newer studies of this type?)

Grüße, Carsten

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 22 Jun 2016 18:58:57 +0200

Hi Abhijan, Carsten,

(Good point, and great measurement paper!)

Yes, this is indeed bad 'news', and a problem.

I agree with Abhijan that a detailed analysis on using TCP Fast Open in
this context, versus long connections aided by (realistic) keep-alive
mechanisms, is definitely needed.

Thanks!

Carles

---

From: Joe Touch <[email-masked]>
Date: Wed, 22 Jun 2016 13:52:10 -0700

>    since the last segment has been sent.'
TCP is already defined such that idle connections remain in the
"connected" state. There should be no need to state this requirement at all.

The converse may be useful to state, such as when a system can "garbage
collect" such idle connections. That's typically only useful to scavenge
memory, and it's always been the OS'es prerogative to do so.

Joe

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 22 Jun 2016 23:46:23 +0000

That's an amazing CC list :-) I would suggest moving to expertly one of those working groups.

Carsten's comment that TCP sessions are likely to be asymmetric, with a constrained node talking to an unconstrained node, is an important one. This seems like an excellent place to note the Robustness Principle - "conservative in what you send, liberal in what you receive". If the constrained node is limited to a profile like yours, and a peer tries to negotiate the use of other options, or simply sends other options, you want the CNN to act on what it understands and ignore the rest.

There are a couple of constants in the draft that caught my attention.

I imagine that the reason for a fixed effective window of one packet is to limit the issues with packet resequencing and congestion control. I think you still want to facilitate the Fast Recovery heuristic, which requires that you support an effective window of five. To work that through, later name the packets in a given transmission burst A through F, and presume that B gets lost. The sender should get an acknowledgement for A when C arrives and duplicate acknowledgements when D, E, and F arrive. It will retransmit B when the third duplicate ack arrives. In order to have B, C, D, E, and F sent, the window has to be at least five.

I can see making that optional, but I don't think it should be precluded.

The two hour lifetime of a session also seems heavy-handed (and I would say the same about a two hour minimum keep-alive interval). I might suggest that the implementor or operator should figure out how many TCP peers a given system is likely to end to communicate with on a regular basis (the number of TCP-based application instances it runs being a possible guideline for that), and be required to have at least that many TCBs plus one. It should then allocate a TCB to a new session from that pool on an LRU basis, so that TCBs associated with active sessions tend to stay open. If you do that, I don't think you need to specify anything about session duration.

My two yen...

---

From: Joe Touch <[email-masked]>
Date: Wed, 22 Jun 2016 16:57:03 -0700

On 6/22/2016 4:46 PM, Fred Baker (fred) wrote:
> The two hour lifetime of a session also seems heavy-handed (and I would say the same about a two hour minimum keep-alive interval).
That's from RFC1122:

         4.2.3.6  TCP Keep-Alives

            Implementors MAY include "keep-alives" in their TCP
            implementations, although this practice is not universally
            accepted.  If keep-alives are included, the application MUST
            be able to turn them on or off for each TCP connection, and
            they MUST default to off.

            Keep-alive packets MUST only be sent when no data or
            acknowledgement packets have been received for the
            connection within an interval.  This interval MUST be
            configurable and MUST default to no less than two hours.