[Trigtran] TRIGTRAN protocol principles and considerations

draft-dawkins-trigtran-framework-00.txt

A few late, but short, queries/comments.

1) Section 4: I don't quite understand what you mean by point 3 in your
list:

"* Trigger coverage requests and notification requests will be piggy-backed
on existing traffic ("setting a bit")."

Can you be a bit (sorry about the pun) more explicit. You seem to be hinting
at a mechanism that I do not yet understand.

2) Section 5: "Trigger: Connectivity Restored", following receipt of this
event you suggest that it is safe to "Probe" for connectivity, the sender
also has to decide an appropriate (conservative) RTO value to use, if this
probe is successful. Setting the correct RTO may need to be considered
carefully - since, if many PRTTs have passed, you no longer have an accurate
view of the RTT, and perhaps you need to be even more conservative if the
restored path could have been a result of a change in the link(s) being
used. 

3) Section 7.1: The motivation for a sender to process and utilise ICMP
source quench messages was also somewhat unclear at the time. Senders had no
incentive to respond to ICMP source quench messages - if they did so, they
were being "polite" to other network users, but did not themselves
necessarily see decreased delay or increased throughput. In a shared
bottleneck topology, those senders that responded to ICMP source quench
would likely experience reduced capacity as a result. IMHO the incentive to
use this was not correct. The incentive to use was better for PMTU-D, since
larger MSS (or less fragmentation) improved TCP performance.

4) Section 7.2: Perhaps it would be useful to also note the need to think
about the issues concerning traversal of NAT, NAT-PT and TCP-PEP. I can't
see that these are show-stoppers in any way, since the triggers themselves
are advisory, and the discussion covering firewalls may also be approriate
to these issues, at least at a top level.

Gorry Fairhurst

_______________________________________________
Trigtran mailing list
Trigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/trigtran

[Trigtran] TRIGTRAN protocol principles and considerations - "set a bit"