On 10/12/2016 2:32 AM, t.petch wrote:
> Looking some more, I think that the carefully defined terminology is not
> then used so carefully!
I agree; we have been asking for this sort of feedback for several
years. I'm glad to finally receive it, though I would note that the
focus has been on converging on the details of advice first. Now that
we've done that, it's very useful to get this feedback so we can update
> s.2.2 defines the term 'forwarder' but by 3.5, 'router' moves in and
> forwarder is never used again. Is this of technical significance, or
> just a question of the style of the author(?s)? I think the latter, but
> see it as introducing uncertainty.
It's used in 2.2 because of the confusion that arises when we talk about
hosts and routers. Many documents (and entire bodies of IETF work)
erroneously imply or assume that these are mutually-exclusive functions.
Most devices we call routers include all the requirements of being a
host because control protocols originate or terminate at that node.
"Forwarding" is intended to describe the exclusive functions a router
performs that a host does not.
The Internet architecture is based on the concept of a host, a
forwarder, and a link, but the Internet is implemented with devices of a
host, a router (which is both a forwarder and a host), and a link.
It's important to discuss this issue, which is why it is grounded in the
definitions. I will add text to explain why the rest of the doc refers
to the device (router) rather than the function (forwarding).
> s.2.2 defines Link MTU, Path MTU, Tunnel MTU but the document then uses
> link MTU, path MTU, tunnel MTU. A common convention is for capitalised
> words to have a particular meaning, lower case not (a bit like SHOULD
> and should)
It's also convention that sentences start with capital letters. In this
case, all list items start with a capital letter as well.
> so is this of technical significance, or just a question of
> the style of the author(?s)? I think the latter, but see it as
> introducing uncertainty.
don't think it's confusing, and all the terms defined have the same
issue, but it seems to be consistent (e.g., we don't use Path MTU
anywhere else except at the beginning of a sentence or a bullet). I'll
> s.2.2 defines ingress as
> 'the virtual link interface of a tunnel which receives
> messages within a node, encapsulates them according to the tunnel
> protocol, and transmits them into the tunnel. '
> which I think of as rather a lot for an interface to do but equally not
> all that needs doing, such as finding a path, selecting an interface,
> finding link and path MTU, inspecting the packet for such as DF=1,
> fragmenting when called for and so on.
That's exactly correct - the other functions you describe are the
responsibility of the originating host or forwarder (router).
And that's not a lot for a link; that's exactly what all link layers do.
> It could be that ingress is intended to cover all these box functions.
> (I would like to use the term 'node' here but that has been defined as
> 'a device that can act as an endpoint or forwarder, which does not seem
> to fit here).
> But reading on, in figure 4, I see the box that has everything to do
> labelled I(ngress) which suggests that Ingress includes everything. But
> when I get to s.3.3, I encounter 'ingress nodes' (um oxymoron?) and then
> 'source (ingress) ' - what does 'source' add that 'ingress' does not
> already have? - and then I get a mixture in s.3.6 of 'ingress' and
> 'tunnel ingress' - what does 'tunnel' add that ingress is not already
> defined to have?
Good point to clarify.
The clarification will be intended to highlight the following:
- a tunnel ingress is an INTERFACE, not a node
- a node where the tunnel ingress is attached is just a node using a
So in the diagrams, the nodes should be labeled "ingress node" and that
term defined as "a node on which the ingress interface is attached".
> I think you get my laboured point. Technical writing, for me, is
> boring. Get a set of concepts, as small as is necessary, give them an
> identifier, easy to read, write, say as you read, and use them over and
> over again; boring, but easy to understand.
I agree, but it should be as simple as we can while still being clear.
It's tempting to have fewer variants of the different MTU values or to
merge the idea of a tunnel ingress as interface with an ingress as node,
but then we lose exactly the distinction that lets us correctly reason
about their role in the Internet architecture.
> (If I look at MTU, I expect I will find the same only more so).
> Tom Petch
> ----- Original Message -----
> From: "Joe Touch" <to...@isi.edu>
> To: "t.petch" <ie...@btconnect.com>; "Templin, Fred L"
> Cc: <email@example.com>
> Sent: Tuesday, October 11, 2016 4:22 PM
>> Hi, Tom,
>> I do agree that the terminology in the current version is confusing
>> it would be useful to be both more clear and more consistent.
>> As I noted, I'll discuss this with Mark further and revise.
>> On 10/11/2016 3:05 AM, t.petch wrote:
>>> ----- Original Message -----
>>> From: "Joe Touch" <to...@isi.edu>
>>> Sent: Monday, October 10, 2016 7:15 PM
>>>> HI, Fred (et al.),
>>>>> IMHO, your draft is getting wrapped up with too many new acronyms
>>> for no
>>>>> good reason when simple English-language text would make things
>>> easier to
>>>> We're dealing with legacy use of the term MTU and path MTU too,
>>>>> In 'draft-templin-aerolink', there are only five acronyms:
>>>>> MTU - the MTU of the tunnel as seen by the IP layer
>>>> That's the term we need to specify in more detail - to some, it's
>>>> one-hop IP MTU, to others it means path MTU, to others it means
>>>> would call egress reassembly MTU.
>>>> We need to either avoid the term MTU in our definitions or provide
>>>> adjective to specify each type (as I have done).
>>>>> MFU - the maximum fragment size within the tunnel
>>>> This is confusing because the fragment could refer to the payload
>>>> entire IP datagram.
>>>>> MRU - the maximum reassembly size supported by the egress
>>>>> ENCAPS - the size of the encapsulation headers inserted by the
>>>>> PTB - an IP Packet Too Big message
>>>> ICMPv4 or IPv6...
>>>> You have omitted the concept of a transit MTU, which is only the
>>>> when the ingress supports fragmentation and reassembly (which not
>>>> tunnels or links do).
>>>> Therein lies the problem with "simple" English, IMO.
>>> I echo Fred's point about acronyms; yes you need adjectives to
>>> MTU but when I read
>>> ' The TMTU (d) is not limited by TIMTU (e), but by ERMTU (f), the
>>> tunnel equivalent of RMTU (c). '
>>> I have to pause, expand and think. Spelling out the adjectives
>>> time would make it easier.
>>> Likewise, when 'MTU' or 'protocol' or some such is unqualified, I
>>> to stop and think which is meant. I think that most uses of MTU
>>> have an adjective or two in front of them.
>>> I would say the same of protocol. At times, the I-D seems specific,
>>> that this is IP in IP and so protocol is IP but other usages seem
>>> generic. After all, you can tunnel Ethernet in ATM and while I
>>> that most of this I-D does not cater for that, I think there are
>>> places where 'protocol' is not limited to IP so if IP protocol (or
>>> protocol or IPv6 protocol) is intended, then I would write that
>>> Tom Petch
Int-area mailing list