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

[Alexander Zimmermann <[e-mail]>]

Hi Pasi,

thank you so much for the review. Comments are inline.

Alex

Am 08.09.2009 um 21:53 schrieb Pasi Sarolahti:

> 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"

Ok, we will change the title to "Making TCP more Robust to Long  
Connectivity
Disruptions". I'm also fine with changing it to something completely  
different,
are there any suggestions?

>
> * 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.

Ack. We will come up with something describing the issues you mention.
This seems to be a general problem for the IP layer (see below).

>
> * 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?)

In our algorithm we assume that the ICMP error message is passed
up from the IP layer, for the corresponding connection.
(See RFC 1122 Section 4.2.3.9 ). Ack, we will make this more clear.
However, I think the fact that the ICMP message already got
demultiplexed implies that the ICMP DU contains a TCP header, otherwise
we would "not see" this ICMP DU at this layer.

>
> * 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.

Depends on what you mean with "real world" we have already presented
some measurements with Linux routers, see the slides from the last
IETF meetings. And the ICMP DU arrive surprisingly reliable.
However, we did not test juniper or cisco yet...

>
> * 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.

Ack.

>
> * 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.

Yeah, I know :-) See Appendix A: TODO list

> * 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 don't think there is something relevant. I only thought
that 1323bis would be published before "our" RFC and wanted to
avoid an outdated reference list ;-).

>
> 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: [phone]
>> ---------------------------
>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm



//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: [phone], fax: [phone]
// email: [e-mail]
// web: http://www.umic-mesh.net
//