Re: [tcpm] poll for adoption of long connectivity disruptions draft

[Pasi Sarolahti <pasi.sarolahti at iki.fi>]

Hi,

I just read the LCD draft. Technically it looks good, and I think it  
would be ok for the TCPM start working on this as a WG item for  
Experimental RFC.

Generally, I wonder if some kind of holistic overview of the  
documented TCP enhancements would be in place at some point. In the  
recent years quite a few of these have been introduced, that each help  
in a specific problem in some communication environments, but might  
not be so important for	others. It might be useful to check that there  
are no unwanted interactions between the different schemes, or whether  
from the documents it is clear to the implementors how to implement  
RFCs A + B + C in a coherent manner with minimal additional  
implementation complexity.

Then, some high-level comments on LCD draft:

* The title would benefit from some tweaking. Maybe its just a matter  
of changing "Make" => "Making"

* It might we worth noting in Section 3 when discussing ICMP message  
content that it assumes that the IP payload is not encrypted by IPsec.  
Probably other forms of tunneling might cause problems for ICMP, too.

* Section 4.2, algorithm: this is really a nit, but might want to  
clarify in step (5) that if ICMP DU contains non-TCP header it should  
be ignored, without affecting the algorithm (right?)

* It would be interesting to have an accompanying technical report on  
some (even preliminary) results on the performance improvements using  
the algorithm. It would also be interesting to have some understanding  
how often ICMP Destination unreachables actually arrive in case of a  
real connectivity disruption in real world.

* Section 4.3, second paragraph says that with this algorithm "it has  
been proved that the retransmission was not lost due to congestion".  
This is a little questionable claim. I believe the algorithm is safe  
enough in congestion control aspects, but I'm not convinced that  
successful termination of the algorithm proves there is no congestion.  
So some rewording might be in place here.

* Section 4.4: "TCP sender MAY use the following algorithm...." -- I  
believe something is missing here. There is no algorithm in this 3- 
line section.

* You might consider if you just want to normatively refer directly  
RFC 1323 instead of the 1323bis draft. Is there something that has  
changed in 1323bis that is relevant for this document? (sometimes  
normative references to work-in-progress drafts have caused additional  
delays in the RFC ed queue, although I don't think that is much of a  
risk here)

I will send some additional detailed nits directly to the authors.

- Pasi


On Sep 1, 2009, at 12:27 PM, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:

> Hello, the authors of the "Long Connectivity Disruptions" draft:
> http://www.ietf.org/internet-drafts/draft-zimmermann-tcp-lcd-02.txt
> have given a couple presentations to the WG now and asked if it
> could be considered as an item for the WG for Experimental.  If
> I'm not mistaken, there has been some positive feedback on the
> most recent incarnation, though not a lot, and not really any
> negative feedback that I could see.
>
> As chairs, David and I are asking the WG to voice whether we should:
>
> A) adopt this as a WG item for Experimental
> B) NOT adopt this as a WG item
> C) wait to decide (not ready)
>
> Please let us know what you think.
>
> ---------------------------
> Wes Eddy
> Network & Systems Architect
> Verizon FNS / NASA GRC
> Office: (216) 433-6682
> ---------------------------
>
> _______________________________________________
> tcpm mailing list
> tcpm at ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm