Subject: Re: [Int-area] Working group last call on draft-ietf-intarea-ipv4-id-update

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 9 Dec 2010 09:13:18 -0800

Folks: 

Given that this document, if approved, updates two Internet Standard (RFC 791 & 1122), and given the extensive text changes (~40%) brought in the last revision, I am not comfortable progressing this document without an adequate level of review, which we do not have (There hasn't been any follow-up to this 2nd WGLC.)

IOW -- silence is neither consent nor consensus.

If you wish this document to progress towards publication, please take some time to carefully review the last version and send to this mailing list your comments and state whether or not you believe it is ready for publication.

--julien

Christian Vogt wrote:
> 
> Folks:
> 
> This is a second working group last call for comments on the document
> "Updated Specification of the IPv4 ID Field":
> 
> https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/
> 
> At our meeting in Maastricht, several issues were raised with this
> document.  These have been addressed in the latest revision of the
> document.  Please read the document carefully, and comment on it on
> this mailing list by Friday, November 26, 2010.
> 
> - Julien and Christian
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 10 Dec 2010 11:44:54 +0800

Hi Julien,

Thanks for your kind reminder, I just read this draft, and have some
comments. In one sentence, I personally think this draft needs more
consideration and modification.

*1, Firstly, I agree the problem described in this draft, we should address
it, thanks to Joe.

*2, I suggest an informative section or appendix to be added in this draft.
The text should introduce what approaches may be considered (ie, possible)
to address the problem, and explain why the proposed modification is
selected.

*3, In my mind, there may be other ways to address the problem described in
this draft. For example, if we reduce MSL requirement. RFC1122 tells us
clearly, 
              The MSL controls the maximum rate
              at which fragmented datagrams can be sent using distinct
              values of the 16-bit Ident field; a larger MSL lowers the
              maximum rate.  The TCP specification [TCP:1] arbitrarily
              assumes a value of 2 minutes for MSL.  This sets an upper
              limit on a reasonable reassembly timeout value.
So to me, the simplest way to improve the "max rate" is to reduce MSL value.
I also think two-minutes-MSL is too longer for us today, nowadays there is
almost no two minutes delay in Internet, and 2-minutes-delayed-packet is
almost meaningless to Internet users. Of course, this approach can only
provide limited-times-extension, but, if we consider the "max rate" at this
point, we can use half-minutes-MSL (1/2 minutes is acceptable to me) to get
a 25.6 Mbps (1500Byte MTU). 25.6 Mbps for each flow, notice this "max rate"
is only for single flow but not for my host or interface, is enough to me,
too, at present. I can get HDTV, HTTP streaming, fast-enough file download,
etc. 
However, this draft provides an unlimited-times-extension space, which can
fit our future requirements. 
NOTE I'm not proposing another approach, my point here is to list all
possible approaches. This is just like a deal, we need some balance, imho.

*4, I suggest we study all fields related to fragmentation, at least
"Identification", "Flags" and "Fragment Offset". That's said, I dislike the
titles of draft and section 6.1 (IPv4 ID Used Only for Fragmentation), not
only ID is used only for fragmentation. Another point is, 13-bit-long
"Fragment Offset" is wasteful nowadays. Considering 16-bit packet length
field, 13-bit fragment offset can afford 8-Byte-MSS, but is there
8-Byte-MSS-link in the word now? 8 Byte is not enough for IP header! So if
the least MSS is 512 Byte (just for an example) in the world, then 7-bit
Fragment Offset is enough. 
So my comment here is, we should consider these three fields together, and
IF POSSIBLE, provide a total proposal, some bits may be released, reserved
for further usage, e.g. QoS or congestion management. I'm not sure this is
right, but surely this would make the issues more complex.

*5, The most important point, if I make mistakes, please let me know. The
negative comment to this draft, should we consider the router-fragmentation
case? Or we disable router-fragmentation?
In the following scenario,

Host A -----------------------Router--------------------------Host B
          Link1                 link2

Suppose Link1 MTU is 1024 Byte, and link2 MTU is 512 Byte, and Host A take
1024 as its PMTU (Host A somehow mis-operates here, or doesn't update its
PMTU in time). Host A transmits two packets (1024 Byte each) to Host B,
called Packet-A and Packet-B, with reused ID (ie, same packet ID). The
packets are fragmented by the router, into four packets, called Packet-A-1,
Packet-A-2, Packet-B-1, and Packet-B-2. How can Host B deal with this
situation. An example in extreme case, Host B receives only Packet-A-1 and
Packet-B-2, perhaps host B reassembles these two packets to an invalid IP
packet? But this seems right to Host B, right?

To avoid this trouble, the router has to re-write the ID field, but the
router further has to keep some packet-state-information (because same
ID-input should lead to different ID-re-written),
RFC791 states,
      The originating protocol module of an internet datagram sets the
      identification field to a value that must be unique for that
      source-destination pair and protocol for the time the datagram
      will be active in the internet system.

The requirement is only for host, "the originating ... sets the ID ... must
be unique ...", will we add this requirement also to routers? This is a huge
challenge to routers, I think. I personally dislike this idea, if the action
is taken, then the update text should also included in the draft.

Best regards,
Xiangsong

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Laganier, Julien
> Sent: Friday, December 10, 2010 1:13 AM
> To: Internet Area Mailing List
> Cc: Christian Vogt; Joe Touch
> Subject: Re: [Int-area] Working group last call on
> draft-ietf-intarea-ipv4-id-update
> 
> Folks:
> 
> Given that this document, if approved, updates two Internet Standard (RFC
791
> & 1122), and given the extensive text changes (~40%) brought in the last
> revision, I am not comfortable progressing this document without an
adequate
> level of review, which we do not have (There hasn't been any follow-up to
this
> 2nd WGLC.)
> If you wish this document to progress towards publication, please take
some
> time to carefully review the last version and send to this mailing list
your
> comments and state whether or not you believe it is ready for publication.
> 
> --julien
> 
> Christian Vogt wrote:
> >
> > Folks:
> >

---

From: Joe Touch <[email-masked]>
Date: Thu, 09 Dec 2010 22:30:31 -0800

Hi, Xiangsong,

Thank you for your feedback. Some notes below.

On 12/9/2010 7:44 PM, Xiangsong Cui wrote:
...
> to address the problem, and explain why the proposed modification is

This document is not intended to describe all possible ways of partially 
dealing with this issue. It's not clear why that would be useful.

> So to me, the simplest way to improve the "max rate" is to reduce MSL value.

An MSL value that is 60 times smaller (2 seconds) is clearly too small, 
but also clearly not appropriate for even existing sustained 1 Gbps 
host-host transfers (it would support only ~400 Mbps). That can be 
pointed out in a single sentence.

> almost meaningless to Internet users.

It's worthwhile to note that there are mechanisms that are intended to 
try to restore intermittent outages by buffering packets that take 
advantage of the current MSL. It's also not uncommon to find ~10 second 
latencies for home uplinks (e.g., when buffers are overloaded and RED is 
not implemented).

This doc, however, is not intended to be a study of all possible issues 
here. The point, IMO, is that the ID should never have had any meaning 
when the packet wasn't fragmented - independent of the MSL issue.

 > Of course, this approach can only

100 Mbps and higher transfers are quite typical, and have been for over 
a decade. I.e., this isn't 'future'; if anything, it's past.

> only ID is used only for fragmentation.

Can you explain "study"? These flags have known meanings, as defined in 
RFC791 already.

As to the draft title, as far as I can tell it explicitly states the 
purpose of the document. Can you let us know what you would suggest as 
an alternative? (same for section 6.1; that's the point of the section, 
but if you have a suggestion for a change, can you let us know?)

 > Another point is, 13-bit-long

The fragment offset is in units of 8 octets (64 bits). For a 512-byte 
datagram, that would require only 4 bits of offset.

These are interesting issues, but have no bearing on the assertion (in 
this doc) that the ID is meaningless if the packet is not already 
fragmented and cannot be further fragmented.

(FWIW, MSS is a transport-layer concept; IP has datagrams, not segments)

> right, but surely this would make the issues more complex.

The bits are NOT intended to be available for any purpose. That is not 
the function of this document. The ID bits that are not used if a packet 
is not fragmented and not fragmentable MUST be ignored by the receiver.

Overall, the point of this document is the *smallest* change to the 
meaning of the IP header that is reasonably consistent with *current* 
use. We know of no use of the IP ID when a packet has not been 
fragmented, despite such being noted in RFC1122.

> packet? But this seems right to Host B, right?

That is correct.

> ID-input should lead to different ID-re-written),

The router should not try to fix this situation. Consider the following 
case:

Host A ---- Router 1 ---- Router 2 ---- Router 3 ---- Host B

The situation in your case can occur at ANY router in this example - 
router 1, 2, or 3. None of these routers can know whether the packets 
they see are already reordered (due to multiple paths between Host A and 
the router, or between routers).

Overall, the error here is twofold:

1) the host has emitted two packets with the same ID (and presumably the 
same protocol, and endpoint addresses) within one MSL

>        will be active in the internet system.

Yes, and in your example host A has failed this requirement.

> be unique ...", will we add this requirement also to routers?

Routers are not supposed to modify the ID field - even to be helpful. So 
no, we don't need to add this requirement. If anything, we should 
already know that a router MUST NOT modify the ID field anyway.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 09 Dec 2010 22:35:57 -0800

Minor correction:

On 12/9/2010 10:30 PM, Joe Touch wrote:
...
> same protocol, and endpoint addresses) within one MSL

and

2) the router is using the wrong path MTU (as already noted)

(sorry for the omission)

Joe

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 10 Dec 2010 15:53:19 +0800

Hi Joe,

Please see my comments inline.

> From: Joe Touch [mailto:[email-masked]]
> Sent: Friday, December 10, 2010 2:31 PM
> To: Xiangsong Cui
> Cc: 'Laganier, Julien'; 'Internet Area Mailing List'; 'Christian Vogt'
> Subject: Re: My comments // RE: [Int-area] Working group last call on

To me, this is a major change, so I would like to support this after this
has been proved to be mandatory.

> pointed out in a single sentence.

Oh, sorry, I missed host-host communication.

> a decade. I.e., this isn't 'future'; if anything, it's past.

Here I'm mainly on the standpoint of Internet, as to IP, I admit higher
speed limitation is important to IP.
My implicit point is, IETF may take this as a weapon to drive IPv6
transition (I admit this is wrong, absurd ...). IPv4 is surely with many
born-defects for current and future network, users can not get perfect
solution from a 30-years-old protocol, this is reasonable. So, IPv4 has been
providing its "best effort" service, if users expect to get better
performance, please, please go to IPv6.

> Can you explain "study"? These flags have known meanings, as defined in

I mean, giving these flags newly defined meaning or operation rule, just as
this draft defines new (or say update) "rules" to ID field, although RFC791
has defined that.
"Study" is the way to this result.

> but if you have a suggestion for a change, can you let us know?)

Yes, I agree this title has already states the purpose of this document,
here my point is, I suggest the document is extended to cover a bigger
scope.
I would like to see a title like "IPv4 Fragmentation Mechanism Update", or
something others.

> datagram, that would require only 4 bits of offset.

Thanks for your correction.

> fragmented and cannot be further fragmented.

In my understanding, I take them all as fragment-related issues, perhaps
this is not in the charter (sorry I didn't read the charter of intarea wg
carefully), but I would like to see all these issues to be addressed
together. That would be perfect, imho, otherwise, when the fragment offset
field needs modification (if this happened), some trouble on ID field may be
met.

> is not fragmented and not fragmentable MUST be ignored by the receiver.

Yes, I agree these issues are not in the scope of this document, I just want
to say, that may be related to this draft.
The issues may influence ID field, for example, just only for example, the
length of ID may be changed. 
A direct question is, when ID is for unique usage (in the period of MSL),
the length of ID field is 16 bits, now the precondition is changed, do we
still need a 16 bit length ID?

> same protocol, and endpoint addresses) within one MSL
-------------------------------------------------
> 2) the router is using the wrong path MTU (as already noted)
-------------------------------------------------
[Note, I merge Joe's message here]
> Yes, and in your example host A has failed this requirement.

Yes, you are right, this rule is very important to host, however, the host's
behavior is correct in the update, "IPv4 ID uniqueness applies to only
non-atomic datagrams". 
My point here is, the draft is trying to change this requirement, so the
draft is bringing danger to hosts.

> already know that a router MUST NOT modify the ID field anyway.

So, do you mean, the host MUST NOT transmit packet larger than PMTU? Or
Fragmentation mechanism SHOULD be used ONLY in the host
(Router-fragmentation is disabled in fact)?
(The implicit requirement in my mind is, the PMTU discovery mechanism MUST
supply enough performance to host.)

Best Regards,
Xiangsong

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Dec 2010 00:31:56 -0800

> has been proved to be mandatory.

Can you explain how the document does not already do this?

And the change is basically to assert that the ID is meaningless if the 
packet isn't fragmented and has DF==1. Although that is a large change, 
it is also already deployed (as noted in the doc, there are 
implementations that just use ID=0 repeatedly in such cases).

...
> performance, please, please go to IPv6.

Users have been using IPv4 at well over 100 Mbps for 10 years, and are 
expected to continue to do so. They have not used that as a rationale to 
switch to IPv6 for that time, so it's not clear why repeating that 
argument would make them switch now.

> "Study" is the way to this result.

That is a *major* change. This document is trying to avoid a major 
change like that, especially one that would not be backward compatible. 
(the current change is largely of definition; it is backward compatible 
to compliant implementations *except* only those that delete duplicates 
based on ID repetition, and again, there is no evidence that was ever 
implemented).

By your previous argument, however, I would claim that the need for 
changes the meaning of the flags would be a reason to go to IPv6 (where 
fragmentation is an option, and options can more easily be changed).

> here my point is, I suggest the document is extended to cover a bigger

That scope is, AFAICT, experimental.

> I would like to see a title like "IPv4 Fragmentation Mechanism Update", or

You are welcome to write that as a separate document, IMO. I don't think 
that this change should be coupled with the *potential* set of changes 
you are considering (and have not worked out yet).

...
(cutting to the key point)
> to say, that may be related to this draft.

They're all related to fragmentation, but it's not clear why they should 
be in a single document. IMO, deprecating the meaning of the ID field 
when a packet is atomic (not fragmented, and DF==1) is a single, 
specific change that can go proposed standard now.

The changes you are considering are much larger, not 
backward-compatible, and have not been worked out.

...
> still need a 16 bit length ID?

If we need a larger field, we should use IPv6 (again, by your argument 
above). If we need a smaller field, why do we have a larger one in IPv6 
- the protocol you consider more modern?

I'm not sure what you're getting at, but in any case it seems orthogonal 
to the scope of this document.

...
(example where a host repeats an ID within one MSL, and the packets are 
fragmented, i.e.:
Host A transmits two packets (1024 Byte each) to Host B, called Packet-A 
and Packet-B, with reused ID (ie, same packet ID). The
packets are fragmented by the router, into four packets, called
Packet-A-1, Packet-A-2, Packet-B-1, and Packet-B-2.
)
> behavior is correct in the update, "IPv4 ID uniqueness applies to only

The host has repeated an ID within one MSL, and both packets have been 
fragmented. In that case, one of the following must be true:

a) the host repeated the ID within one MSL and either emitted fragments 
OR did not set DF==1; this violates RFC791 - and this draft does not 
change that. Packets emitted as fragments or that can be later 
fragmented MUST NOT repeat the ID within one MSL

b) the host repeated the ID within one MSL, did not fragment, and set 
DF==1, *AND* another device ignored the DF bit and fragmented the 
packets anyway; this violates RFC791 - and this draft does not change 
that. Packets with DF==1 MUST NOT be fragmented.

> draft is bringing danger to hosts.

See above; the draft does not change the requirement of RFC791 in this case.

> So, do you mean, the host MUST NOT transmit packet larger than PMTU?

No. A host has two choices when sending a packet:

a) make the ID unique for one MSL; in that case, the host MAY set DF=0, 
or MAY fragment the packet as it sends it, or both.

	when doing so, the host MUST rate-limit to ensure the IDs are
	appropriately unique

b) make the ID non-unique; in that case, the host MUST NOT fragment it 
as it sends it, and MUST set DF=1

	when doing so, the host need not rate limit

If the host wants to test the PMTU (e.g., PMTUD, or PLPMTUD), it would 
use (b). If the host wants to ensure fail-safe operation for PMTUD when 
ICMPs could be lost or blocked, it should use (a).

 > Or

The router MUST honor the DF bit in packets it sees. Routers that ignore 
the DF bit and fragment packets where DF==1 are already violating RFC791.

Routers MAY fragment packets whose DF==0, as per RFC791 - this draft 
does not change that.

Hosts MAY fragment packets they emit, and those packets MAY have DF=0 
(allowing further fragmentation) or DF=1 (prohibiting further 
fragmentation), as per RFC791 - this draft does not change that.

I hope this clarifies what this draft does and does not change.

Joe

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 10 Dec 2010 17:28:52 +0800

Hi Joe,

[snip]
> implementations that just use ID=0 repeatedly in such cases).

Yes, I agree this works, but I want to say, the host loses flexibility when
it sets DF==1, especially for wireless host. As I said, the host has to
implement a high-performance PMTU discovery.
One example is MIF (Multiple Interface) device, the interfaces provide
different MTU. When the communication is established, the host (the peer of
MIF device) would take the larger as the PMTU. But when the larger-MTU
interface is out of service in the MIF device side, or the MIF device is
implementing flow mobility, ie, MIF device changes its traffic from one
interface (larger MTU) to another interface (smaller MTU), if DF flag of the
packets are set to 1, then, some packet would be dropped in the path of
smaller MTU interface.

So, when DF==1 is set, the flow mobility or hot-interface-standby is
temporarily lost, this is uninfluenced to host with one interface, but for
those MIF device, flexibility is the cost of "Max rate".
To myself, I would like to prefer my peer set DF==0, although I can only get
a relatively low "max rate".

> - the protocol you consider more modern?

There are different preconditions. In my understanding, IPv6 takes larger ID
because IPv6 continues the principle of "ID uniqueness". Under this
principle, ID length is related to "max rate", however, if this principle is
destroyed, then it is another case.

[snip]
> ICMPs could be lost or blocked, it should use (a).

OK, I agree these all.

I agree this draft is OK as a standard option to host, my concern is about
implementation or host operation, which should not block the draft.

Thanks for your patient discussion.

Best regards,
Xiangsong

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 10 Dec 2010 17:40:40 +0800

Hi Chairs,

I'm OK to this draft now, sorry for the confusion.

My initial though was the result of wrong impression, where I thought most
packets in the world are set DF==0. But after checking the actual traffic
flow in Internet, I found this is not true. Since hosts have already set
DF==1, my negative comment (ie, *6) to this draft is not appropriate.

Regards,
Xiangsong

Behalf
> Of Xiangsong Cui
> Sent: Friday, December 10, 2010 5:29 PM
> To: 'Joe Touch'
> Subject: Re: [Int-area] My comments // RE: Working group last call on