Subject: [Gen-art] gen-art review of draft-ietf-tcmp-tcp-uto-09.txt

From: Scott Brim <[email-masked]>
Date: Mon, 24 Nov 2008 11:40:02 -0500

I have been selected as the General Area Review Team (Gen-ART) 
reviewer for this draft (for background on Gen-ART, please see 
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). 
 
Please resolve these comments along with any other Last Call comments 
you may receive. 
 
Document:           draft-ietf-tcpm-tcp-uto-09.txt
Reviewer:           Scott Brim
Review Date:        24 November 2008
 
Summary: This draft is basically ready for publication, but has nits
         that should be fixed before publication. 
 
Comments: 

(1) Technical:

  - Since a UTO can apparently be sent at any time, what happens if a
    UTO is received that shortens the timeout and there are
    unacknowledged packets that are already beyond the new timeout
    value?  

  - Is it intended that the ENABLED flag applies to both sending and
    receiving the UTO?  It seems to be, but I want to be sure.  If
    that is the intention, could you make it clearer?

    It certainly applies to a received UTO:

      "This adaptation only happens if the other end of the connection
      has explicitly allowed it (both ENABLED and CHANGEABLE are
      true)."

    but it seems to apply to sending a UTO as well:

      "Before opening a connection, an application that wishes to use
      the UTO option enables its use by setting ENABLED to true."

(2) Editorial:

  1. Introduction

    - "If an end-to-end connectivity disruption lasts longer than the
      user timeout, no acknowledgments will be received for any
      transmission attempt, including keep-alives, and the TCP
      connection will close when the user timeout occurs."

      I would rephrase for clarity:

        If an end-to-end connectivity disruption lasts longer than the
        user timeout, a sender will receive no acknowledgments for any
        transmission attempt, including keep-alives, and it will close
        the TCP connection when the user timeout occurs.

    - "One example of such a scenario is mobile hosts that change
      network attachment points based on current location."

      Drop the last part as redundant:

        One example of such a scenario is mobile hosts that change
        network attachment points.

    - "For example, an orbiting node on a non-geostationary satellite
      might experience connectivity disruptions due to line-of-sight
      blocking by other planetary bodies."

      Let's see, it's orbiting the Earth although not geostationary,
      and experiencing disruption because other planets are blocking
      its transmissions ... it must be communicating with something
      far out in the solar system.  Either it doesn't matter whether
      the orbit is geostationary (or whether it is orbiting at all),
      or disruptions won't be due to planetary bodies.  How about:

        For example, a node in space might experience connectivity
        disruptions due to line-of-sight blocking by planetary
        bodies.  

Scott

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

---

From: Lars Eggert <[email-masked]>
Date: Fri, 28 Nov 2008 15:08:13 +0200

Hi, Scott,

thanks for the comments.

>    unacknowledged packets that are already beyond the new timeout

Good point. There are basically two choices: Apply the new UTO already  
to the current timeout event, or start using the new UTO for future  
timeout events. I believe that simply starting to use the new value  
immediately is easiest for implementors, but because reaction to UTOs  
is purely a local thing, I'm not sure if the draft should require any  
specific behavior. We can mention the two choices, if folks think that  
would be useful - tell us.

>      the UTO option enables its use by setting ENABLED to true."

Correct, it applies for both sending and receiving. Can we make this  
clearer in the text somehow?

> (2) Editorial:

I applied all of these in my working copy.

Thanks,
Lars

---

From: Scott Brim <[email-masked]>
Date: Sun, 30 Nov 2008 14:18:08 -0500

> clearer in the text somehow?

Perhaps, in the beginning of Operation (3), you simply change

   ENABLED (Boolean)
      Flag that controls whether the UTO option is enabled for a
      connection.  Defaults to false.

to

   ENABLED (Boolean)
      Flag that controls whether the UTO option is enabled for a
      connection.  This flag applies to both sending and receiving.
      Defaults to false.

swb