Re: [Int-area] [DMM] New draft posted: Anchorless mobility management through hICN (hICN-AMM): Deployment options

[Tom Herbert <[e-mail]>]

On Fri, Jun 22, 2018 at 9:15 AM, Luca Muscariello <
[e-mail]> wrote:

> IMHO, there's no such a thing as a wrong question. But you can always ask
> another one.
> And BTW, I answered already to one of the questions you redo.  Yes, there
> will be another draft on transport.
> It is not ready but I can have a technical report right before the IETF
> week and I might give a presentation
> at the next ICNRG meeting. That is out of scope for this list I think.
>
> Yes, it is out of scope for this list. If the intent is to standardize a
new transport protocol then that obviously needs to be done in transport
area. Honestly, given the immense scope and novelty of what hICN is
attempting to do, I have to wonder if this work is better to be done in
IRTF.

Tom


> On the other hand, the draft provides information about how a transport
> service sits on top of this
> forwarding machinery. There might be several transport protocols of
> course,
> likewise today there are multiple transport protocols using IPv6,
> providing different kind of services.
> They can be TCP friendly, they can be lower than best effort such as
> LEDBAT vs TCP etc.
>
> Without loss of generality, I can say that we have one specific
> implementation of a transport protocol
> that provides reliable transport services.  We have used several flow
> control laws and algorithms
> including AIMD, MIMD,  and more recently BBR.
> It has been demoed in different venues for some applications
> such as MPEG-DASH at SIGCOMM last year and also MWC last year.
> Some analysis about that can be found in the following paper.
>
> J. Samain, et. al
> Dynamic Adaptive Video Streaming: Towards a Systematic Comparison of ICN
> and TCP/IP.
> IEEE Trans. Multimedia 19(10): 2166-2181 (2017)
> https://doi.org/10.1109/TMM.2017.2733340
>
> Another transport service that we have implemented and that I might demo
> during the IETF week
> is one used for a scalable RTC system based on WebRTC, Chrome and
> Simulcast.
> Nothing to do with TCP friendliness of course for this protocol.
>
>
>
> On Fri, Jun 22, 2018 at 5:39 PM Tom Herbert <[e-mail]> wrote:
>
>>
>>>
>>> #3 is the wrong question to ask. The right question is "Does the new
>> transport protocol disrupt TCP?". Of particular interest, how does the
>> protocol interact with TCP on wire? What is the congestion control of the
>> new transport protocol? How is it "TCP friendly"? As Behcet mentioned,
>> these are not things that can be answered in a few sentences on an email
>> thread. The draft posted seems bereft of any details about the new
>> transport protocol; will another draft be coming that specifies the
>> transport protocol and answers questions like this?
>>
>> Tom
>>
>