[Tsvwg] comments on draft-dawkins-trigtran-linkup-01

[Aaron Falk <[e-mail]>]

Spencer, Carl-

I just read through draft-dawkins-trigtran-linkup-01.txt and have a
couple of comments.  I'm not sure if this document is on the agenda
for tsvwg this IETF so I'm sending my comments now.

Hope this is helpful,

--aaron

--------------

In section 2.3, you say:

   Hosts supporting TCP-based applications over subnetwork interfaces
   subject to multi-second outages MAY perform the actions described
   in Section 3. These actions are more attractive for TCP
   implementations used with "human-in-the-loop" applications, but are
   safe for any TCP-based implementation.

Just to be clear: this proposal is only for end-systems, right?  Not
for routers?  The text here is clearly talking about hosts but later
in section 3 you talk about subnetworks.  The proposal seems a little
vague on this.  I feel like you are saying that he retransmitted
packet may come from a router along the path (as suggested in
draft-ietf-pilc-link-design) but the language seems to imply that it
is _hosts_ saving and retransmitting the packets.  A block diagram
would help. :)

Because, if it is the sender saving and retransmitting the packets and
the sender directly connected to the wireless interface, the question
comes up: why not just kick the RTO timer when the interface comes
back up, as Phil Karn suggested?

----------------

Section 3.1 "Layering  Violation Tradeoffs"

This section is quite confusing.  I don't know what is meant by a
"subnetwork implementation".  At a minimum it's mis-titled.  It
doesn't say why one should be concerned about layering violations, nor
what the tradeoffs are.

----------------


In section 3. "When a Local Interface Returns to UP", you say:

   When the subnetwork implementation detects that a local interface
   has returned to "UP" status, the subnetwork implementation MAY
   retransmit the last packet stored for each TCP connection.

(Again: the subnetwork vs. end-host issue.)

My concern here is that the proposal in this draft is for links that
are down for long enough that recovering from an RTO is onerous.
Links that are down for only a few RTTs should be allowed to recover
using the existing algorithm.  So, I think you should say something
about how long a link is down before engaging in this behavior.  For
example, you might say 'the local interface has returned to "UP" and
the/one/all connection(s) are in RETRANSMISSION-WAIT.'  Of course,
this means makes implementation a bit harder since you a) need to be
on the end-system and b) need to correlate packets you are saving to
resend with the state of the connection.  A simple approach would be
to have the implementor fix a lower bound in seconds.

--------------

Finally in Section 3. you need to say something about aging old
buffered packets.  I have this vision of hosts with lots of idle or
even closed connections, a link going down and up triggering a storm
of saved packets from hours/days previous trying to restart
connections that are idle.  The hosts and connections will probably
survive but it seems an un-neighborly thing to do to the network.  So,
I'd propose a setting maximum time that packets can be held, say 1 MSL
(2 minutes, I believe), by any entity doing this algorithm.

--------------


_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg