Subject: Re: I-D ACTION:draft-khosravi-forces-tcptml-01.txt

From: "Putzolu, David" <[email-masked]>
Date: Fri, 25 Feb 2005 19:14:24 -0800

TCP/IP makes no guarantees of respecting the boundaries
of the message you give it - to TCL it is just a stream
of bytes.  Given following received at FE: [[Payload] IP]

TCP/IP could deliver any of the following at the CE:

[[[{[Payload]IP}PL hdr]TCP]IP] 
[[[{[Payload]IP}TCP]IP] [[[PL hdr]TCP]IP]
[[[{[Payload]TCP]IP] [[}PL Hdr]TCP]IP]
[[[{[Payl]TCP]IP] [[[[oad]IP}PL Hdr]TCP]IP]
etc - could also concatenate as well:
[[[{[Payload1]IP1}PL hdr1{[Payload2]IP2}PL hdr2]TCP]IP]

Cheers,
David

> -----Original Message-----
> From: Forwarding and Control Element Separation 
> [mailto:[email-masked]] On Behalf Of Furquan Ansari
> Sent: Friday, February 25, 2005 2:07 PM
> To: [email-masked]
> Subject: Re: [FORCES] I-D ACTION:draft-khosravi-forces-tcptml-01.txt
> 
> Unless you are using TCP over some other network protocol, I have to 
> assume that the TCP stream
> is carried within IP datagrams. So, the way I am seeing this is:
> 
> Headers involved:
> ------------
> Orig Received at FE: [[Payload]IP]
> 
> Redirect Data from FE to CE: [[[{[Payload]IP}PL Hdr]TCP]IP]
> 
> So, what am I missing?
> 
> 
> Joel M. Halpern wrote:
> 
> > Remember that TCP is a stream protocol, not a packet 
> protocol.  There 
> > is no "outer IP packet" to look at.
> >
> > Yours,
> > Joel
> >
> > At 04:16 PM 2/25/2005, Furquan Ansari wrote:
> >
> >> Joel,
> >>    But couldn't this be deduced from the Outer IP header? - if the 
> >> transport mechanism is TCP/IP between the
> >> FE and CE. I pressume that you mean that the FE receives 
> an IP packet 
> >> from a neighbor which could have
> >> length mismatch and has to be redirected to the CE. This IP packet 
> >> would be encapsulated within the TCP/IP
> >> channel as payload between the CE and FE. In such as case, 
> the outer 
> >> IP header should contain the "actual" length
> >> received.
> >>
> >> Thanks,
> >>
> >> Joel M. Halpern wrote:
> >>
> >>> At least for the redirected packets (which folks are 
> arguing should 
> >>> not have a shim header) I can not see how to avoid such a header.
> >>> Although the IP Header has a total length field, one of 
> the reasons 
> >>> for sending the packet to CE may be that the amount of 
> data received 
> >>> and the total length actually received may not match.
> >>> We can argue that in such a case we should never send 
> that packet to 
> >>> the CE, but that seems an odd restriction.
> >>>
> >>> Yours,
> >>> Joel
> >>>
> >>> PS: This also mandates that the PL header have a total 
> length field.
> >>> Is it really the job of the TML to tell the PL how to do its job?
> >>
> >>
> >>
> >> -- 
> >> Furquan Ansari
> >> Bell Labs Research                      Ph : 732-949-5249
> >> Holmdel, NJ                             Fax: 732-949-4556
> >
> 
> -- 
> Furquan Ansari
> Bell Labs Research			Ph : 732-949-5249
> Holmdel, NJ				Fax: 732-949-4556
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 25 Feb 2005 22:35:52 -0500

You could overcome this issue at the TML level by maintaining state
of the packet i.e some form of reassembly detail:

put a little loop that reassembles the PL packet from the TCP stream.

assuming you receive a PL header but an incomplete PL packet ..
which you detect because  socket receive() length < PL len, then you
buffer the incomplete PL packet until such a point you have sufficient
data that is of the same size of PL length. The end of one PL packet is
the beggining of another...  

This so far has worked for us so far.

cheers,
jamal