Subject: [forces] Large object dump

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 18 Mar 2014 15:54:25 -0400

Folks,

In the latest proto update draft I have tried to clarify what RFC 5810 didnt on
dumping large objects. To quote from the draft text:

--
   Imagine a GET request to a path that is a table i.e a table dump.
   Such a request is sent to the FE with a specific correlator, say X.
   Imagine this table to have a large number of entries at the FE.  For
   the sake of illustration, lets say millions of rows.  This requires
   that the FE delivers the response over multiple messages, all using
   the same correlator X.
---

My view (based on implementation) is to re-use the transaction flags
since they have no semantic meaning on the direction of the FE->CE
and they are not totally off in describing the progress of the dump.
Here's what our implementation does (with intention to mirror what
a transaction from CE->FE will do).

The AT (Atomic Transaction) flag is used to indicate "multi message"
The TP(Transaction Phase) flags SOT/MOT/EOT to indicate start,
middle and End of dump.

There is one caveat with two alternatives:
1) The last message which carries the EOT flag would need to go the CE
without any data - likely with a result code. This would be the mirror of
a 2PC commit where the last message is an empty commit message.
OR:
2) The last message which carries the EOT flag would need to go the CE
with data

What do people think? We have implemented #2 - but it seems to me #1
would be better.
Attaching a small diagram which shows alternative #1 just in case i wasnt
clear.

cheers,
jamal

---

From: Joel <[email-masked]>
Date: Wed, 26 Mar 2014 16:11:47 -0400

This looks like a real problem.  Particularly for structures with 
multiple large tables, any other approach requires significant 
complexity on the CE.

As far as I can tell, using these flags for this problem is as good an 
answer, or better than anything else I can find.  So yes, lets do that.

Yours,
Joel

On 3/18/14, 3:54 PM, Jamal Hadi Salim wrote:
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 27 Mar 2014 06:43:26 -0400

Joel,

I am leaning towards the last message which carries the EOT flag to go the CE
without any data to mirror  a 2PC commit where the last message is an empty
commit message. It is not how our implementation works right now, but we can
change it.

Does that sound reasonable?

cheers,
jamal

On Wed, Mar 26, 2014 at 4:11 PM, Joel <[email-masked]> wrote:
> This looks like a real problem.  Particularly for structures with multiple
> large tables, any other approach requires significant complexity on the CE.
>

---

From: Joel <[email-masked]>
Date: Thu, 27 Mar 2014 09:24:48 -0400

I would certainly want to permit that.  The question that is not obvious 
is whether we need to mandate it.

Yours,
Joel

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Thu, 27 Mar 2014 16:12:47 +0200

Greetings Joel and Jamal and to the list,

I agree that this is something that we need to address and I also agree with
the proposed solution.
However I think that we would need to explicitly specify in the solution
that the FE MUST NOT split a table row in the middle and send it within one
of those messages.

For example imagine having a table with each row being a large struct with
let's say 10 components.
Since the proposed solution does not offer any ordering in the messages (and
indeed it's not needed as row indexes are packed into the data) the struct
MUST NOT be split in two ForCES messages as there is no way to reconstruct
the struct again. So the FE MUST take care to stop putting table rows if
current_message_size+next_row_size>maximum_message_size.

Regards,
Evangelos Haleplidis.

> -----Original Message-----
> From: forces [mailto:[email-masked]] On Behalf Of Joel
> Sent: Thursday, March 27, 2014 3:25 PM
> To: Jamal Hadi Salim
> Cc: [email-masked]
> Subject: Re: [forces] Large object dump
> 
> I would certainly want to permit that.  The question that is not
> obvious is whether we need to mandate it.
> 
> Yours,
> Joel
> 
> > I am leaning towards the last message which carries the EOT flag to
> go
> > the CE without any data to mirror  a 2PC commit where the last
> message
> > is an empty commit message. It is not how our implementation works
> > right now, but we can change it.
> >
> >> As far as I can tell, using these flags for this problem is as good
> >> an answer, or better than anything else I can find.  So yes, lets do
> that.
> >>
> >> Yours,
> >> Joel
> >>
> >>
> >>> In the latest proto update draft I have tried to clarify what RFC
> >>> 5810 didnt on dumping large objects. To quote from the draft text:
> >>>
> >>> --
> >>> 1) The last message which carries the EOT flag would need to go the
> >>> CE without any data - likely with a result code. This would be the
> >>> mirror of a 2PC commit where the last message is an empty commit
> message.
> >>> OR:
> >>> 2) The last message which carries the EOT flag would need to go the
> >>> CE with data
> >>>
> >>> Attaching a small diagram which shows alternative #1 just in case i
> >>> wasnt clear.
> >>>
> >>> cheers,
> >>> jamal
> >>>
> >>>
> >>>