Re: [Softwires] [softwire] Merged version of lightweight 4over6

hi Yiu,

thanks for the explanation.

2012/2/16 Lee, Yiu <Yiu_Lee@cable.comcast.com>

> Hi Maoke,
>
> For 1, it is not a ds-lite problem but a general problem for any tunneling
> protocol. Once option is the 4o6 TC passes the fragmented packets and hope
> the destination would reassemble them. This option would break the
> end-to-end model if the destination rejects fragmented packets. The current
> model in RFC6333 will not in exchange with extra CPU and buffer overhead.
>
>
got it. this point is fine. and i also mean that DS-Lite states (Sec 6.3):

   This reassembly process will significantly
   impact the AFTR's performance. However, this impact only happens
   when many clients simultaneously source large IPv4 packets. Since we
   believe that the majority of the clients will receive large IPv4
   packets (such as watching video streams) instead of sourcing large
   IPv4 packets (such as sourcing video streams), reassembly is only a
   fraction of the overall AFTR's workload.

the "since we believe" is true in the term that client/server model is
dominating the Internet usage. but the situation is changing, AFTR might
suffer a heavy burden with reassembly in the environment where p2p is
dominating. can we (actually you authors) surely state lightweight 4over6
improves this? if we can, it is a happy point. ;-)

best,
maoke

> For 2, we can mention ALG could be implemented in the 4o6 TI. We still
> want to keep the 4o6 TC simple.
>
> Thanks,
> Yiu
>
> From: Maoke <fibrib@gmail.com>
> Date: Wed, 15 Feb 2012 16:38:36 +0900
> To: Qiong <bingxuere@gmail.com>
> Cc: <softwires@ietf.org>
> Subject: Re: [Softwires] [softwire] Merged version of lightweight 4over6
>
> sp. the merged document meets the requirements where flexible dynamic IPv4
> address sharing in IPv6 domain and meanwhile 1) considerably reduces the
> states that the AFTR needs to handle; 2) reduces the overload of AFTR
> through distributing the NAT functionality over Initiators.
>
> i think the document is ready for WG adoption.
>
> a further discussion is: DS-Lite (RFC6333) states some limitations related
> to the potentially high burden of AFTR. as i understand, there are at least
> two:
> 1) for fragmentation and reassembly (RFC6333, sec 5.3, sec 6.3), it is
> required to reassembly before the decapsulation. DS-Lite states because of
> the high buffer requirements, AFTR doesn't do the reassembly but only B4 do
> that. it is reasonable in the case of client/server communications where
> large datagrams happen often in the inbound. however, it implies that
> DS-Lite is not very suitable for the p2p communications where outbound
> datagram might be large as well.
> 2) on the issue of ALG (RFC6333, sec 8.3), it is stated that DS-Lite AFTR
> doesn't do ALG for any applications. thus some applications might be
> impacted.
>
> my question is: can lightweight 4over6 improve 1) and 2) because the AFTR
> load has been enlighted? if so, i suggest the author to state the
> improvement of releasing the limitations.
>
> regards,
> maoke
>
> 2012/2/5 Qiong <bingxuere@gmail.com>
>
>> Dear all,
>>
>> We have published a merged version of lightweight 4over6 in:
>>
>> http://www.ietf.org/internet-drafts/draft-cui-softwire-b4-translated-ds-lite-05.txt.
>>
>>
>> This mechanism moves the translation function from the tunnel
>> concentrator (AFTR) to initiators (B4s), and hence reduces the mapping
>> scale on the concentrator to per-subscriber level.
>>
>> It has got wilely support in the last Taipei IETF meeting, and the only
>> action we need to do is to merge I-D.cui-softwire-b4-translated-ds-lite
>> and I-D.zhou-softwire-b4-nat into one draft.
>>
>> Now that the merge work has done, from the authors of this document's
>> view, it is ready to be adopted as working group document. We would be
>> appreciated to have your comments.
>>
>> Thanks in advance !
>>
>> Best wishes
>>
>> Qiong
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>>
> _______________________________________________ Softwires mailing list
> Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
>