Re: [TERNLI] Request for review - Questions from rev -07?

[Gorry Fairhurst <[e-mail]>]

I some questions and comments that I'd like to understand the answers 
to, please see below.

Best wishes,

Gorry

---

COMMENTS on rev -07
----
1) Definitions: Strong End System Model
/does not correspond to the physical interface/
-  Are these addresses at the link or network layer?
- I can't quite tell from this what is meant, could it please be 
rephrased ro be more clear?
Definitions: Weak End System Model
- Is this then, the "normal" IP host behaviour?
----
2) Section 1.4.2 Transport Layer
   /For example, the Transport layer may utilize the receipt of a "Link
    Down" indication followed by a subsequent "Link Up" indication to
    infer the possibility of non-congestive packet loss during the period
    between the indications, even if the IP configuration does not change
    as a result, so that no Internet layer indication would be sent./
- OK, but this example assumes that the transport layer knows the
indication came from a link forming a part of the path, for example it 
was the directly connected link to the sender or receiver. Could this be 
explained in the text perhaps?
----
3) Section 1.4.2 Transport Layer
   /Since hosts implementing "Path MTU Discovery" [RFC1191]
    use Destination Unreachable code 4, they do not treat this as a hard
    error condition./
- I suggest you also cite the recommended successor,
"draft-ietf-pmtud-method-11", which will be RFC before this I-D is
published. This does NOT rely on vulnerable network-layer indications
using ICMP to perform path MTU discovery.
----
4a)  Figure 1:
/MTU/
- Should this transport layer segment size, MSS?
- IMHO, this little difference is important, since it reflects the
indirect communication between layers that is spoken about later (i.e. 
MSS is set as a result of local MTU and discovered PMTU).
- Should this therefore perhaps also mention cached PMTU value for the
path as a network property?
----
4b) Section 2.3.2
   /Where a proposal involves recovery at the transport layer, the
    recovered transport parameters (such as the MTU, RTT, RTO, congestion
    window, etc.) should be demonstrated to remain valid.  /
- see above, MTU is not a transport parameter, "MSS".
- As previous you could also add the Internet layer PMTU as a parameter
that could be re-verfied after a potential path change.
---
5) Section 2.9
   /As noted earlier, the transport layer may take the state of the local
    routing table into account in improving the quality of transport
    parameter estimates.  For example, by utilizing the local routing
    table, the Transport layer can determine that segment loss was due to
    loss of a route, not congestion. /
- This causes me to worry.
- At the moment it does not mention the corresponding important issue of
congestion control - absence of positive feedback that the path is sending
data end-to-end must be heeded, although of course, it seems plausible to
consider such a signal as a "lack" of congestion information, and
therefore to trigger congestion control probing.
----
6) Section 2.9
/[b]  Mitigation of security vulnerabilities.  Transported link
      indications that modify the local routing table represent routing
      protocols, and unless security is provided they will introduce the
      vulnerabilities associated with unsecured routing protocols.  For
      example, unless schemes such as SEND [RFC3971] are used, a host
      receiving a link indication from a router will not be able to
      authenticate the indication.  Where indications can be transported
      over the Internet, this allows an attack to be launched without
      requiring access to the link./
- This example mixes up the Internet Layer (SEND, routing, etc).
- Is there a good transport example?
----
7) Section 2.9
/[d]  Mapping of Identifiers.  When link indications are transported, it
      is generally for the purposes of saying something about Internet,
      Transport or Application layer operations at a remote element.
      These layers use different identifiers, and so it is necessary to
      match the link indication with relevant higher layer state.
      Therefore proposals need to demonstrate how the link indication can
      be mapped to the right higher layer state.   For example, if a
      presence server is receiving remote indications of "Link Up"/"Link
      Down" status for a particular MAC address, the presence server will
      need to associate that MAC address with the identity of the user
      (pres:[e-mail]) to whom that link status change is
      relevant./
- All seems true... but presence isn't a classic transport-layer example,
please find an example from SCTP, TCP, UDP, DCCP, etc...
- And at the transport-layer entity would need to associate each
indication with a corresponding specific (or set of) transport sessions
(port,address) combination, that are impacted by the change... which is
even more tricky ;-)
---
8) Section 2.9 [d]
- This should, IMHO, also mention that transport sessions are not 
necessarily
visible to link entities generating transported link indications due to
various things, (or mention in section 4.3?) e.g.:
* Load-sharing between multiple links
* VPN and IPsec
* Tunnel overlays, including mobile IP (that do not prevent access to
higher layer headers, but would require parsing of multiple protocol
headers).
---
9)
/  This way transport parameters are not adjusted as though congestion
    were detected when loss is occurring due to other factors such as
    radio propagation effects or loss of a route (such as can occur on
    receipt of a "Link Down" indication)./
- Can we be more careful here in what we are asserting?
- This current statement seems dangerous... A given basis for congestion
control is that the sending transport has consumed capacity on the path 
it will use and that it has reasonable evidence that the path is capable 
of supporting the rate. A loss of data (even due to non-congestion
corruption) needs to be accompanied by a positive confirmation that 
other traffic was received, and does not necessarily tell the transport 
entity that the lost traffic WOULD have got through had it been sent at 
another moment (i.e. there could be another bottleneck). Done 
incorrectly, this will negatively impact other flows that share capacity.

- In short, any new work needs to assess the congestion control issues
that arise when the transport flow shares the path which it is using 
with other transport flows (these may, or may not, use the link that is
providing indications)?

===========================================