Subject: Re: [Int-area] Review: draft-ietf-intarea-ipv4-id-update-00

From: Bob Briscoe <[email-masked]>
Date: Mon, 05 Jul 2010 10:12:04 +0100

Joe,

I haven't been able to get back to this thread - and now I'm taking a 
week off until next Sunday - terrible timing, but it is unavoidable.

I think it would help to reboot the conversation anyway - we were at 
cross-purposes. Can we go back to this point:

At 21:03 13/04/2010, Joe Touch wrote:
>Also, I had an off-line discussion with John Day just this AM, and he
>suggested I also address why generally just spinning down the MSL
>doesn't help much (even if we notch it down from 120 secs to 6 secs -
>which is double what I can see with a 3G card in real use - the
>host-host BW goes up from 6.4 Mbps to around 130 Mbps, which is still
>far too low).

I took this to mean you agreed with John that the proposal in 
ipv4-id-update-00 would not get us very far. I agreed. So I proposed 
a straw-man alternative and the discussion shifted to that (mostly 
misunderstandings about what 'that' was). That ended up with you 
going back to the proposal in ipv4-id-update-00.

Instead, perhaps we should start by checking whether you now agree 
that the proposal in ipv4-id-update-00 will not get us very far, and 
to be more precise about why.

Then we can move on to possible alternatives.

Bob

At 19:43 26/05/2010, Joe Touch wrote:
>Hi, Bob (et al.),
>
>Trying to summarize (I'll refer to "the current draft" and "Bob's
>algorithm" so we can refer to things without relative context of who
>writes the email).
>
>Joe
>
>------------------------
>
>- the current draft focuses on changes to "atomic" packets
>         (i.e., those not already fragmented and with DF=1)
>         for those packets:
>         - deprecates all uses of the ID by receivers or
>         intermediates
>         - sender can put any value in since it is ignored
>
>- the current ID relaxes the requirement on sender's repeating IDs
>         - currently they MUST NOT repeat IDs for 2*MSL
>         (which most ignore, but it's still there - so any host that
>         doesn't do this is already non-compliant and already
>         potentially generates reassy errors- that's not new)
>
>         - indicates that reuse can occur so long as it won't
>         interfere with reordering
>                 i.e., it *relaxes* the current 2*MSL reuse
>                 interval; this doesn't ADD a requirement so
>                 much as RELAX it
>
>                 it does not specify how to determine that
>                 value. there is no way for the sender to
>                 do that anyway; it's a design parameter, IMO
>
>** if this issue is contentious, let's leave the value at 2*MSL **
>
>I wanted to relax it. Bob is showing a *possible* way to detect the
>interval at the receiver, given some assumptions, but that's not
>directly useful to the sender anyway.
>
>Addressing the key outstanding question:
>
>- Bob repeated Fernando's question:
> > ...For expected reordering context/interval, please give:
> > i) a definition,
>
>There has been such a definition since draft-touch-02 at least:
>
>    o  >> Sources emitting non-atomic IPv4 packets SHOULD NOT repeat ID
>       field values within a given source IP, destination IP, and
>       protocol tuple over the period that fragment reordering would
>       affect reassembly.
>
>If useful, I can revise the presentation to make it clear that
>"reordering interval" is defined as the "period over which reordering
>can occur", i.e., the longest period between fragments of the same
>datagram as seen at the reciever"
>
> > ii) an exaample value and
>
>2*MSL, if we can't converge on something better
>
> > iii) an explanation of how a source should estimate it
>
>I would suggest that the source could estimate it using RTT, i.e., some
>fraction or multiple of RTT seems a reasonable estimate.
>
>----
>
>Bob's algorithm tries to have the receiver adjust the reassembly cache
>to avoid misassociation automatically - regardless of how fast the
>sender wraps IDs.
>
>IMO, that's simply impossible. If the sender wraps faster than fragments
>get interleaved, there is *NO WAY* for the receiver to detect it at all.
>
>There are some blue-sky approaches, one of which Bob outlines, that try
>to detect this *WHEN THE SENDER IS ALREADY DOING THE RIGHT THING*, i.e.,
>not repeating IDs over the reordering period.
>
>I can't see what the point of that algorithm is, then.
>
>----
>
>Addressing some of Bob's recent claims, even though (as noted just
>above), I don't see the utility of the algorithm:
>
>- the current draft allows new sources to not set the ID for atomic packets
>         - it makes NO additional requirements for any currently
>         deployed sources
>
>         (Bob's does - those sources MUST comply with his algorithm
>         properties; although many current sources do, we don't
>         have a way to determine this exhaustively)
>
>- Bob's suggestion tries to compute the reuse interval
>         - not clear why this is useful; the sender is the
>         one who determines what that reuse is
>
>Some clarifications (all quoted text is from your recent response):
>
>- Bob's algorithm detects when an ID repeats
>
>         There's a new algorithm (Bob's pseudocode)
>         that measures that period at the receiver.
>
> > I'm not asking anyone to measure any period. The minimum repetition
> > period is a deterministic property of the algorithm the developer
> > chooses to do ID generation. It's known, not measured.
>
> > I'M NOT INFERRING ANYTHING FROM THE OBSERVED IDs
>
>         If you don't need that measuring, why do you
>         need the pseudocode you provided (which
>         refers to observed IDs)?
>
> > I DON'T SELECT ANY ID TO HOLD.
>
>         - it had better hold an ID somewhere
>         or it can't ever know it's seen it twice
>
>         you hold it in the fragment you're reassembling, at least
>
>         - the number of packets SENT between ID reuse
>         would be what I have called the ID generator 'period'
>
> > I don't need a known period. I'm solely proposing
> > A SRC MUST NOT REPEAT AN ID WITHIN LESS THAN N PACKETS PER SRC-DST-PROTO.
>
>         Let's say you pick an ID, and see it repeat in K packets,
>         given the source is using, as you require, an algorithm
>         that doesn't repeat for N packets.
>
>                 - you can't know that K=N
>                 packets could be reordered, and in that case
>                 K could be larger or smaller
>                 K can also vary if the alg isn't strictly periodic,
>                 (with a single fixed repeating interval for all
>                 IDs), or if IDs go through a NAT
>
>                 - if you pick K when it's larger than N, and if you
>                 use that to govern reassembly, you can end up
>                 causing errors
>
>                 NB: this is a case where a new recommendation could
>                 cause incorrect behavior; it's not possible to know
>                 that receiver behavior not erroneous
>
>         - Bob's algorithm measures periodicity at the receiver
>                 NB: due to reordering, the period measured
>                 at the receiver is NOT the same as that at the
>                 sender - it can/will be longer or shorter
>
> > I'M PROPOSING A MINIMAL CONSTRAINT ON THE ALGO. *ALL* EXISTING ALGOS
> > MEET THIS CONSTRAINT AFAIK, and all the possible algos you could ever
> > want to invent meet it too.
>
>         How about one that creates IDs across all destinations, not just
>         a single dest? (actually, many such implementations do this)
>                 in this case, any ID you want to see repeat might
>                 or might not repeat on the sender generator's period,
>                 it might repeat on some multiple of that
>
>                 this is yet another way in which the receiver measure
>                 of this period is likely to be incorrect
>
>- Bob's algorithm MUST check the IDs of non-fragmented packets
>         - checking that ID is a computational expense
>         not incurred by the current draft or by current implementations
>
>-----------------------------------
>
>

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: Joe Touch <[email-masked]>
Date: Mon, 05 Jul 2010 08:21:04 -0700

Hi, Bob,

On 7/5/2010 2:12 AM, Bob Briscoe wrote:
> ipv4-id-update-00 would not get us very far.

This comment refers to the argument that using a more accurate MSL 
estimate, rather than 2 minutes, does not suffice to allow the current 
ID space use to be valid.

I.e., it's just another, *stronger* reason why the ID is needed.

As I noted in my last post, I appreciate your concern that the ID ends 
up requiring the sender 'guess' a value it cannot determine, and I have 
provided no mechanism to determine.

In that post, I also demonstrated how your counterproposal requires 
*that same* "guess".

I don't see an alternative to the importance of that guess. Perhaps it 
would be useful to consider how best to word it (without requirements 
language, e.g.), but I still believe the document's point, purpose, and 
approach, are valid and important as is.

Joe