To summarize the discussion, fragmentation happens due to:

c1) via-list and route-list growth (only in recursive routing)
c2) resource + header size exceeding MTU
  -at the request originator
  -or at the intermediate nodes.

Solution space consists of whether intermediate nodes should:

s1) store via/route-list in the local memory
s2) store via/route-list + fragment state in the message
s3) perform per-hop reassembly of fragments
s4) perform e2e reassembly of fragments

The protocol provides ROUTE-QUERY message which allows to search for the destination peer before performing the transfer (essentially, iterative routing). This is one way to avoid via-list and route-query growth problem.

As a fragmentation solution, I prefer s1|s2 with s4.

I am not in favor of (s3), i.e., per-hop reassembly of fragments as a MUST in base spec whether this is for via/route-list or for large messages.

-salman


On Tue, 16 Dec 2008, Narayanan, Vidya wrote:


Is this growth primarily in the via list?  If that is the case, then it
seems possible to solve this using a combination of the fragment
field and the via list.  If the fragment field's high order two bits
indicate that this is a fragment, you could replace the via list
with a null list for any fragment after the first complete rendering
of the via list.  That requires one more state in the fragment field
(via list not yet complete;via list complete).  It also requires you
to presume that the via list can be split across fragments and
and that fragments with "via list not yet complete" set are
going to have no real data--just segments of the via list--in them.


Maybe I'm missing something basic here.  How would the sending node even know 
that the via list was rendered completely at any time?

Regards,
Vidya

The same things can be done when other headers grow, obviously;
it is just a bit easiert to do when it is only one header that has to
be tracked in this way.
                        regards,
                                Ted

_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip


_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip

Reply via email to