RE: Why do we have or should have keep-alive packets?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I have some doubts. 

The question is Who has control over Who? Does the application layer control
the transport protocol, or do transport protocols have their own autonomy?

So if the application does'nt send any data, should the transport protocol
send keep alives by its own judgement or should the application trigger the
keep-alives? My belief was that application layer controls the transport
layer. I maybe wrong in my assumption.

I believe that there should be some sort of synchronization between the
three layers (application, transport and network) and send one keep-alive
rather than these layers sending their own keep-alives.


Arjuna

-----Original Message-----
From: Gorry Fairhurst [mailto:gorry@xxxxxxxxxxxxxx] 
Sent: 26 March 2007 12:09
To: gorry@xxxxxxxxxxxxxx; dccp@xxxxxxxx
Subject:  Why do we have or should have keep-alive packets?


This email is to start a discussion on the use and requirements for protocol
keep-alive packets in DCCP. This is a follow-up to discussing the RTP/DCCP
draft.

A keep-alive packet is defined here as a packet that is sent when the
protocol has no data to send. Such packets provide no specific protocol
function, except to indicate that the protocol end points still have
protocol state.

The notes below capture some of the ideas inspired by the DCCP WG meeting in
Prague. Please add more ideas and thoughts...

1. Uses of Keep-Alive at the Network Layer:
    a) To refresh network-layer soft state (e.g. NAT, Firewall pinholes)

2. Uses of Keep-Alive at the Transport Layer:
    a) To verify network path (rtt change, loss indication)
        - to modify congestion parameters.
    b) To verify remote reachability (end host transport still there?)
        - to terminate/reset connection.
    c) To verify transport state (application died? no loss?)
        - to retransmit or reset peer lost protocol state.

3. Uses of Keep-Alive at the Application Layer:
    a) To verify receiver state (socket open, application died?)
        - to terminate/reset connection.
    b) To verify network path (path changed?)
        - to modify flow-control/session parameters.

Do these lists have missing things, how clear is the suggested separation in
functions between the two layers?

How often should we probe in this way?

Thoughts and comments are welcome!

Gorry


    






[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux