On 2/13/13 1:16 AM, Suresh Krishnan wrote:
Hi Brian,
On 02/11/2013 07:44 PM, Brian Haberman wrote:
Hi Suresh,
On 2/11/13 7:08 PM, Suresh Krishnan wrote:
Hi Brian,
Thanks for the review. I wanted to clarify three points that you
raised and I will ask the authors take care of the rest.
On 02/11/2013 04:11 PM, Brian Haberman wrote:
7. In Section 4.1.2, it would be good to describe any issues that the
approach has with the original use of the Identification field for
fragmentation reassembly. If a middlebox changes the ID field, weird
things can/will happen if those packets are fragmented somewhere.
Agree. I think this is precisely the reason that the mechanism for
putting the HOST_ID in the IP-ID is a non-starter.
I agree. But that rationale should be in the draft.
Ack. Med proposed a reference to RFC6864 Section 5.3. Is that sufficient?
That reference should be fine.
11. Is Section 4.6 theoretical or is there a specific reference that can
be added for this technique?
There are several mechanisms that use port sets for IPv4 address
sharing. A+P (RFC6346) is one such mechanism.
Then I would ask that a reference be put in to give readers an example.
OK.
15. Section 5
* Shouldn't there be an additional metric that covers the impact/cost of
needing client or middlebox code changes?
* Where did the 100% success ratio for IP-ID come from? There have been
documented cases of OSes setting the Identification field to zero. If
that is true, the success ratio can't be 100% can it?
This technique involves the translator (and not the sender) setting the
IP-ID field. That is why it can still work with OSes on senders setting
the IP-ID to zero.
You still have the issue of the middlebox setting that ID to something
that potentially impacts fragmentation reassembly. So, I would still
like to know how that 100% success ratio was collected.
Makes sense. I read the test result % to mean successful connection
establishment and identification. Med, can you elaborate a bit on what
exactly was tested and what the success % means.
Thanks
Suresh
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
