Mostly NiTs on link-id (-07 from IETF archive)

[Gorry Fairhurst <[e-mail]>]

While awakening several hours too early, after failing to adapt to US time
zones, I read the link-id again.

These comments refer to the ID revision 07 as held in the IETF archives.
Comments are mainly NiTs, and some consistency issues between pilc drafts.

Gorry Fairhurst

---------

In the section "Bandwidth on Demand (BoD) Subnets"

The ID says:
   "The resource shared may be a terrestrial wireless hop, a
   satellite uplink, or an end-to-end satellite channel."

These techniques are also used in other places than those listed. This
statement should be more inclusive. I suggest, for example:

   "Examples of the resource that may be shared include a terrestrial
    wireless hop, a cable modem uplink, a satellite uplink, and an
    end-to-end satellite channel."
    
---------

In the section "Recovery from Subnetwork Outages"

Para 6 of the ID says
   " Only a single packet per TCP connection, including ACKs, need be held
   in this way to cause the TCP sender to recover from the additional
   losses once the flow resumes.  [ARQ-DRAFT]"

Reference should come before the full stop.
 
---------

In the section "Recovery from Subnetwork Outages"

Para 7 of the ID says

 " Because it would be a layering violation (and possibly a performance
   hit) for IP or a subnetwork layer to look at TCP headers (which would
   in any event be impossible if IPSEC [RFC2401] encryption is in use),

*** But, still not sure about this - In [arq-id], section 3.3, we discuss
flow separation from the ARQ viewpoint and the practical difficulties in
doing this. Some of this surely applies here, in particular how is a network
device to identify TCP flows when IPSEC ESP is being used?
Life gets more tricky when the link includes tunnels/MPLS/etc. etc.

This problem issue should at least be highlighted somewhere!

It continues:

 ..."it would be reasonable for the IP or subnetwork layers to choose, as
   a design parameter, some small number of packets that it will retain
   during an outage."

The above sentence referes to one or more layers. Suggest:

 ..." it would be reasonable for the IP or subnetwork layers to choose, as
   a design parameter, some small number of packets that will be retained
   during an outage."

---------

In the section " CRCs, Checksums and Error Detection"

The final paragraph on IPv6, may be better placed as the third paragraph of
the section, since it follows logically the thoughts in paras 1,2. The rest
of the section seems to talk about link CRCs, which applies to IPv6 and
IPv4.

---------

In the section "CRCs, Checksums and Error Detection"

The paragraph below is possibly misleading:
   "For link layers that can differentiate between flows, it may be
   appropriate to reduce the error detection level for certain flows
   with large numbers of small packets, such as voice flows.  As such
   flows also benefit significantly from header compression, this should
   only be combined with a header compression scheme that is robust
   against residual bit errors [RFC3095]."

The requirement is not that the link layer is able to "differentiate between
flows" which simply means separation of the IP (or TCP) flows - something
which again, is not always possible or easy in the general Internet - it
also assumes that the link is able to identify the ***actual***
transport/application requirements. Reducing the CRC coverage / power should
only be done with the knowledge that the ***application*** can correctly
utilise corrupted information, doing this with arbitary application
protocols carries a serious danger that the link may deliver data with
errors which usually remain undetected by the application and hence can
corrupt the user data. This is evil. On the other hand, it can be good
if you have a suitable audio/video format and codec that's able to
accommodate loss using "erasure" techniques.

This paragraph needs to be changed.

---------

In the section "How TCP Works"

Paragraph 4:
   "TCP uses sequence numbering and acknowledgments (ACKs) on an end-to-
   end basis to provide reliable, sequenced, once-only delivery.  TCP
   ACKs are cumulative, i.e., each implicitly ACKs every segment
   received so far.  If a packet is lost, the cumulative ACK will cease
   to advance."

The last sentence isn't too clear. Slightly better:

"If an ACK is not received, the acknowledgment value carried in the
cumulative packet will cease to advance"

---------

The section "Delay Characteristics"

Says some important things, but also partly re-iterates what is said
elsewhere in the document on the impact of delay and also in the [arq-id].
It may be better to re-edit this or place it near the start? at the end?
of the document.

---------

The section "Bandwidth Asymmetries"

Since ASYM is now a working group document, which has been agreed, I think
you really should replace "[BPK98]" with a reference to the asym-id.  The
text in the link-id now pre-dates the text in the asym-id, which now talks
about much more than simple differences in link bandwidth and the few
mitigations cited in the link-id.

The ID says:
 "Some subnetworks may provide asymmetric bandwidth and the Internet
   protocol suite will generally still work fine."

Yes, but asymmetry may also arise because the forward and return paths used
by a TCP connection use different subnetworks with different available
capacities as well. This may be better:

 "Some subnetworks may provide asymmetric bandwidth (or may cause TCP
    packet flows to be experience asymmetry in the capacity) and the
    Internet protocol suite will generally still work fine."

I also dislike the work "bandwidth" here, because it's not bandwidth that
matters, but available capacity. Bandwidth asymmetry may lead to asymmetric
capacity.

The ID says:
   "Therefore, when the ratio of the bandwidth of the subnetwork carrying
   the data to the bandwidth of the subnetwork carrying the
   acknowledgments is too large, the slow return of of the ACKs directly
   impacts performance. "

Suggest you replace "bandwidth" by "available capacity" as below:

   "Since ACKs are generally smaller than data
   segments, TCP can tolerate some asymmetry, but as a general rule
   designers of subnetworks should avoid large differences in the
   incoming and outgoing bandwidth."

Is this really the correct recommendation? - I don't agree.

The phrase "should avoid" seems very strong, the asym-id gives many examples
of situations other engineering trade-offs result in high asymmetry.

I would suggest the best advice is something like:
   "Since ACKs are generally smaller than data
   segments, TCP can tolerate some asymmetry, but as a general rule
   designers of subnetworks should be aware that subnetworks with
   significant asymmetry can result in reduced performance, unless
   issues are taken to mitigate this [asym-id]."

The ID says:
   "One way to cope with asymmetric subnetworks is to increase the size
   of the data segments as much as possible.  This allows more data to
   be sent per ACK, mitigating the slow flow of ACKs.  Using the delayed
   acknowledgment mechanism [Bra89] that reduces the number of ACKs
   transmitted by the receiver by roughly half can also improve
   performance by reducing the congestion on the ACK channel.  These
   mechanisms should be employed in asymmetric networks."

The above paragraph is not advice to a link designer!

Anyway, this is one of a number of ***mitigations***, it only works in some
cases, it doesn't always help much - see [asym-id].

Can we delete the above paragraph?

The ID says:
   "Several researchers have introduced strategies for coping with
   bandwidth asymmetry.  These mechanisms generally attempt to reduce
   the number of ACKs being transmitted over the low bandwidth channel
   by limiting the ACK frequency or filtering out ACKs at an
   intermediate router [BPK98].  While these solutions mitigate the
   performance problems caused by asymmetric subnetworks, they do have
   some cost. Therefore, as suggested above, bandwidth asymmetry should
   be minimized in subnetwork designs."

This isn't in agreement with the discussion in the [asym-id]. Suggest you
replace this paragraph with:

   "Several strategies have been identified for reducing the impact of
   asymmetry of the network path between two TCP end hosts, e.g. [asym-id].
   These techniques attempt to reduce the number of ACKs transmitted over
   the return path (low bandwidth channel) by changes at the end host(s),
   and/or by modification of subnetwork packet forwarding. While
   these solutions may mitigate the performance issues caused by asymmetric
   subnetworks, they do have associated cost and may have other
   implications. A fuller discussion of strategies and their implications
   is provided in [asym-id]"

---------

In the section "Buffering, flow & congestion control"

Para 4 of the ID ends by saying
   "as a rule of thumb, each node should have
   enough buffering to hold one bandwidth*delay product's worth of data
   for each TCP connection sharing the link."

Is bandwidth - is this "link bandwidth"?
Is delay also "link delay" - or is it "path delay"?
- Can we make this clear?

---------

In the section "Multicasting"

There is no statement about IPv6, requiring multicast support at the network
layer - Thus is needed even if multicast is not natively supported by a
subnetwork.

---------

In the section "Broadcasting and Discovery"

There is no statement about IPv6!!!!!
 
---------

In the section "Security Considerations"

Paragraph 5 "The majority of the working group held that" --- I think
someone's already said something, but this is not necessarily true or useful
to say!!!

-----